x86 COM interop from x64 .Net assembly using COM+ - "No such interface supported" error

1
votes

I am writing a C# assembly that is called from an x64 process (SS Reporting Services) and needs to use an x86 3rd party COM assembly.

When I compile my assembly as x64, I get a "Class not registered" COM exception as soon as the first call to the COM assembly is made.

Following the advice here (sorry if my terminology is incorrect) I created a new COM+ application and added components found in the COM assembly I am referencing. When I run my assembly as x64 it does make some successful calls to the COM assembly until I get this error:

Unable to cast COM object of type 'TRIMSDK.RecordTypesClass' to interface type 'TRIMSDK.IBaseObjects'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{8A354545-6BCB-11D3-B273-00A0C9FC3DC0}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).

'TRIMSDK.RecordTypesClass' does implement 'TRIMSDK.IBaseObjects' according to the class definition.

If I search the registry for the interface GUID from the error message or for 'IBaseObjects', no matches are found. Since creating the COM+ application I get the same error in x86 mode (which I guess makes sense), though it worked fine in x86 before that.

So, I assume the 'TRIMSDK.IBaseObjects' interface I'm trying to use isn't being registered as a COM+ thingy and I don't know why or how to fix it.

Any ideas? Thanks in advance.

Update: I think I am getting the E_NOINTERFACE exception for TRIMSDK.IBaseObjects because the TypeLibType attribute on the interface is set to 'FNonExtensible' only, whereas other interfaces I use successfully in the assembly also have 'FDispatchable'. Is it possible to get around this error (either altering the type library or manually registering the 'IBaseObjects' interface somehow)?

1
c#com-interopcom+
msdn.microsoft.com/en-us/library/aa384231(v=vs.85).aspx – Lex Li
Thank you for the link, but I didn't find anything particularly helpful there. What should I be looking for? – AndrewS
If you cannot follow that article, you may try to request a sample via 1code.codeplex.com/wikipage?title=COM. It is very likely that your registration of the COM object is incorrect. – Lex Li
I have updated my question a little since your inital comment. I know that something is wrong with the COM registration but fixing it is another matter (particularly since I don't have the source to recompile the COM assembly with different type attributes) :). I ended up using the CSExeCOMServer sample which I found yesterday to make a C# wrapper to work around my problem. Thanks for the link. – AndrewS
You may describe the steps and use that as an answer to this question. That can help others if they hit the same problem. Regards, – Lex Li

1 Answers

1
votes

This is quite an old question, but I've just sorted this out in our environment after having been struggling with this issue for a while. I have very little experience with COM and/or Interop so excuse me if my terminology is a little off.

The error message I was getting was;

Unable to cast COM object of type 'TYSTransfer.TransferClass' to interface type 'TYSTransfer._Transfer'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{E825C39B-1EF3-4319-89FC-AEF62C8117B9}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).

I was also struggling to find the interface GUID specified in the message. I looked in Component Services for the GUID assigned to our COM component and could see;

GUID that component services showed

Then when I used DotPeek to look at the generated Interop class that I was using to access this COM component, I noticed that the associated GUID for the same interface was the one as was reported in my error;

DotPeek data of the same interface

So DotPeek showed me that the Guid being referenced was from my Interop class. It turned out that regenerating the Interop class against the target COM object generated a class with the correct Guids (at least they matched so I assumed they were correct), and utilising this fixed the issue for us.