从64位模式运行的c＃调用32位COM

Question

I have a 3rd party COM object(32 bit) that I need to call from my c# application (64 bit). I know I have to run the COM object in a separate process. This COM object has many classes implemented in it, so I'm trying to avoid writing my own remoting wrapper that exposes all the methods. COM+ seems to be the most straightforward solution. I opened the Component Services menu, created a new COM+ Application, added my COM object as a component to this application. Everything seemed to import beautifully.

In my C# application, I added the original COM object as a reference (which automatically generates the type library). Using the type library reference, I can create objects from from the COM+ component (I see them begin to spin in the Component Services window), but when I try to access on of the methods of the object, I get an error saying the interface is not registered.

Does anyone have a clue? I went back and ran regsvr32 on the COM object, but I don't think it was necessary, and it didn't help. Is my usage in C# correct? VS2008 autocomplete had no problem seeing those methods.

The exact exception is: "Interface not registered (Exception from HRESULT:0x80040155)"

Unclear about exactly what the permissions and roles are about in the Component Services, I tried setting up the COM+ object identity to run under the System Account, both as a local service and as interactive user. I've added Everyone as a user in the Roles. Everything is running locally, so there shouldn't be an issue with file privileges or anything like that.

I also want to reiterate that this COM object contains many classes. I successfully instantiated one class object in my client and set some property values. I also successfully instantiated another class object, but received this exception when attempting to call a method of this second object .... so I don't think there is an issue with which registry my COM object is registered in.

Answer 1

We had a similar situation, working with a COM dll from VFP.

It all depends on rights and permissions, like Yahia says. We got it working by doing this:

• Install VFP oledb 9 drivers (dunno what you have so probably not required).
• give Network Service IIS_IUSR full control on the COM folder (required so the DLL can do some logging in its own folder, when called from the website).
• run regsvr32.exe "c:\\xxx\\yourfile.dll" -> this should be successful!
• Create COM+ application, and add the DLL as a part
• Set the application COM+ credentials on a user wigh sufficient rights

and we had to do some more settings on rights in application pool / IIS, but thats not required for you I guess.

Anyways, just make sure you have enough logging, make sure the dll is registered, and after that its all about rights rights rights..

Good luck with it!

Answer 2

Sorry to use the "Answer" to respond to comments, but it seems to be my only avenue.

The whole purpose of moving to a 64bit operating system was to gain the extra addressable memory space, so running the entire application in 32bit mode is not an option.

It might be relevant to the problem that after successfully creating three class objects, I was able to set properties in one, call a method with no arguments in the second, but it was calling a method in the third, which took the other two objects as arguments that threw the exception.