tags:

views:

29

answers:

2

Hi,

We have a project that references COM+ components (written in VB6). The components are added to our .Net solution by 'Add reference'. This works well and even intellisense works.

Now and then the interfaces (compatability) of the components are broken and our .Net code doesn't work anymore. The component was added with a specific GUID, that GUID isn't registered anymore.

The question: Is it possible to call the COM+ components in the same way as we are used to (no reflection allowed), without having to update the references in our .Net solution. For instance by creating a wrapper for the COM+ component on basis of filename?

Regards, M.

+3  A: 

No, .NET (as well as any native program) will not be able to instantiate a COM component without knowing the right GUID.

Your best bet is to prevent that component from changing GUIDs in the first place turn on binary compatibility in the component project and maintain the interfaces to remain compatible. Once you break interfaces compatibility you'll have to readd the component to your program so that a new valid reference is created. That's not because .NET is dumb, that's because once you broke the interfaces compatibility you need to recompile the client.

sharptooth
I will choose this as the answer and I will solve my problem for now by shoving an extra component between .Net and the target component. In that way the reference always stays the same and I don't have to regenerate the COM Interop.
Michel van Engelen
+2  A: 

When you add a reference to a COM object, Visual Studio automatically creates an 'Interop' for you. This interop is essentially a wrapper class responsible for loading the COM object, and contains p-invoke statements for making the function calls.

If your COM object is changing - you could either re-add the reference every time the COM object gets updated, or you could generate the Interop yourself.

You can do this using the tlbimp tool:

TlbImp.exe "MyCOMClass.dll" /out:Interop.MyCOMClass.dll

Now if you simply add a reference to the Interop.MyCOMClass.dll instead of the COM object, then if the COM oject changes, you can simply regenerate the Interop with the statement above and distribute it along with the new version of the COM object.

John Sibly
And that's the thing, I don't want to regenerate the COM Interop.
Michel van Engelen