我正在處理的一個項目需要在關閉之前序列化數據結構，並在再次啓動時從該序列化數據恢復其狀態。跨不同框架版本的.NET序列化的穩定性
去年，我們正在建造的.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文檔歡迎。
機會很低（但不是零！）框架版本之間會有變化。意圖是你應該能夠使用二進制序列化和遠程處理在客戶端和運行不同框架版本的服務器之間進行通信。 .NET 1.x和2.0可用的2.0 is a bug之間的不兼容性。
但是，二進制序列化還有其他問題，特別是對序列化結構版本化的支持不足。從你所描述的用例中，Xml序列化是一個明顯的選擇：如果你不介意對.NET 3.x的依賴，DataContractSerializer比XmlSerializer更靈活。
您不能保證.NET Framework 2.0將始終安裝在未來版本的Windows上。但我相信微軟將努力確保大多數.NET 2.0應用程序在.NET 4.x和更高版本上運行不變。我沒有任何參考資料：任何這種承諾在任何情況下都只適用於Windows的下一版本（Windows 7）。
你在使用什麼串行器？在許多方面，像XmlSerializer或DataContractSerializer這樣的序列化程序可以從許多細節中緩衝您的工作，並提供更簡單的擴展選項。 在某些情況下，新的CLR版本無疑是必要的 - 所以我不認爲任何人都可以對2.0.50727做任何保證;儘管如此，你應該是短期安全的。而且我希望更少的重大更改...
[另一回復更新以下注意事項】
如果你想爲空間/性能原因二進制格式，那麼另一種選擇是使用不同的二進制序列。例如，protobuf-net適用於所有.NET變體*，但二進制格式（由Google制定）是跨平臺兼容的（Java，C++等），使其非常便於攜帶，速度快，體積小。
* =我還沒有嘗試過微型框架，但CF，Silverlight，Mono，.NET 2.0等都支持。
經驗法則通常是：XML序列化應該能夠在新的框架版本中存活，因此可以長期存儲，但二進制序列化不能（因此應該只是暫時的）。
撿起來; BinaryFormatter等/可能/有問題...有二進制格式是以數據爲中心的，而不是以類型爲中心的，並且爲此目的可以被認爲類似於「密集的xml」。 「protobuf-net」就是其中之一; -p – 2008-10-15 06:09:49
如果兼容性問題，ISerializable接口可能是您正在尋找的治療方法。這個界面可以讓你更好地控制項目的序列化。欲瞭解更多信息，請嘗試這個article on msdn。
我有兩件事情要添加到其他的答案...
首先，利用定製SerializationBinder的可以讓你圓大量的進口遺留串行數據的困難。其次，我認爲必須爲所有持久數據編寫大量的單元測試。我總是做兩個測試：
爲了獲得更高的靈活性和版本控制，您不必使用XML。
我已經使用了Simon Hewitt的開源庫，請參閱Optimizing Serialization in .NET - part 2而不是默認的.NET序列化。它提供了一些自動化功能，但基本上可以控制序列化和反序列化的信息流。對於版本控制，可以首先對（文件）版本進行序列化，並在解串行時解釋信息流的方式取決於版本。
這樣做很簡單，雖然由於顯式的 序列化/反序列化而有點繁瑣。
作爲獎勵，它的速度提高了20-40倍，佔用了大量數據集的空間（但在您的情況下可能不重要）。
我同意大部分內容，但是我沒有看到Windows 7的一點......我不知道關於.NET 4.x或Windows的大量數據7，但我希望.NET 4.x能夠兼容Vista和/或XP。當然，我可能是無知的; -p – 2008-10-15 07:52:56