How can I wrap a COM object in a native .NET class?

Question

I\'m using an extensive existing COM API (could be Outlook, but it\'s not) in .NET (C#). I\'ve done this by adding a \"COM Reference\" in Visual Studio so all the \"magic\" is

Answer 1

You, yourself aren't dealing with COM objects. You are already dealing with a facade that was created the moment you added a reference to the COM binary to your project. (.NET) will generate a facade for you, therefore simplifying the task of using COM objects to simply using regular .NET classes. If you do not like the interface that's generated for you, you should probably create a facade to the existing facade. You don't have to worry about COM intricacies, because that's already been done for you (there may be some things you do need to worry about, but I think they are few and far between). Just use the class as a regular .net class because that's exactly what it is, and deal with any problems as they arise.

EDIT: One of the problems you might experience is nondeterministic COM object destruction. The reference counting that's taking place behind the scenes relies on garbage collection so you can't be sure when your objects will be destroyed. Depending on your application you may need more deterministic destruction of your COM objects. To do this you would use Marshal.ReleaseComObject. If this is the case, then you should be aware of this gotcha.

Sorry, I would post more links, but apparently I can't post more than 1 without first getting 10 reputation.

Answer 2

It sounds like you are looking to create a simpler .NET API around your complex COM API. As nobugz said, your ComObject classes are real, native .NET objects that internally contain the unmanaged references to your actual com objects. You don't need to do anything funky to manage them...just use them like they are normal .NET objects.

Now, in regards to presenting a "prettier face" to your .NET consumers. There is an existing design pattern for this, and its called a Facade. I am going to assume that you only really need a part of the functionality that these COM objects provide. If that is the case, then create a facade layer around your com interop objects. This layer should contain the necessary classes, methods, and support types that provide the neccesary functionality to all of the .NET clients with a friendlier API than the com objects have themselves. The facade would also be responsible for simplifying oddities like converting whatever the com objects do for events with normal .NET events, data marshaling, simplification of com object creation, setup, and teardown, etc.

While in general, abstractions should be avoided, as they tend to add work and complexity. However sometimes they are necessary, and in some cases can greatly simplify things. If a simpler API can improve the productivity of other team members who need to consume some of the functionality provided by a very complex com object system, then an abstraction provides tangible value.

Answer 3

You are making it unnecessarily difficult. It is not a "handle", there's no need for reference counting. A __ComObject is a regular .NET class and subject to normal garbage collection rules.

Answer 4

The biggest problem I've found with bringing COM objects into .NET is the fact that the garbage collector runs on a different thread and the final release of the COM object will often (always?) be called from that thread.

Microsoft deliberately broke the COM threading model rules here which state that with apartment threaded objects, all methods must be called from the same thread.

For some COM libraries this is not a big deal, but for others it's a huge problem - particularly for libraries that need to release resources in their destructors.

Something to be aware of...