|Important||This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here. ArchiveDisclaimer|
The .NET remoting infrastructure requires the proper metadata to connect an object in one application domain to an object in another domain. In all cases, the client application domain must possess the metadata of the remote object that it intends to use. The important issues to remember are as follows:
For server-activated objects, the assembly name that contains the type must be the same on both the client and the server, and the type name must be identical. This is because type identity is determined using the type and assembly name combination, including the assembly version and any strong-name information.
For client-activated objects, the assembly name that contains the type must be the same on both the client and the server, and the type name must be identical. In addition, the client must have an actual implementation of the remote type, and all the members must have the exact same signature as the corresponding members on the server implementation.
The client implementation does not need to be the server implementation. If you do not want the client to have access to the server implementation, you can build a stand-in library that fulfills all the above requirements, but contains stubbed-out members that throw a NotSupportedException exception. The Soapsuds tool (Soapsuds.exe) does this for clients using SOAP serialization. You can do this for any published marshal-by-reference type using any channel.