That wasn't the problem. I tried to manually register the DLL with
regsvr32 and it didn't work either.
I found two things that when combined did help:
1. define the _ATL_MIXED macro
2. Initialize the CComModule global in a managed code section. The original
problem was that the InitInstance() was not called (for a reason that I
don't fully understand). After placing the CComModule initialization in a
managed section the InitInstance is called
correctly and the registration proceeds as expected.
Maybe it's a know problem and I'm only treating the symptoms, so if anybody
has a clue what it's all about - please let me know. I know we're using old
COM classes. Would using
ATL8.0 help?
Genady
"Marcus Heege" <no****@heege.netwrote in message
news:%2****************@TK2MSFTNGP02.phx.gbl...
Yes, that's a pity in VS.NET. If you have a project that produces an
assembly, and use the linker setting to register the output, they will use
RegAsm to register the .NET types instead of RegSvr32.
You should avoid this setting and use a custom build step instead.
Marcus
"Genady Beryozkin" <ge****@spammerscatch.algotec.co.ilwrote in message
news:%2****************@TK2MSFTNGP04.phx.gbl...
>>I have a COM dll that defines a COM object.
I used to register it either during link or using regsvr32.
Now I have compiled one of the C++ files in the DLL with /clr so now I
have a mixed DLL.
The problem is that the DLL registration no longer works.
Regsvr32 succeeds but the GUIDs of the COM objects no longer present in
the registry
and when somebody tries to CreateInstance of them, I get an error "Class
Not Registered".
Is there any magic that makes it possible to register such DLL?
Thanks in advance,
Genady