An exported managed server with a type library registered by the Assembly Registration Tool (Regasm.exe) has a ThreadingModel registry entry set to Both. This value indicates that the server can be activated in a single-threaded apartment (STA) or a multithreaded apartment (MTA). The server object is created in the same apartment as its caller, as shown in the following table.

Because the client and server are in the same apartment, the interop marshaling service automatically handles all data marshaling. The following illustration shows the interop marshaling service operating between managed and unmanaged heaps within the same COM-style apartment.

If you plan to export a managed server, be aware that the COM client determines the apartment of the server. A managed server called by a COM client initialized in an MTA must ensure thread safety.

The default setting for .NET client apartments is MTA; however, the application type of the .NET client can change the default setting. For example, a Visual Basic 2005 client apartment setting is STA. You can use the STAThreadAttribute, the MTAThreadAttribute, the Thread..::.ApartmentState property, or the Page..::.AspCompatMode property to examine and change the apartment setting of a managed client.

The author of the component sets the thread affinity of a COM server. The following table shows the combinations of apartment settings for .NET clients and COM servers. It also shows the resulting marshaling requirements for the combinations.

When a managed client and unmanaged server are in the same apartment, the interop marshaling service handles all data marshaling. However, when client and server are initialized in different apartments, COM marshaling is also required. The following illustration shows the elements of a cross-apartment call.

For cross-apartment marshaling, you can do the following:

• Accept the overhead of the cross-apartment marshaling, which is noticeable only when there are many calls across the boundary. You must register the type library of the COM component for calls to successfully cross the apartment boundary.

• Alter the main thread by setting the client thread to STA or MTA. For example, if your C# client calls many STA COM components, you can avoid cross-apartment marshaling by setting the main thread to STA.

  Note:
  Once the thread of a C# client is set to STA, calls to MTA COM components will require cross-apartment marshaling.

For instructions on explicitly selecting an apartment model, see Managed and Unmanaged Threading.

The common language runtime preserves the identity of managed and unmanaged references. The following illustration shows the flow of direct unmanaged references (top row) and direct managed references (bottom row) across process and host boundaries.

In this illustration:

• An unmanaged client gets a reference to a COM object from a managed object that gets this reference from a remote host. The remoting mechanism is DCOM.

• A managed client gets a reference to a managed object from a COM object that gets this reference from a remote host. The remoting mechanism is DCOM.

  Note:
  The exported type library of the managed server must be registered.

The number of process boundaries between caller and callee is irrelevant; the same direct referencing occurs for in-process and out-of-process calls.

The runtime also provides managed remoting, which you can use to establish a communications channel between managed objects across process and host boundaries. Managed remoting can accommodate a firewall between the communicating components, as the following illustration shows.

Some unmanaged calls can be channeled through SOAP, such as the calls between serviced components and COM. For additional information about using managed remoting, see .NET Framework Remoting Overview.