将 C++ COM object 更新为 C#

Question

We have a COM interface declared and implemented in unmanaged C++. We no longer wish to maintain this assembly, but do need to make some changes, and still be backward compatible.

What I want to do, is to write all the new code in C#, and make it ComVisible. From this thread I see a reference to TreatAs to replace the old interface.

I was thinking along the same path as Jonathan Peppers regarding ProgId, Guid, etc. I will implement the exact interface as the old version as a wrapper to the new implementation. I am also thinking about adding MarshalAs attributes exactly as in the generated interop wrapper to be sure the data types will be the same, if possible.

Are there anything else I should consider while working with this? Anyone with experience doing this conversion?

EDIT: I do have the IDL file for the server. I am not sure if there is a way I can auto generate the code based on this. COM is not something I'm very familiar with.

EDIT Q: How should I deal with HRESULT used by existing clients?

ADDED: Figured I should point other readers to a different fix , which is not available for my scenario as I can't recompile all the .NET applications using the existing com:

Bjørnar Sundsbø

Answer 1

One quick way to get started:

• Import your existing COM object into C# with tlbimp (or Visual Studio)
• Load up .Net Reflector and get the generated interface to put in your new project
• Implement the generated interface in C#
• Switch any import declarations to export instead

This should get all your types and method signatures correct from the start. It is a great starting point for porting an existing COM interface to C#.

Answer 2

It seems to be by design to prevent managed COM object from being used from a managed client.

Here are some links to the same problem , as well as this thread , providing some solutions. Also take a look at the answer Jonathan Peppers provided to see how to start out if you only need to use it from unmanaged applications.

The only way I figure I could work around this, is a messy solution where I create the new code in C#, add a COM layer on top of that. Then create an additional COM layer as unmanaged C++ which accesses the first layer so, that my .NET applications can access it. {Unmanaged COM exposing the original interface} => {Managed COM with rewrite of the original logic of the COM}. All existing applications will then access the "{Unmanaged COM...}". If I get desperate enough, that might be a way. For now I'm abandoning this approach and looking for other solutions.

If you can, recompile your managed application to use the new assembly, do so. You can still use that managed COM from VB6, unmanaged C++, etc. If you still need to reference as a COM from managed, you might be able to create new instances using the approach specified in one of the referenced posts , as long as you don't need to create an interop wrapper.