Nel ciclo di vita di un'applicazione non è raro dover far fronte a modifiche in seguito al rilascio del prodotto finale, per adeguamenti, nuove richieste o funzionalità aggiuntiva. Non sono da meno i servizi realizzati in Windows Communication Foundation che se definiti sia partendo dal WSDL (contract-first) o dalla interfaccia .NET (code-first) necessitano di un'attenzione particolare rivolta a rendere i servizi aperti a future modifiche o aggiunte, mantenendo la retrocompatibilità con i client vecchi del servizio. Nel primo caso gli schema XSD possono prevedere elementi di tipo anyType, così da poter inglobare futuri dati che la prima versione del servizio può ignorare.

In un approccio code-first, invece, occorre far sì che le proprie entità siano aperte a memorizzare dati utilizzati da future versioni dell'entità, in modo da farle transitare tra client e server, ignorandone il contenuto. In WCF per effettuare ciò basta implementare l'interfaccia IExtensibleDataObject che contiene una sola proprietà per memorizzare questi dati.

Una tipica classe Product versione 1 potrebbe essere quindi questa:

public class Product : IExtensibleDataObject
{
    ExtensionDataObject _extensionData;
    
    ExtensionDataObject IExtensibleDataObject.ExtensionData
    {
        get
        {
            return _extensionData;
        }
        set
        {
            _extensionData = value;
        }
    }
    
    [DataMember(Order = 1)]
    public string Name { get; set; }
}

In futuro, la seconda versione della classe Product potrebbe includere un nuovo capo:

public class Product2 : IExtensibleDataObject
{
    ExtensionDataObject _extensionData;
    
    ExtensionDataObject IExtensibleDataObject.ExtensionData
    {
        get
        {
            return _extensionData;
        }
        set
        {
            _extensionData = value;
        }
    }
    
    [DataMember(Order = 1)]
    public string Name { get; set; }

    [DataMember(Order = 2)]
    public string Category { get; set; }
}

L'uso dell'interfaccia IExtensibleDataObject manterrà funzionante il client che conosce la versione 1 e il client che conosce la versione 2, nonostante il servizio si sia evoluto. Si noti per ultimo l'uso della proprietà Order dell'attributo DataMember, utile per forzare l'ordine di definizione dei membri, al fine di evitare fraintendimenti nella serializzazione e deserializzazione.