Стабильность сериализации .NET в разных версиях фреймворка.

Question

Проект, над которым я работаю, требует сериализации структуры данных перед выключением и восстанавливает ее состояние из этих сериализованных данных при повторном запуске.

В прошлом году мы создавали для .NET 1.1 и столкнулись с сложной проблемой, когда

• наш код работал на .NET 2.0
• клиент обновил программное обеспечение, которое каким-то образом установило 1.1 по умолчанию
• наш код работал на .NET 1.1 и не смог десериализовать свое сохраненное состояние

Эта конкретная проблема была «решена» путем запрета данного обновления программного обеспечения, и теперь она не должна быть проблемой, когда мы нацелены на платформу .NET 2.0 (поэтому мы не можем работать на версии 1.1).

Какова вероятность того, что эта сериализация может снова несовместимо измениться между 2.0 и более новыми платформами? Если мы используем <supportedVersion> для исправления нашего кода до 2.0.50727, каковы шансы изменений между 2.0.50727.1434 и 2.0.50727.nnnn (в некоторых будущих выпусках)? Сериализуемыми структурами данных являются массивы, карты, строки и так далее из стандартных библиотек классов.

Кроме того, гарантируется ли, что инфраструктура 2.0.50727 будет всегда установлена ​​даже после дальнейших обновлений .NET? Указатели на документацию Microsoft приветствуются.

Answer 1

Шансы (но не нулевые!) Малы, что будут изменения между версиями фреймворка. Предполагается, что вы сможете использовать двоичную сериализацию и удаленное взаимодействие для связи между клиентом и сервером, на котором работают разные версии платформы. Несовместимость между .NET 1.x и 2.0 - это ошибка , для которой доступно исправление.

Однако двоичная сериализация имеет другие проблемы, особенно слабую поддержку управления версиями сериализуемой структуры. Из описанного вами варианта использования сериализация Xml является очевидным выбором: DataContractSerializer более гибок, чем XmlSerializer, если вы не возражаете против зависимости от .NET 3.x.

Вы не можете гарантировать, что .NET Framework 2.0 всегда будет установлен в будущих версиях Windows. Но я уверен, что Microsoft приложит все усилия, чтобы большинство приложений .NET 2.0 работали без изменений в .NET 4.x и более поздних версиях. У меня нет никаких ссылок на это: любое такое обязательство в любом случае действительно относится только к следующей версии Windows (Windows 7).

Answer 2

Как правило, практическое правило: сериализация XML должна выдерживать новые версии каркаса и, следовательно, может храниться в течение длительного времени, но двоичная сериализация не может (и, следовательно, должна быть только временной).

Answer 3

Какой сериализатор вы используете? Во многих отношениях сериализатор, такой как XmlSerializer или DataContractSerializer, буферизует вас из многих деталей и предоставляет более простые варианты расширяемости. В какой-то момент, несомненно, понадобится новая версия CLR - так что я не думаю, что кто-либо может дать какие-либо гарантии относительно 2.0.50727; Вы должны быть в безопасности в краткосрочной перспективе, хотя. И я бы надеялся на меньшее количество переломных изменений ...

[обновлено следующее примечание к другому ответу]

Если вам нужен двоичный формат по соображениям пространства / производительности, тогда другим вариантом является использование другого двоичного сериализатора. Например, protobuf-net работает на всех вариантах .NET *, но двоичный формат (разработанный Google) является кросс-платформенным (Java, C ++ и т. Д.), Что делает его очень переносимым, быстрым и маленький.

* = Я не пробовал это на микро-фреймворке, но поддерживаются CF, Silverlight, Mono, .NET 2.0 и т. Д.

Answer 4

У меня есть две вещи, которые нужно добавить к другим ответам ...

Во-первых, использование пользовательского SerializationBinder поможет вам преодолеть множество трудностей при импорте устаревших сериализованных данных.

Во-вторых, я считаю обязательным писать расширенные модульные тесты для любых сохраняемых данных. Я всегда делаю два теста, в частности:

1. Проверка в оба конца - можете ли вы сериализовать и десериализовать ваши объекты и получить в точности то же самое?
2. Устаревший тест импорта - убедитесь, что у вас есть версии сериализованных данных, экспортированных из каждой выпущенной версии вашего приложения. Импортируйте данные и убедитесь, что все возвращается, как и ожидалось.

Answer 5

Если проблема заключается в совместимости, интерфейс ISerializable может быть тем лекарством, которое вы ищете. Этот интерфейс дает вам больше контроля над тем, как элементы сериализуются. Для получения дополнительной информации попробуйте эту статью на MSDN .

Answer 6

Вам не нужно использовать XML для повышения гибкости и управления версиями.

Я использовал библиотеку открытого кода Саймона Хьюитта, см. Оптимизация сериализации в .NET - часть 2 вместо сериализации .NET по умолчанию. Он предлагает некоторую автоматизацию, но, по сути, вы можете контролировать поток информации, который сериализуется и десериализуется. Для управления версиями (файл) версия может быть сначала сериализована и время десериализации, как интерпретируется поток информации, зависит от версии.

Это довольно просто сделать, хотя несколько утомительно из-за явного сериализация / десериализация.

В качестве бонуса он работает в 20-40 раз быстрее и занимает меньше места для больших наборов данных (но может быть неважно в вашем случае).