COM objects are not serializable as such, but when writing a COM object, you're supposed to use sophisticated proxy / stub definition - althouh in general, undercover, you don't really have to think about it, especially if these objects are written using some framework (ATL, delphi, VB6, .NET, etc.).

These proxies / stubs will at compile time or runtime use powerful RPC mechanisms (which is more or less "DCOM") if the client-server communication works out-of-process or across threads (COM "apartments" in fact).

All this to say that if your COM objects are in-process servers and were correctly built, COM provides free services to host them as "COM+ applications".

By creating logical groups of COM components as COM+ applications, you can take advantage of the following benefits of COM+: Component dynamic-link libraries (DLLs) loaded into processes (DLLHost.exe) on demand and Managed (nothing to do with .NET here) server processes to host components.

If you put your object in a COM+ Application, then you should be able to use it from .NET code just like it was in-process, but now hosted in a special "surrogate" system-provided host process (which happens to be the famous dllhost.exe). You can even configure it to become a full Windows service as shown here in the "Activation" tab of the application configuration: