Implement IMarshalonly when you believe that you can realize significant optimizations to COM's default implementation. In practice, this will rarely be the case. However, there are occasions where implementing IMarshalcan be preferred:

• The objects you are writing keep their state in shared memory. In this case, both the original process and the client process uses proxies that refer to the shared memory.
  
  This type of custom marshaling is possible only if the client process is on the same machine as the original process. COM-provided implementations of IStorageand IStreamare examples of this type of custom marshaling.
  
  
• The objects you are writing are immutable, that is, their state does not change after creation. Instead of forwarding method calls to the original objects, you simply create copies of those objects in the client process.
  
  This technique avoids the cost of switching from one process to another. Some monikers are examples of immutable objects; if you are implementing your own moniker class, you should evaluate the costs and benefits of implementing IMarshalon your moniker objects.
  
  
• Objects that themselves are proxy objects can use custom marshaling to avoid creating proxies to proxies. Instead, the existing proxy can refer new proxies back to the original object.
  
  This capability is important for the sake of both efficiency and robustness.
  
  
• Your server application wants to manage how calls are made across the network without affecting the interface exposed to clients.
  
  For example, if a user were making changes to a database record, the server might want to cache the changes until the user has committed them all, at which time the entire transaction would be forwarded in a single packet. Using a custom proxy would enable the caching and batching of changes in this way.
  
  

When you choose to implement IMarshal, you must do so for both your original object and the proxy you create for it. When implementing the interface on either object or proxy, you simply return E_NOTIMPL for the methods that are not implemented.

COM uses your implementation of IMarshalin the following manner:

• When it is necessary to create a remote interface pointer to your object (that is, when a pointer to your object is passed as an argument in a remote function call), COM queries your object for the IMarshalinterface.
  
  
• If your object implements it, COM uses your IMarshalimplementation to create the proxy object.
  
  
• If your object does not implement IMarshal, COM uses its default implementation.
  
  

How you structure the proxy is up to you:

• You can write the proxy to use whatever mechanisms you deem appropriate for communicating with the original object.
  
  
• You can also create the proxy as either a stand-alone object or as part of a larger aggregation such as a handler.
  
  

However you choose to structure the proxy, it must implement IMarshalto work at all. You must also generate a CLSID for the proxy to be returned by your implementation of IMarshal::GetUnmarshalClasson the original object.

COM calls this interface as part of system-provided marshaling support. COM's calls are wrapped in calls to CoMarshalInterfaceand CoUnmarshalInterface.

Your code typically will not need to call this interface. Special circumstances where you might choose to do so are discussed in the Notes to Callers section for each method.

To determine whether the platform supports this interface, see Determining Supported COM APIs.