我正在处理的项目需要在关闭之前序列化数据结构，并在重新启动时从该序列化数据中恢复其状态。
去年，我们正在为.NET 1.1构建，并遇到了一个棘手的问题
这个特定的问题是通过禁止特定的软件升级而“解决”的，现在我们的目标是.NET 2.0框架（因此我们不能在1.1上运行），这应该不是问题。
这个序列化在2.0和更新的框架之间再次不兼容的可能性有多大？如果我们使用<supportedVersion>将代码修复为2.0.50727，那么2.0.50727.1434和2.0.50727.nnnn（未来某个版本）之间的变化几率是多少？被序列化的数据结构是来自标准类库的数组，映射，字符串等。
此外，是否可以保证即使在进一步的.NET升级后也会始终安装2.0.50727框架？指向Microsoft文档的指示欢迎。
答案 0 :(得分：6)
框架版本之间会有变化的可能性很低（但不是零！）。目的是您应该能够使用二进制序列化和远程处理在客户端和运行不同框架版本的服务器之间进行通信。 .NET 1.x和2.0 is a bug之间不兼容的补丁可用。
然而，二进制序列化还有其他问题，尤其是对序列化结构版本控制的支持不足。从您描述的用例中，Xml序列化是显而易见的选择：如果您不介意依赖于.NET 3.x，DataContractSerializer比XmlSerializer更灵活。
您无法保证在未来的Windows版本上始终安装.NET Framework 2.0。但我确信微软会努力确保大多数.NET 2.0应用程序在.NET 4.x及更高版本上保持不变。我没有任何参考资料：任何此类承诺在任何情况下都只适用于下一版本的Windows（Windows 7）。
答案 1 :(得分：4)
经验法则通常是：XML序列化应该能够在新的框架版本中存活，因此可以长期存储，但二进制序列化不能（因此应该只是暂时的）。
答案 2 :(得分：3)
您使用的是什么序列化程序？在许多方面，像XmlSerializer或DataContractSerializer这样的序列化程序可以从许多细节中缓冲您，并提供更简单的可扩展性选项。 在某些时候，新的CLR版本无疑是必要的 - 所以我认为任何人都不能对2.0.50727作出任何保证。不过，你应该是短期安全的。我希望减少更改......
[关于另一个回复的更新后续注释]
如果出于空间/性能原因需要二进制格式，则另一种选择是使用不同的二进制序列化程序。例如，protobuf-net适用于所有.NET变体*，但二进制格式（由Google设计）是跨平台兼容的（Java，C ++等） - 使其非常便携，快速和小巧。
* =我还没有尝试过微框架，但CF，Silverlight，Mono，.NET 2.0等都受到支持。
答案 3 :(得分：2)
如果要考虑兼容性，ISerializable界面可能是您正在寻找的治疗方法。此界面使您可以更好地控制项目的序列化方式。有关详细信息，请尝试此article on msdn。
答案 4 :(得分：2)
我有两件事要添加到其他答案......
首先，使用自定义SerializationBinder可以帮助您在导入旧版序列化数据时遇到很多困难。
其次，我认为必须为任何持久数据编写广泛的单元测试。我总是特别做两个测试：
答案 5 :(得分：0)
您不必使用XML来获得更高的灵活性和版本。
我使用过Simon Hewitt的开源库，请参阅 Optimizing Serialization in .NET - part 2 而不是默认的.NET序列化。它提供了一些自动化功能，但基本上您可以控制序列化和反序列化的信息流。对于版本控制，可以首先序列化（文件）版本 反序列化时间解释信息流的方式取决于版本。
这很简单，但由于显而易见，有些单调乏味 序列化/反序列化。
作为奖励，它的速度提高了20-40倍，并且占用较少的空间用于大型数据集（但在您的情况下可能并不重要）。