Metadata Issues
This topic is specific to a legacy technology that is retained for backward compatibility with existing applications and is not recommended for new development. Distributed applications should now be developed using the Windows Communication Foundation (WCF).
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.
.gif "Note") Note |
|---|
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. |