However, you can make this work under Win 7, but it should be noted, that this workaround is sometimes not needed. The problems with 32bit / 64bit registry stuff is often that you use a 32 bit application to register a 64 bit assembly – this does not work since 32 bit applications do not see 64 bit registry by default.

I’m trying to use CoCreateInstance on a Visual SourceSafe DLL.

The registry hack solution is not working for me. I’m getting the following error

“Unable to cast COM object of type ‘NewAtlProjectLib.InmAtlsimpleobject1Class’ to interface type ‘NewAtlProjectLib.IInmAtlsimpleobject1′. This operation failed because the QueryInterface call on the COM component for the interface with IID ‘{0D5A58FA-5C0E-4AC1-9064-9C5A2C51FD55}’ failed due to the following error: Class not registered (Exception from HRESULT: 0×80040154 (REGDB_E_CLASSNOTREG)).”

My environment details are
Building com objects –> C++ 32 bit DLL
Wrapper DLL –> C# 64bit dll
Client application –> C# 64 bit windows application
Build environment –>W2K8 SP2 + VS2008

The client application function is
public int samplefunction(int val)
{
InmAtlsimpleobject1Class c1 = new InmAtlsimpleobject1Class(); //here succeeds
int val1 = c1.DoSomething(); //here failed with above error
return val;
}

Please suggest. Any other change is registry entry required ?

Thanks
Mathi

Most probably Microsoft changed something in Windows 7 that disabled this workaround. What error are you experiencing? Is it the same as Tobias was experiencing above? And, did you try the same process I suggested to him?

IClassFactory *pclsf;
IUnknown *pUnk;
IStepfile *pstep;
int x,y;
long result;
CoInitialize(NULL);
HRESULT hr= CoGetClassObject(STEPFILE_CLSID,CLSCTX_INPROC,NULL,IID_IClassFactory,(void**)&pclsf);
hr = pclsf->CreateInstance(NULL,IID_IUnknown,(void**)&pUnk);
hr=pUnk->QueryInterface(IID_IStepfile,(void**)&pstep);
result = pstep->AddNum(1,2);

thanks for your quick reply. I used as flag “CLSCTX_LOCAL_SERVER” and “CLSCTX_ACTIVATE_32_BIT_SERVER” and also tried only one of them but nothing changed.
“CoCreateInstance” will return “CLASS_NOT_REGISTERED”. In this article (http://msdn.microsoft.com/en-us/library/aa384253%28v=VS.85%29.aspx) they specified why reflection would be disabled.

Have you run 32-bit-surrogation in this way with Windows 7?

Regards,

Tobias

I didn’t run into your problem so this might not work, but none the less worth a shot I guess. Did you try setting the CLSCTX_LOCAL_SERVER flag for dwClsContext in the CoCreateInstance Call?

This should theoretically force the com to use the localservice key which according to your link is reflected. Might work, definitely worth a shot.

I tried this for my COM DLL but it does not work for DLL surrogation. According to this article (http://msdn.microsoft.com/en-us/library/aa384235%28v=VS.85%29.aspx) all registry keys which includes InProcServer32-IDs are not reflected because Microsoft assumes that these are only InProc-Calls and not Out-Of-Proc-Calls. A CoCreateInstance-Call would return “CLASS_NOT_REGISTERED” because it does not find the key in the 64-bit section.

Has anybody an idea how to get reflected the key with using of DLL surrogation?

I made the registry changes, but I now receive the following error:

Retrieving the COM class factory for component with CLSID [class guid] failed due to the following error: 80070005.

Anything I missed?

Thanks,
Rachel