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

Шансы на то, что между версиями фреймворка будут меняться, невысоки (но не равны нулю!). Предполагается, что вы должны иметь возможность использовать двоичную сериализацию и удаленное взаимодействие для связи между клиентом и сервером, на котором работают разные версии фреймворка. Несовместимость между .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).

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

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

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

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

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

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

К остальным ответам у меня есть две вещи ...

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

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

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

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

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

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

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