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

Question

Un proyecto en el que estoy trabajando requiere la serialización de una estructura de datos antes de cerrar y restaura su estado a partir de estos datos serializados cuando se inicia de nuevo.

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

• nuestro código se ejecutó en .NET 2.0
• un cliente actualizado con algún software que de alguna manera establece 1.1 como predeterminado
• nuestro código se ejecutó en .NET 1.1 y no pudo deserializar su estado almacenado

Este problema en particular fue " resuelto " restringiendo esa actualización de software en particular, y no debería ser un problema ahora que estamos apuntando al marco .NET 2.0 (por lo que no podemos ejecutar en 1.1).

¿Cuál es la posibilidad de que esta serialización vuelva a cambiar de forma incompatible entre los marcos 2.0 y los más nuevos? 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, ¿se garantiza que siempre se instalará un marco 2.0.50727 incluso después de las actualizaciones de .NET? Punteros a la documentación de Microsoft son bienvenidos.

Answer 1

Las posibilidades son bajas (¡pero no cero!) de que haya cambios entre las versiones de framework. La intención sería que debería poder utilizar la serialización binaria y la comunicación remota para comunicarse entre un cliente y un servidor que ejecuta diferentes versiones de framework. La incompatibilidad entre .NET 1.xy 2.0 es un error para el cual hay un parche disponible.

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

No puede garantizar que .NET Framework 2.0 siempre se instalará en futuras versiones de Windows. Pero estoy seguro de que Microsoft trabajará duro para garantizar que la mayoría de las aplicaciones .NET 2.0 se ejecuten sin cambios en .NET 4.xy versiones posteriores. No tengo referencias 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

La regla general es generalmente: la serialización XML debería poder sobrevivir a las nuevas versiones de framework y, por lo tanto, puede almacenarse a largo plazo, pero la serialización binaria no puede (y, por lo tanto, solo debe ser transitoria).

Answer 3

¿Qué serializador estás usando? En muchos sentidos, un serializador como XmlSerializer o DataContractSerializer lo protege de muchos detalles y ofrece opciones de extensibilidad más simples. En algún momento, sin duda será necesaria una nueva versión de CLR, por lo que no creo que nadie pueda ofrecer ninguna garantía sobre 2.0.50727; sin embargo, debes estar seguro a corto plazo. Y espero menos cambios importantes ...

[actualizada siguiente nota en otra respuesta]

Si desea un formato binario por razones de espacio / rendimiento, entonces otra opción es usar un serializador binario diferente. Por ejemplo, protobuf-net funciona en todas las variantes .NET *, pero el binario El formato (ideado por Google) es compatible con múltiples plataformas (Java, C ++, etc.), lo que lo hace muy portátil, rápido y pequeño.

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

Answer 4

Si la compatibilidad es una preocupación, el ISerializable interfaz podría ser la cura que estás buscando. Esta interfaz le brinda más control sobre cómo se serializan los artículos. Para obtener más información, pruebe este artículo sobre msdn .

Answer 5

Tengo dos cosas que agregar a las otras respuestas ...

Primero, haciendo uso de un SerializationBinder puede ayudarlo a superar muchas dificultades al importar datos serializados heredados.

Segundo, considero obligatorio escribir extensas pruebas unitarias para cualquier dato persistente. Siempre hago 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 de cada versión lanzada de su aplicación. Importe los datos y verifique que todo vuelva como se esperaba.

Answer 6

No tiene que usar XML para obtener una mayor flexibilidad y control de versiones.

He usado la biblioteca de código abierto de Simon Hewitt, consulte Optimización de la serialización en .NET - parte 2 en lugar de la serialización predeterminada de .NET. Ofrece algo de automatización, pero esencialmente puede controlar el flujo de información que se serializa y deserializa. Para versionar la versión (archivo) se puede serializar primero y al tiempo de deserialización la forma en que se interpreta el flujo de información depende de la versión.

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

Como beneficio adicional, 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).