Stabilité de la sérialisation .NET à travers différentes versions du framework

Question

Un projet sur lequel je travaille nécessite de sérialiser une structure de données avant de l'arrêter et de restaurer son état à partir de ces données sérialisées lorsqu'il redémarre.

L'année dernière, nous construisions pour .NET 1.1 et nous avons rencontré un problème épineux:

• notre code a fonctionné sur .NET 2.0
• un client mis à niveau avec un logiciel qui définit en quelque sorte 1.1 comme valeur par défaut
• notre code fonctionnait sous .NET 1.1 et n'a pas pu désérialiser son état stocké

Ce problème particulier était " résolu " en interdisant cette mise à niveau logicielle particulière, et ne devrait plus être un problème maintenant que nous ciblons le framework .NET 2.0 (nous ne pouvons donc pas utiliser la version 1.1).

Quelles sont les chances pour que cette sérialisation puisse à nouveau changer de manière incompatible entre les frameworks 2.0 et les nouveaux? Si nous utilisons <supportedVersion> pour corriger notre code à 2.0.50727, quelles sont les chances de modifications entre 2.0.50727.1434 et 2.0.50727.nnnn (une version future)? Les structures de données en cours de sérialisation sont des tableaux, des cartes, des chaînes, etc. des bibliothèques de classes standard.

De plus, est-il garanti qu'un framework 2.0.50727 sera toujours installé même après d'autres mises à niveau .NET? Les pointeurs vers la documentation Microsoft sont les bienvenus.

Answer 1

Il y a peu de chances (mais pas nul!) qu'il y ait des changements entre les versions du framework. L'intention est que vous puissiez utiliser la sérialisation binaire et la communication à distance pour communiquer entre un client et un serveur exécutant différentes versions de l'infrastructure. L’incompatibilité entre .NET 1.x et 2.0 est un bogue pour lequel un patch est disponible.

Toutefois, la sérialisation binaire pose d’autres problèmes, notamment un faible support pour la gestion des versions de la structure que vous sérialisez. Dans le cas d'utilisation que vous avez décrit, la sérialisation XML est le choix évident: DataContractSerializer est plus flexible que XmlSerializer si la dépendance à l'égard de .NET 3.x ne vous dérange pas.

Vous ne pouvez pas garantir que .NET Framework 2.0 sera toujours installé sur les futures versions de Windows. Mais je suis sûr que Microsoft travaillera d'arrache-pied pour que la plupart des applications .NET 2.0 s'exécutent sans changement sur .NET 4.x et les versions ultérieures. Je n’ai aucune référence à cela: aucun engagement de ce type ne s'appliquerait vraiment à la prochaine version de Windows (Windows 7).

Answer 2

La règle générale est la suivante: la sérialisation XML doit pouvoir résister aux nouvelles versions du framework et peut donc être stockée à long terme, mais pas la sérialisation binaire (et ne doit donc être que transitoire).

Answer 3

Quel sérialiseur utilisez-vous? À bien des égards, un sérialiseur tel que XmlSerializer ou DataContractSerializer vous met en mémoire tampon de nombreux détails et offre des options d'extensibilité plus simples. À un moment donné, une nouvelle version du CLR sera sans doute nécessaire - je ne pense donc pas que quiconque puisse donner des garanties à propos de la version 2.0.50727; vous devriez être en sécurité à court terme, cependant. Et j'espère moins de changements décisifs ...

[mis à jour la note suivante sur une autre réponse]

Si vous souhaitez un format binaire pour des raisons d'espace / performances, une autre option consiste à utiliser un sérialiseur binaire différent. Par exemple, protobuf-net fonctionne sur toutes les variantes .NET *, à l'exception du binaire. Le format (recommandé par Google) est compatible avec toutes les plateformes (Java, C ++, etc.), ce qui le rend très portable, rapide et petit.

* = Je ne l'ai pas essayé sur un micro-framework, mais CF, Silverlight, Mono, .NET 2.0, etc. sont tous supportés.

Answer 4

Si la compatibilité pose un problème, le ISerializable interface pourrait être le remède que vous cherchez. Cette interface vous donne plus de contrôle sur la façon dont les articles sont sérialisés. Pour plus d'informations, essayez cet article sur msdn .

Answer 5

J'ai deux choses à ajouter aux autres réponses ...

Tout d'abord, utilisez un SerializationBinder <> / a> peut vous éviter beaucoup de difficultés pour importer des données sérialisées héritées.

Deuxièmement, j'estime qu'il est obligatoire d'écrire des tests unitaires approfondis pour toutes les données conservées. Je fais toujours deux tests en particulier:

1. Test aller-retour - pouvez-vous sérialiser et désérialiser vos objets et obtenir exactement la même chose?
2. Test d'importation héritée - assurez-vous que les versions des données sérialisées sont exportées à partir de chaque version publiée de votre application. Importez les données et vérifiez que tout rentre comme prévu.

Answer 6

Vous n'avez pas besoin d'utiliser XML pour gagner en flexibilité et en gestion de version.

J'ai utilisé la bibliothèque open source de Simon Hewitt, voir Optimisation de la sérialisation dans .NET - partie 2 au lieu de la sérialisation .NET par défaut. Il offre une certaine automatisation, mais vous pouvez essentiellement contrôler le flux d’informations sérialisées et désérialisées. Pour la gestion des versions, la version (du fichier) peut être sérialisée en premier et à temps de désérialisation la façon dont le flux d'informations est interprété dépend de la version.

C’est assez simple à faire, bien que quelque peu fastidieux en raison de la sérialisation / désérialisation.

En prime, il est 20 à 40 fois plus rapide et prend moins de place pour de grands ensembles de données (mais peut ne pas être important dans votre cas).