Стабильность сериализации .NET в разных версиях фреймворка
Проект, над которым я работаю, требует сериализации структуры данных перед завершением работы и восстановления ее состояния из этих сериализованных данных при повторном запуске.
В прошлом году мы создавали для .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 приветствуются.
Ответы 6
Какой сериализатор вы используете? Во многих отношениях сериализатор, такой как XmlSerializer или DataContractSerializer, буферизует вас от многих деталей и предоставляет более простые варианты расширяемости. В какой-то момент, несомненно, потребуется новая версия CLR - поэтому я не думаю, что кто-то может дать какие-либо гарантии относительно 2.0.50727; Однако в краткосрочной перспективе вы должны быть в безопасности. И я бы надеялся на меньшее количество критических изменений ...
[обновлено после примечания к другому ответу]
Если вам нужен двоичный формат из соображений экономии места / производительности, другой вариант - использовать другой двоичный сериализатор. Например, protobuf-net работает со всеми вариантами .NET *, но двоичный формат (разработанный Google) является кроссплатформенным (Java, C++ и т. д.), Что делает его очень портативным, быстрым и компактным.
* = Я не пробовал это на микро-фреймворке, но поддерживаются CF, Silverlight, Mono, .NET 2.0 и т. д.
Как правило, эмпирическое правило таково: сериализация XML должна выдерживать новые версии фреймворка и, следовательно, может храниться в течение длительного времени, но двоичная сериализация не может (и, следовательно, всегда должна быть временной).
Если совместимость вызывает беспокойство, интерфейс ISerializable может быть тем лекарством, которое вы ищете. Этот интерфейс дает вам больше контроля над сериализацией элементов. Для получения дополнительной информации попробуйте этот статья на msdn.
Шансы на то, что между версиями фреймворка будут меняться, невысоки (но не равны нулю!). Предполагается, что вы должны иметь возможность использовать двоичную сериализацию и удаленное взаимодействие для связи между клиентом и сервером, на котором работают разные версии фреймворка. Несовместимость между .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).
Я согласен с большей частью этого, но я не вижу смысла Windows 7 ... Я не очень много знаю ни о .NET 4.x, ни о Windows 7, но я бы ожидал, что .NET 4.x будет Vista и / вероятно / XP совместимы. Конечно, я могу быть невежественным ;-p
Я имел в виду, что, хотя Microsoft может взять на себя обязательство поставлять вместе с Windows 7 как .NET 2.0-3.5, так и .NET 4.0, сегодня они вряд ли возьмут на себя обязательства по поводу того, какие версии платформы будут поставляться с более поздними версиями Windows.
У меня есть две вещи, которые нужно добавить к другим ответам ...
Во-первых, использование настраиваемого Сериализация может решить множество проблем при импорте устаревших сериализованных данных.
Во-вторых, я считаю обязательным писать обширный модульные тесты для любых сохраняемых данных. В частности, я всегда делаю два теста:
- Тест туда и обратно - можете ли вы сериализовать и десериализовать свои объекты и получить обратно то же самое?
- Устаревший тест импорта - убедитесь, что у вас есть версии сериализованных данных, экспортированных из каждой выпущенной версии вашего приложения. Импортируйте данные и убедитесь, что все возвращается, как ожидалось.
Вам не нужно использовать XML, чтобы получить более высокую гибкость и управление версиями.
Я использовал библиотеку с открытым исходным кодом Саймона Хьюитта, см. Оптимизация сериализации в .NET - часть 2 вместо сериализации .NET по умолчанию. Он предлагает некоторую автоматизацию, но, по сути, вы можете контролировать поток информации, который сериализуется и десериализуется. Для управления версиями (файловая) версия может быть сериализована первой и на Время десериализации способ интерпретации потока информации зависит от версии.
Это довольно просто сделать, хотя и несколько утомительно из-за явного сериализация / десериализация.
В качестве бонуса он работает в 20-40 раз быстрее и занимает меньше места для больших наборов данных (но может быть неважным в вашем случае).
Чтобы понять это; BinaryFormatter и т. д. / Может / иметь проблемы ... существуют двоичные форматы, ориентированные на данные, а не на типы, и для этой цели их можно рассматривать как аналог «плотного xml». "protobuf-net" является одним из них ;-p