Subject: Forcing a .NET obj exposed as COM to use StdCall instead of CdCall

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Does anyone know how to force interop to use a stdcall interface on the COM objects it creates instead of the cdcall interface that is standard?

This is very importiant for my project. I need to reference a VB.NET based interop COM object from an outside program. The program will only interact with a stdcall interface on the COM object. .NET interop uses the cdcall interface when it exposes an assembly to COM. I need to figure out how to change this.

Thanks for any help.

-Doug
 
I was told that was the case. I could be wrong about that, but it was the explination for why the COM object wasn't working

What type of call does interop use when exposing an assembly to COM

-Dou

BTW, thanks for the info.
 
Hi,

Thanks for your post.
It's also _stdcall. You can verify it by the following steps:

1. Use Tlbexp.exe (Type Library Exporter) command to generates a type
library that contains definitions of the types defined in the assembly.

Type Library Exporter (Tlbexp.exe)
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cptools/htm
l/cpgrfTypeLibraryExporterTlbExpexe.asp

2. Start the OLE Viewer tool (OLEVIEW.EXE) that shipps with VS .NET.

3. Open the type library in OLE Viewer and you can see that the methods are
declared as _stdcall.

I believe there must be another problem that COM object is not working.
Could you please give us detailed information on the sympton of the problem?

I look forward to hearing from you.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
It's not "cdcall". I assume you mean "__cdecl", right?

But in any case, COM works through basically one method, DllGetClassObject.
This is not exported from your .NET interop assembly but from mscoree.dll.
And it's exported through __stdcall from there, as is the standard with
Windows system libraries.

I've never seen a COM client that requires a specific calling convention -
that's one of the things COM is supposed to encapsulate. Otherwise we'd all
still be doing GetProcAddress() and calling function pointers =)

--
____________________
Klaus H. Probst, MVP
http://www.vbbox.com/

Doug said:
Does anyone know how to force interop to use a stdcall interface on the
Click to expand...
COM objects it creates instead of the cdcall interface that is standard?
This is very importiant for my project. I need to reference a VB.NET
Click to expand...
based interop COM object from an outside program. The program will only
interact with a stdcall interface on the COM object. .NET interop uses the
cdcall interface when it exposes an assembly to COM. I need to figure out
how to change this.
 
I stand corrected about the stdcall issue. I was repeating that information from the reserch that a person who has a problem similar to mine was doing

I need to make the VB.NET object callable from a program called Trade Station. It is a stock analysis and trading tool that is very importiant to my company. They have a scripting languge called easy language that is built into the system. It is supposed to be capable of extending itself by calling external DLLs. It is very picky about what DLLsit will see though

Others have had success using C++ to write a DLL that will work with Easy Language, but I am hitting a brick wall with VB. I am not a strong C++ programmer, but I am very good at VB. I am hoping to find a way to make interop expose my VB DLL in the same way that the C++ DLL is exposed. Here is a snippet of code that is from a working C++ DLL. I hope it is meaningful. I am not sure :-(

-----------stdafx.h----------
// stdafx.h : include file for standard system include files
// or project specific include files that are used frequently, bu
// are changed infrequentl
/

#pragma onc

#define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows header
// Windows Header Files
#include <windows.h

// TODO: reference additional headers your program requires her
#define dll_entry( type ) extern"C" type __stdcal

-----------a.cpp----------
// a.cpp : Defines the entry point for the DLL application
/

#include "stdafx.h
#import "c:\Program Files\TradeStation\Program\TSKit.dll" no_namespac
#import "D:\documents\projects\TradeStationInterop\CSharp\bin\Release\CSharp.tlb

BOOL APIENTRY DllMain( HANDLE hModule,
DWORD ul_reason_for_call,
LPVOID lpReserve


return TRUE


double __stdcall MyTest(IEasyLanguageObject *pEL, int iNBars

CSharp::_Class1 *com_ptr
CoInitialize(NULL)
CSharp::_Class1Ptr p(__uuidof(CSharp::Class1))
com_ptr = p
double d = com_ptr->TestDouble()

return d


-----------stdafx.cpp----------
// stdafx.cpp : source file that includes just the standard include
// a.pch will be the pre-compiled heade
// stdafx.obj will contain the pre-compiled type informatio

#include "stdafx.h

-----------a.def----------
LIBRARY
EXPORT
MyTest
 
Doug,

What you're talking about here is a completely different thing than COM.
I've seen these extension scripts in products like Mercator and PoepleSoft.
They basically load a DLL and call a method in it by using GetProcAddress
and a defined signature through a function pointer. However, you will not be
able to pull *that* off with .NET because you cannot create standard exports
in CLR assemblies. You'd need to use C or C++ or (maybe) Delphi. This is not
a problem with COM since the application is not using COM (at least in the
example you describe below).

If the script can call COM objects normally (instead of using
LoadLibrary/GetProcAddress) like, say, VBScript, then it's certainly
possible because .NET can create normal unmanaged COM wrappers around
managed assemblies. But the scenario you describe below is basically
impossible to achieve with plain .NET, COM or not.


--
____________________
Klaus H. Probst, MVP
http://www.vbbox.com/

Doug said:
I stand corrected about the stdcall issue. I was repeating that
Click to expand...
information from the reserch that a person who has a problem similar to mine
was doing.
I need to make the VB.NET object callable from a program called Trade
Click to expand...
Station. It is a stock analysis and trading tool that is very importiant to
my company. They have a scripting languge called easy language that is
built into the system. It is supposed to be capable of extending itself by
calling external DLLs. It is very picky about what DLLsit will see though.
Others have had success using C++ to write a DLL that will work with Easy
Click to expand...
Language, but I am hitting a brick wall with VB. I am not a strong C++
programmer, but I am very good at VB. I am hoping to find a way to make
interop expose my VB DLL in the same way that the C++ DLL is exposed. Here
is a snippet of code that is from a working C++ DLL. I hope it is
meaningful. I am not sure :-(
 
Back
Top