Why does instantiating COM object in C# throw exception

I'm trying to instantiate a COM object, defined in a x86 dll written in Borland C++, in a testing program i write in C# (.net 4.7.2). The COM dll (server) is working, I have a windows service also written in C++ Borland that can use it and instantiate a COM object from the class (using CoCreateInstance). The dll is registered and the InprocServer32 entry has the correct path to the dll. There is no coclass existing in a typelib, only interfaces (those exist in the typelib). I have used the TlbImp to create dll:s which i reference in the c# project. In the project the target platform is set to x86. The way i try to instantiate an object is:

var comType = Type.GetTypeFromProgID("ins.MyComType");
object comObj = Activator.CreateInstance(comType);

however the second line gives me

"Exception thrown: 'System.IO.FileNotFoundException' in mscorlib.dll" with the message 'Retrieving the COM class factory for component with CLSID {C4363C5E-3831-46DF-8701-60C8D1B612BA} failed due to the following error: 8007007e The specified module could not be found. (Exception from HRESULT: 0x8007007E).".

It does not matter if i try to run the app as administrator. I have a vague memory of trying out a similar thing a couple of years ago and that it at that time worked. It was probably on a Win 7 machine (might even have been a 32-bit system). I have tried to open the project in DependencyWalker but i'm not sure what i'm looking at. I get a couple of errors:

*Error: At least one required implicit or forwarded dependency was not found. *Error: Modules with different CPU types were found. *Error: A circular dependency was detected. *Warning: At least one delay-load dependency module was not found. *Warning: At least one module has an unresolved import due to a missing export function in a delay-load dependent module.

Does any one have any idea on what it could be causing the exception? Or if i could get some hints as of how to dig deeper into dependencywalker? I get a gigantic tree of systemassembly stuff but i cannot see any obvious assembly standing out, though DW refers to many of them as being 64 bit. My guess is some dependent dll(s) somewhere should be x86 but which one(s). Is there a redist similar thingi i should have installed for this to work?

best regards

/Erik

You should write a simple VBScript that contains these lines:

set obj = CreateObject("ins.MyComType")
MsgBox TypeName(obj)

Name the file test.vbs

Execute the command:

c:\windows\syswow64\wscript.exe test.vbs

Using the version from syswow64 ensures that it uses the 32-bit version of wscript.exe which can instantiate 32-bit COM objects. The version in c:\windows\system32 can only instantiate 64-bit In-process COM objects in DLLs...you said your object is a 32-bit COM DLL server.

If the vbscript fails, it could be that the object is not automation compatible--implements IDispatch. Otherwise you will get an error message why it fails.

If it succeeds, you will know there is probably nothing on the C++ side causing problems. You THINK this is the case...but where is the runtime for Borland C++? Is everything statically linked, or is some of it dynamically linked? If it is dynamically linked, where is it in the path? It could be that the C++ service you have has the library in its path so that when it loads your COM object, the library is available. But, when you try to load from a 3rd party, like .NET or VBScript then the path to the library manifests itself. Who knows? I'm just making suggestions.

If you use ProcMon, it can see where the problems are. It will show you what registry entries are being read and which files are trying to be loaded.