3

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)?

Community
  • 1
  • 1
AndrewS
  • 3,450
  • 1
  • 21
  • 26
  • http://msdn.microsoft.com/en-us/library/aa384231(v=vs.85).aspx – Lex Li Mar 04 '12 at 12:43
  • Thank you for the link, but I didn't find anything particularly helpful there. What should I be looking for? – AndrewS Mar 04 '12 at 14:53
  • If you cannot follow that article, you may try to request a sample via http://1code.codeplex.com/wikipage?title=COM. It is very likely that your registration of the COM object is incorrect. – Lex Li Mar 05 '12 at 05:13
  • 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 Mar 05 '12 at 09:54
  • 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 Mar 06 '12 at 06:49

1 Answers1

2

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.

The generated Interop class we were using during runtime was simply replaced with the regenerated one. Once the program was restarted with the new generated Interop class in place, it started working again.

The reason this issue simply appeared all of a sudden was due moving the code to a new server. I think something got mixed up during the move.

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
Mr Moose
  • 5,946
  • 7
  • 34
  • 69
  • 1
    So you re-built the project and it fixed your issue? Your answer does a good job showing that you had the same problem, but the solution is not very clear. – Trisped Nov 06 '12 at 08:21
  • This was more of a runtime issue that compile time. The generated Interop class we **were** using during runtime was simply replaced with the regenerated one. Once the program was restarted with the new generated Interop class in place, it started working again. That is what I meant by "utilising this fixed the issue for us". The reason this issue simply appeared all of a sudden was due moving the code to a new server. I think something got mixed up during the move. – Mr Moose Nov 06 '12 at 08:27