Click here to Skip to main content
14,930,588 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I've got a bunch of C++ COM components that I'm adding to a C# .NET project as references.

All except one can be added successfully.

There is one that is never recognized as a COM.
It doesn't turn up in the COM tab in the Add Reference dialog.
So I forced to load it as a file but I get an error along the lines of:

"Please make sure the file is accessible and that it is a valid assembly or COM component."

The COM in question can be registered successfully using regsvr32 (checked registry to make sure it is there and it is).

However, when I come to add it as a COM reference, it is not recognized as a COM.

I compared this COM to all the other ones that got added successfully and of course there are differences but I can't think which of the differences is causing this one COM to not be recognized.

What am I missing?

Thanks in advance.

I stripped the COM down to its bones but still no luck.

However, investigation has revealed that:

-The GUID of the coclass is written to registry by regsvr32

-None of the GUIDs for the interfaces are written to registry

-However, GUIDs are correctly visible in OLE Viewer

-The registry entry for the coclass GUID is odd in that under InProcServer32 key, there are only the file location and threading model and no mention of InProcServer32

I'm guessing that because the interfaces are not written to the registry, I can't add it to my C# reference as a COM.

Any ideas how this happened?
How can I force regsvr32 to register the interfaces?
Updated 7-Nov-12 15:37pm
Sounds weird, but who knows? You never told us what it is. I assume you don't have the source code, do you?
PaulowniaK 6-Nov-12 22:52pm
The COMs are all developed in-house and I have source codes to them, but I can't disclose any part of it, I hope you understand...

Also there is far too much of it for me to understand them all, so frankly, they are all black boxes, except that I have had a go poking around the project settings and the IDL file.
skydger 7-Nov-12 0:15am
So do you have type library for this? What OleView tells about it? Is it .NET COM visible library or ATL?
PaulowniaK 7-Nov-12 0:24am
Yes, I do have access to the type library.

OK, second edit...

Opening the "correct"(!!!) DLL using the correct procedure in OLE Viewer results in what resembles the IDL file very closely to be displayed.
No, I don't understand non-disclosure. You are asking for help and not disclosing. Well, seek help in your organization then, or create a code sample not having sensitive information. Now I hope you understand.

Otherwise... I know such a joke.

A very drunk man takes a taxi. A taxi driver asks:
--"Where to?"
--"None of your business, you swine!"


Well yes, in certain cases I used to answer some question myself having no code sample. Unfortunately, in this situation I have no idea how to do that without some code to reproduce the problem...

PaulowniaK 7-Nov-12 0:27am
I take your point, but in which case, which part do you need? Since the problem is that I don't know what the problem is I'm having trouble extracting the relevant part to write a pseudo code.
I don't need anything, probably you do... :-)

I don't know, really. Usually, I advice the following: the part of your real code is often useless. Rather, you need to create some complete code sample, but make is as simple as possible, focused only on one problem you want to reproduce. When you reduce it to a bare minimum, eventually the problem may disappear, and this gives you the idea already. But it the problem is still reproduced and you did not get an idea, the code becomes more suitable for putting in the question ("Improve question", above).

I cannot guarantee anything at all. And I do understand that creation of such sample would be difficult, but what would be your other choice (wait for other experts? maybe...)? And (between you and me :-), COM is old obsolete trash, created a while ago for an intermediate platform between non-OOP OS and a number of OOP languages... morally dead.

PaulowniaK 7-Nov-12 1:02am
Well, actually, I was beginning to think about rewriting the COM from scratch and see where it falls over. It's great to get someone else telling me that as well. Thanks.

I'd love to get rid of this entanglement of obsolete and new technology too!
I understand perfectly what you mean.
Wish you the best of luck,

If your object can be registered without problems with regsvr32 then
you should check if your COM dll consist of type library. As it require to make exports automatially. To check it use "OLE-COM Object Viewer" tool (it comes with VS and or SDK). In there select "View TypeLib" and choose your file. If there is no type library then you should to know your objects GUIDs in that DLL and what interfaces they supports; and then you can create managed wrapper but manually. Also usefull tool is "tlbimp.exe" which used to make .NET COM import. NOTE type library can be in separate file usually with same name and "*.tlb" extension - then you should load and import this file.

PaulowniaK 7-Nov-12 0:39am
Hi Thanks for your help.
I had a look with OLE Viewer and found that indeed it is having problems with the type library.
I understand the use of tlbimp but I'm wondering why all other COMs got added without tlbimp but this one is having problems?

I modified the .rc file and added




which I thought did the trick.
Maxim Kartavenkov 7-Nov-12 1:35am
Type library it is description of what your COM dll is exports - so all applications can use your interfaces and declarations, but if you want this information to be private and only you will be know how to work with your objects then you can hide that info and do not export type library.
The DllRegisterServer function wasn't calling AfxOleRegisterTypeLib.

Stupidly simple now that I know what it is, but gosh, it's been a hard week!

Thanks to everyone who made suggestions. They all helped point me in the right direction in the end.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900