Estabilidad de la serialización .NET en diferentes versiones de framework

Question

Un proyecto en el que estoy trabajando requiere serializar una estructura de datos antes de apagar y restaurar su estado a partir de estos datos serializados cuando se reinicia.

año pasado, estábamos construyendo para .NET 1.1, y encontramos con un problema complicado, donde

• nuestro código funcionó en .NET 2.0
• un cliente mejorado con algún tipo de software que de alguna manera fija 1.1 como predeterminado
• nuestro código funcionó en .NET 1.1 y no pudo deserializar su estado almacenado

Este tema en particular fue "resuelto" por la restricción de que la actualización de software en particular, y no debe ser un prob ahora que estamos apuntando al framework .NET 2.0 (por lo que posiblemente no podamos ejecutar en 1.1).

¿Cuál es la probabilidad de que esta serialización vuelva a cambiar de manera incompatible entre 2.0 y frameworks más recientes? Si usamos <supportedVersion> para arreglar nuestro código a 2.0.50727, ¿cuáles son las posibilidades de cambios entre 2.0.50727.1434 y 2.0.50727.nnnn (alguna versión futura)? Las estructuras de datos que se serializan son matrices, mapas, cadenas, etc. de las bibliotecas de clases estándar.

Además, ¿está garantizado que siempre se instalará un marco 2.0.50727 incluso después de nuevas actualizaciones .NET? Bienvenido a la documentación de punteros a Microsoft.

Answer 1

Las posibilidades son bajas (pero no nulas) de que habrá cambios entre las versiones del marco. La intención sería que usted pueda usar la serialización binaria y la comunicación remota para comunicarse entre un cliente y un servidor que ejecute versiones de framework diferentes. La incompatibilidad entre .NET 1.x y 2.0 is a bug para el que hay un parche disponible.

Sin embargo, la serialización binaria tiene otros problemas, especialmente soporte deficiente para versionar la estructura que está serializando.Desde el caso de uso que ha descrito, la serialización Xml es la elección obvia: DataContractSerializer es más flexible que XmlSerializer si no le importa la dependencia de .NET 3.x.

No se puede garantizar que .NET Framework 2.0 siempre esté instalado en futuras versiones de Windows. Pero estoy seguro de que Microsoft trabajará arduamente para garantizar que la mayoría de las aplicaciones .NET 2.0 se ejecuten sin cambios en .NET 4.xy versiones posteriores. No tengo ninguna referencia para esto: cualquier compromiso de este tipo en cualquier caso solo se aplicaría realmente a la próxima versión de Windows (Windows 7).

Answer 2

¿Qué serializador estás utilizando? En muchos sentidos, un serializador como XmlSerializer o DataContractSerializer le almacena en búfer desde muchos detalles, y proporciona opciones de extensibilidad más simples. En algún momento, sin dudas será necesaria una nueva versión de CLR, por lo que no creo que nadie pueda dar garantías sobre 2.0.50727; sin embargo, deberías estar seguro a corto plazo. Y espero para un menor número de cambios de ruptura ...

[siguiente nota actualizada sobre otra respuesta]

Si desea un formato binario, por razones de espacio/rendimiento, a continuación, otra opción es utilizar un serializador binario diferente. Por ejemplo, protobuf-net funciona en todas las variantes .NET *, pero el formato binario (diseñado por Google) es compatible multiplataforma (Java, C++, etc.), lo que lo hace muy portátil, rápido y pequeño.

* = No lo he probado en micro framework, pero CF, Silverlight, Mono, .NET 2.0, etc. son compatibles.

Answer 3

La regla de oro es en general: la serialización de XML debe poder sobrevivir a las nuevas versiones de marco y por lo tanto se puede almacenar a largo plazo, pero la serialización binaria no puede (y por lo tanto solo debe ser transitoria).

Answer 4

Si la compatibilidad es una preocupación, la interfaz ISerializable podría ser la solución que está buscando. Esta interfaz le brinda más control sobre cómo se serializan los artículos. Para obtener más información, intente esto article on msdn.

Answer 5

que tienen dos cosas que añadir a las otras respuestas ...

En primer lugar, haciendo uso de una costumbre SerializationBinder se puede obtener una gran cantidad de dificultades redondas importadores datos serializados heredados.

En segundo lugar, considero obligatorio escribir extensas pruebas de unidad para cualquier dato persistente. Siempre realizo dos pruebas en particular:

1. Prueba de ida y vuelta: ¿puede serializar y deserializar sus objetos y recuperar exactamente lo mismo?
2. Prueba de importación heredada: asegúrese de tener versiones de datos serializados exportados desde cada versión de su aplicación. Importe los datos y verifique que todo vuelva como se esperaba.

Answer 6

No necesita usar XML para obtener mayor flexibilidad y control de versiones.

He utilizado la biblioteca de código abierto de Simon Hewitt, consulte Optimizing Serialization in .NET - part 2 en lugar de la serialización .NET predeterminada. Ofrece algo de automatización, pero esencialmente usted puede controlar la secuencia de información serializada y deserializada. Para el control de versiones, la versión (archivo) se puede serializar primero y al tiempo de deserialización, la forma en que se interpreta la secuencia de información depende de la versión.

Es bastante simple de hacer, aunque algo tedioso debido a la serialización/deserialización explícita .

Como extra, es 20-40 veces más rápido y ocupa menos espacio para grandes conjuntos de datos (pero puede no ser importante en su caso).