CODEWITHSUNDEEP
c#wcfserializationdeserialization
Jay
Jay

Reputation: 2703

Serialization between client and server with different referenced versions

I have a windows service that references an assembly which contains the following class. 

 [Serializable]
 public class User
    {
        public User(string userName)
        {
            UserName = userName;
        }

        public string UserName { get; private set; }
    }

This service has a method to allow us to create a User:

public User CreateUser(User user)
        {
        //Create and return user
    }

Through remoting we are able to call this method in the service that takes in User object from our application. The application references the same assembly that the service does for the User class but it forces a specific 1.0.0.0 version.

CreateUser(User user);

We would like to change the existing assembly that is referenced from each project to add a new property "Phone" to the User class. 

 [Serializable]
 public class User
    {
        public User(string userName)
        {
            UserName = userName;
        }

        public string UserName { get; private set; }
        **public string Phone { get; set; }**
    }

We will increment the assembly version from 1.0.0.0 to 2.0.0.0. The windows service will have a reference to the 2.0.0.0 version of the assembly in the GAC. Because some of our clients are slow at upgrading and they force specific versions of the assembly or copy it local they will still be referencing the 1.0.0.0 version.

With this change to the service assembly reference the marshaller that deserializes/serializes the object from the service to the application throws a serialization error. "The formatter threw an exception while trying to deserialize the message: There was an error while trying to deserialize parameter..."

The change we made should be a non breaking change since we just added additional feature. Is there a way to allow the existing application continue and use the 1.0.0.0 version of the assembly and serialize the 2.0.0.0 without the new property down to them without some convoluted conversion on the service?

UPDATE:

We are using the following to connect over to our service

marshaller = ChannelFactory<T>.CreateChannel(new NetTcpBinding() { MaxReceivedMessageSize = MaxResponseSize }, new EndpointAddress(new Uri(new Uri(servers[serverIndex]), serviceName)));

Inner exception: http://tempuri.org/:CreateUserResult. The InnerException message was ''EndElement' 'CreateUserResult' from namespace 'http://tempuri.org/' is not expected. Expecting element '_someOtherField'.'. Please see InnerException for more details ...Next inner is null

Upvotes: 2

Views: 2570

Answers (2)

Marc Gravell
Marc Gravell

Reputation: 1063774

As I suspected, here's the problem;

NetTcpBinding

(from your edit). Basically, WCF includes some nice friendly contract-based support, and some less-than-friendly type-based support.

If at all possible, I would suggest the simplest option here is to not use NetTcp as it by default uses NetDataContractSerializer (type-based), so will have versioning issues. Alternatively, you can use oter serializers on the transport - for example DataContractSerializer of protobuf-net. However, changing this would itself be a breaking change.

I gather it is possible to use a custom binder with NetDataContractSerializer - see Problem deserializing with NetDataContractSerializer after refactoring code . If you can get that working it should preserve the API, but it should not be underestimated; I think that will be a maintenance burden, in all honesty. I'd rather cut my losses, break the API once and switch to a contract-based serializer.

Upvotes: 2

Jonas W
Jonas W

Reputation: 373

Maybe the OptionalField attribute works for you, depending on the formatter, see http://msdn.microsoft.com/en-us/library/system.runtime.serialization.optionalfieldattribute.aspx.

Upvotes: 0

Related Questions