locked
Will adding a KnownType break existing clients RRS feed

  • Question

  • HI

    Will adding a KnownType to a datacontract break existing clients that do not refresh their proxy?

    Thanks

    Tuesday, April 24, 2012 3:52 PM

Answers

  • It will break the client if you return an instance of the known type for that data member. Thus, adding KnownType is backwards compatible for Request messages but not for Response messages.
    • Proposed as answer by ecabiac Tuesday, April 24, 2012 6:05 PM
    • Marked as answer by DP7 Tuesday, April 24, 2012 6:39 PM
    Tuesday, April 24, 2012 5:26 PM
  • Hi Ecabiac

    Thanks for the reply.  So, if I have a new property to add, and that property is only applicable to a particular sub-type, there is now way of adding the Knowtype without versioning the service (so that existing clients don't break).  Is this true?  Thanks in advance I could add the property to the base class, it just won't mean anything to particular users.

    DP

    This depends greatly on your specific implementation. In general I would say yes, but there are other strategies that can be employed. For instance, it is possible to "version" a message (as opposed to the service) by using a field in the message header or body to indicate which version is being used. You could then ensure that the "new" type is never returned to the client unless their version is higher than X.

    Although SvcUtil uses the "KnownType" mechanism to generate contracts based off of existing inheritance schemes, be aware that OO inheritance doesn't always mesh well with XML Schemas. The KnownType is a much more useful feature coming from the XSD side where an existing XSD uses <xs:choice> or <xs:any> tags.

    Another option that is useful in many situations is instead of creating a subclass for an additional property, you can often get away with adding the property to an existing class. As long as the client proxy uses IExtensibleDataObject (which I believe is default if you are using SvcUtil to generate the client proxies) then your existing clients won't have any issues when these "extra" fields start coming over the wire.

    • Marked as answer by DP7 Friday, May 17, 2013 11:58 AM
    Wednesday, April 25, 2012 9:03 PM

All replies

  • It will break the client if you return an instance of the known type for that data member. Thus, adding KnownType is backwards compatible for Request messages but not for Response messages.
    • Proposed as answer by ecabiac Tuesday, April 24, 2012 6:05 PM
    • Marked as answer by DP7 Tuesday, April 24, 2012 6:39 PM
    Tuesday, April 24, 2012 5:26 PM
  • From a test I just did the client was not broken. However I think in theory there might be some risk since previously there was one type (no known types) so the clients do not send the type name with each request. Now there are a few types (known types) and new clients will send the type name. Old clients still do not send it - so how would WCF know which type is it? From the test I did WCF will pick the base type in this case, so assuming you do not make it abstract and the known types just derive from it you should be ok. Of course you need to test this in your case.

    http://webservices20.blogspot.com/
    WCF Security, Interoperability And Performance Blog

    Tuesday, April 24, 2012 5:48 PM
  • Hi Ecabiac

    Thanks for the reply.  So, if I have a new property to add, and that property is only applicable to a particular sub-type, there is now way of adding the Knowtype without versioning the service (so that existing clients don't break).  Is this true?  Thanks in advance I could add the property to the base class, it just won't mean anything to particular users.

    DP

    Tuesday, April 24, 2012 6:47 PM
  • Hi Ecabiac

    Thanks for the reply.  So, if I have a new property to add, and that property is only applicable to a particular sub-type, there is now way of adding the Knowtype without versioning the service (so that existing clients don't break).  Is this true?  Thanks in advance I could add the property to the base class, it just won't mean anything to particular users.

    DP

    This depends greatly on your specific implementation. In general I would say yes, but there are other strategies that can be employed. For instance, it is possible to "version" a message (as opposed to the service) by using a field in the message header or body to indicate which version is being used. You could then ensure that the "new" type is never returned to the client unless their version is higher than X.

    Although SvcUtil uses the "KnownType" mechanism to generate contracts based off of existing inheritance schemes, be aware that OO inheritance doesn't always mesh well with XML Schemas. The KnownType is a much more useful feature coming from the XSD side where an existing XSD uses <xs:choice> or <xs:any> tags.

    Another option that is useful in many situations is instead of creating a subclass for an additional property, you can often get away with adding the property to an existing class. As long as the client proxy uses IExtensibleDataObject (which I believe is default if you are using SvcUtil to generate the client proxies) then your existing clients won't have any issues when these "extra" fields start coming over the wire.

    • Marked as answer by DP7 Friday, May 17, 2013 11:58 AM
    Wednesday, April 25, 2012 9:03 PM
  • Thanks Ecabiac!  Useful information!
    Thursday, April 26, 2012 4:27 PM