Data Contract Versioningを読んだ後、それがすべてではないという結論に達しました。たとえば、以前は ValueA があり、新しいバージョンでは ValueB と呼ばれ、別の型になっている場合、ValueA を ValueB に変換する必要がある場合はどうなるでしょうか。
これを支援するために使用できるコールバックがいくつかありますが、フォーマットが長期間にわたって頻繁に変更されることが予想される場合、それはあまり保守可能なソリューションのようには見えません。
私たちが解決した解決策は、「バージョンごとに保存」フィールドを保持し、ファイルのロード時に、必要に応じて古いバージョンに固有の変換ルーチンを呼び出すことです。これらの変換ルーチンは、古いデータの XML を新しいデータの XML に変換する方法を知っています。
ただし、結局のところ、DataContractSerializes では、要素の順序が期待どおりである必要があります。これは、変換プロセスが要素を正確に正しい場所に挿入することを認識している必要があることを意味します。継承を考慮すると、既知の名前を持つ要素を単純に追加するよりも、これははるかに困難です。継承では、この新しいフィールドの隣に常に単一のフィールドがないという理由だけで、どのフィールドAddBeforeSelfもAddAfterSelf 確実に継承することはできません。
DataContractSerializer が非常に厳密になった理由はさておき、これを回避する方法を提案していただけますか? おそらく、非常に古いデータ コントラクトとの下位互換性を維持する方法に関する優れた記事であり、100 回目の破壊的変更をフォーマットに加えた時点で扱いにくくなることはありません。
この記事には追加のガイドラインがいくつかありますが、これは別の目的で書かれたに違いありません。たとえば、古いデータ メンバーを永遠に放置しておくことはできません (ポイント 9)。そのような記事のほとんどは、データをファイルに保存するのではなく、通信プロトコルの観点から書かれているようです。