我正在处理的一个项目需要在关闭之前序列化一个数据结构，并在它再次启动时从这个序列化数据中恢复其状态。
去年，我们正在为 .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 文档。
框架版本之间发生变化的可能性很低（但不是零！）。目的是您应该能够使用二进制序列化和远程处理在运行不同框架版本的客户端和服务器之间进行通信。.NET 1.x 和 2.0 之间的不兼容是一个可用补丁解决的错误。
但是二进制序列化还有其他问题，尤其是对您正在序列化的结构的版本控制的支持很差。从您描述的用例来看，Xml 序列化是显而易见的选择：如果您不介意对 .NET 3.x 的依赖，DataContractSerializer 比 XmlSerializer 更灵活。
您不能保证 .NET Framework 2.0 将始终安装在未来版本的 Windows 上。但我确信微软会努力确保大多数 .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可以让您在导入遗留的序列化数据时遇到很多困难。
其次，我认为必须为任何持久数据编写广泛的单元测试。我总是特别做两个测试：
您不必为了获得更高的灵活性和版本控制而使用 XML。
我使用了 Simon Hewitt 的开源库，请参阅Optimizing Serialization in .NET - part 2而不是默认的 .NET 序列化。它提供了一些自动化，但本质上您可以控制被序列化和反序列化的信息流。对于版本控制，可以首先序列化（文件）版本，并且在反序列化时，解释信息流的方式取决于版本。
这很简单，虽然由于显式的序列化/反序列化而有些乏味。
作为奖励，它的速度提高了 20-40 倍，并且为大型数据集占用的空间更少（但在您的情况下可能并不重要）。