HOWTO add aggregate .NET COM Interop to an ATL EXE Server??

Question

Hello,

I would like to know how one can add a .NET C# COM object (created using the COM Interop facility of .NET) to a Visual Studio 2008 ATL EXE Server. Basically, I am trying to create an out of process Automation server to hold my C# COM object to allow it to act as a Singleton server for many clients. I think all I need to do is add the proper entries to the ATL EXE Server's IDL file? Does this sound right? Would anybody also have any idea how to actually instantiate my C# COM object then? I am guessing I need to redefine its GUID otherwise it would just instantiate the C# one right away? Thanks for any help.

-David

For Example: .

import "oaidl.idl";
import "ocidl.idl";

[
 uuid(A9F9E81F-D5FE-4718-8078-E8378CFB3D3C),
 version(1.0),
 helpstring("Libreria dei tipi SSOLoginDLLServer 1.0")
]
library SSOLoginDLLServerLib
{
 importlib("stdole2.tlb");
 import "SSOLoginDLL.tlb";   <-- Reference included to my C# project which creates the TLB
 [
  uuid(A8FD5BC5-3B8D-4828-B9CB-6496A7A6D9B9)
 ]
 coclass CSSOLogin
 {
  [default] interface ISSOLogin;
  [default, source] dispinterface ISSOLoginEvents;
 };
};

Answer 1

So you have one COM object (your ATL server), which exists for the sole purpose of giving clients access to another COM object (the C# object). It's important to note that you're not talking about giving clients access to the TYPE (i.e. they will instantiate their own instance of the C# object) but rather to the actual INSTANCE.

So your ATL server needs to define and implement an interface that provides the necessary access. You could either just return the C# object:

MyInterface
{
    IUnkown GetThatComObject();
}

in which case the client will also need to know all the type definitions from the C# library, so that they can work with this object once they get it.

or you could wrap it, so that clients only need to know about your primary type library:

MyInterface
{
    bool TellThatComObjectFoo();
    int TellThatComObjectBar();
    // etc.
}

Either way, I think this is what you mean when you are asking '[would I] need to redefine its GUID' -- yes, the types (and their GUIDs) defined by your ATL server need to be independent distinct from the other classes they happen to use.

(BTW, sorry I'm not giving you correct IDL or anything here ... I haven't actually created a COM object since 1999.)

Answer 2

I guess my next question would be, where does the C# COM instance actually gets stored, I mean how would the ATL EXE Server keep track of all the outstanding references of COM Objects (the specs say that it will automatically shut down when all COM references to the objects it has given out are released), is this done through the weird ATL macros?? Any good book to buy to understand the actual programmatic details, the ideas are fairly clear but some coding examples would be useful? Thanks again for the help.

Answer 3

I hope this gets printed as a comment and not as an answer (not sure how to force it to do that though)! I actually was using a COM+ server before and not trying to use an ATL EXE Server, but the problem is that I need my clients of the C# COM Object to be able to register for it's COM events. In COM+ I was using the transient subscriber model, and it was actually working with transient subscriptions. However, unfortunately, to register transient subscriptions the user needs to have Administrator Privileges, so an ordinary user was making my app crash in Windows. Permanent subscriptions had the problem of instantiating a new client subscriber everytime an event fired, which doesn't fit my programming model. So thats why I am trying to figure out the ATL EXE, which should create more/less one C# COM object for all Clients to subscribe to.

-David