Share via


remoting versioning

There are two types of remotable objects, wellknown and client activated. The server controls which version of the type its publishing (either using registerwellknownservertype or using RemotingServices.Marshal). Whereas for client-activated objects the client has the option of choosing what version of the type it needs to load. Hence adding version information to a wellknown type's assembly qualified name is disallowed on the client and specifying version information while configuring a CAO is disallowed on the server. Thus if a client asks for a particular version of a type which is missing on the server the call will fail.

Theres a different behaviour for serializable types which are passed between client and server. In v1 and v1.1 you can choose a loose versioning behaviour by setting includeVersions="false" in the binary or soap sink providers. This would aid in interoping between different version of the serializable type, provided the shape of the type hasnt changed between versions. Setting includeVersions="true" (which is also the default will mean a strict binding and the deserialization will fail if the exact version couldnt be loaded.