前言

從.NET框架4.0開始，所有主版本號為4（稱為“4.x”版本）的.NET框架，都會進行就地更新。這就意味著在一段時間內，電腦上安裝的只有一個.NET 4.x框架。安裝.NET 4.5框架將替換.NET 4.0框架，.NET 4.5.1框架將替換.NET 4.5框架，.NET 4.6框架將替換.NET 4.5.1，以此類推。

由于這些就地更新的特點，原本在.NET 4.0框架上運行的應用程序，在電腦安裝的.NET框架升級后，可能需要在.NET 4.6上運行。.NET 4.x框架之間的兼容性是非常高的，因此在.NET 4.x框架下正常工作的應用程序，通常也會在較新版本的.NET框架下正常運行。然而不同的.NET 4.x框架會有一些變化，因此應用程序應該在其將運行的任何版本的.NET框架上測試下。

本文概述了最佳做法和工具，用來使支持新的.NET 版本更容易。

?

發生了哪些變化？為什么？

對于.NET 團隊來說，和之前版本的.NET框架的兼容性，是一個高優先級的工作。事實上，.NET框架所有的更改都是由經驗豐富的工程師進行審核，他們會對這些改變在客戶的應用程序上的影響進行評估。

盡管如此，仍然存在兼容性問題。原因之一是，在更新.NET框架時，兼容性并不是唯一的優先事項。有時，由于功能性的原因，不得不進行更改，來解決某個安全漏洞，或者是支持某個行業標準。

還有一些偶然發生的兼容性問題。.NET框架團隊會進行全面的兼容性測試，以防止這些問題，但仍然會漏掉一些問題。還有更復雜的情況，修復兼容性問題本身就是一種影響兼容性的改變（因為有些用戶可能依賴于這些無意的新行為）。在這樣的情況下（解決無意的行為更改），.NET框架團隊常常會使用一個稱為“quirking”的解決方案。

?

Quirking和目標.Net框架

Quirking指的是對于緩解兼容性問題，在.NET 框架中有兩個單獨的代碼路徑，并且選擇一種作為應用程序的目標.NET 框架版本的路徑。這種方式緩解了許多.NET 框架兼容性的問題，因為應用程序在較新的.NET框架上運行時，只要在沒有變化的目標.NET框架中運行，就避免了很多潛在的問題。Quirking行為是被應用程序的目標.NET框架自動確定，但可以由開發人員使用應用程序或計算機配置設置來進行重寫。雖然通過奇想行為減輕了很多兼容性的問題，但是由于安全方面的考慮，以及技術上的限制，并不是所有的兼容性問題都可以被Quirking行為解決。

舉一個例子，如果一個目標.NET框架是4.5的應用程序，在安裝了.NET 4.5.2的電腦上運行，即使在較新的框架上執行應用程序，為了減少兼容性問題，它也會模擬.NET 4.5的行為。

目前，?微軟對.NET 4.0，4.5?和?4.5.1已?停止支持，但是需要特別注意的是，根據新.NET框架的支持政策，?以那些低版本為目標.NET框架的應用程序在高版本的.NET框架上的正常運行，將會繼續得到支持。

目標版本是在創建應用程序域 （通常是在托管可執行文件啟動時）時，由應用程序的主程序集的目標框架屬性決定的。此屬性可以通過以下方式設置︰

• 可以在?Visual Studio 中指定項目的目標框架。

• 可以直接在項目文件中指定項目的目標框架

• 可以直接在項目的源代碼中的目標框架屬性指定目標框架。

• • 請注意，MSBuild 會基于項目的目標框架名稱，自動添加目標框架屬性，所以此屬性只應在非 MSBuild 場景中直接使用。如果使用 MSBuild，就必須通過使用以前鏈接的項目文件來設置調整目標框架。

Quirking設置是?應用程序域?范圍。在大多數情況下，類庫（dll的）將根據依賴于于它們的可執行文件，而使用或者不使用quirking。正因為如此，即使沒有quirking應用，創建者的共享庫可能需要確保他們的代碼能夠正常工作。

?

兼容性開關

除了基于目.NET標框架的自動急轉之外，開發人員可以通過設置兼容性開關，明確選擇使用或者不使用影響兼容性的變化，手動啟用或禁用個別兼容性急轉（以及其他一些不是自動急轉的行為）。這些“兼容性開關”對于允許開發人員把較新版本的.NET框架作為目標.NET框架（為了使用.NET的新功能）時非常有用，這樣仍然可以選擇不使用一些已知的會影響應用程序的改動。兼容性開關設置方式有以下幾種：

• 通過配置文件設置

• 通過環境變量設置

• 在項目的源代碼中以編程方式設置

如何設置兼容性開關的詳細信息，雖然沒有在這篇介紹性的博客中提到，但在后續的跟進中，會有關于這方面更多深入的細節。

在?MSDN?上關于兼容性問題的文檔中，經常會提到兼容性開關，需要時可以查閱。

?

兼容性問題文檔

所有已知的.NET 框架兼容性問題都記錄在 MSDN?上。

從.NET 框架 4.5.1 開始，兼容性問題被列為“運行時更改” 或 “重定向更改”。

• 運行時更改，指的是影響任意應用程序在較新的.NET 框架版本 （這些變化不是quirking） 上運行的更改。

• 重定向更改，指的是只影響應用程序重新以較新.NET框架為目標框架生成的更改。這些是.NET 框架變化，或者是編譯工具的變化。對于.NET 4.0 和 .NET 4.5 之間的變化，在兼容性問題表的項目里，運行時和重定向的區別并不顯示，但可以通過閱讀說明來進行區分。

除了 MSDN 上面的文檔，.NET 框架兼容性問題都可以作為標記文件?，是可供使用的兼容性工具（見下文）?？梢酝ㄟ^直接讀取參考文件 （或在列表的?MSDN 鏡像中）， 來了解有關兼容性的問題。這個參考文件是開源 GitHub 存儲庫中的一部分，可以提交請求，或者創建任何需要修正的問題。.NET 團隊會將參考文件上面的信息和 MSDN 上的信息進行同步。

?

編譯器的兼容性問題

除了上文提到的.NET 框架運行時和重定向的兼容性問題之外，在不能進行急轉的C#和VB編輯器版本之間，還有一小部分不會發生在運行時的更改問題。例如，由于C# 4.0 編譯器和 5.0 C# 編譯器 在生成中間語言時的極小差異，開發人員在新的編輯器中重新編譯應用程序的時候，必須留意此類問題。

因為這些兼容性問題僅在新的編譯器中重新編譯時才會顯現，所以它們不會影響到以前編譯過的二進制文件在新版本的.NET 框架上運行。為此，MSDN 文檔中將這些問題歸類為重定向的變化。兼容性問題標記文檔會將編譯器兼容性問題標記為“編譯時”的重定向的更改問題，這種問題和 “quirking “ 重定目標更改有一些差異。

?

問題識別工具

在 GitHub 上發布兼容性問題標記文件的主要目的，是為了兼容性工具的使用。這些工具使得從一個.NET 框架版本到另一個的遷移變得比較容易。現在，我們介紹以下兩個兼容性分析工具集。

API移植性分析器

ApiPort?（該工具的簡稱），它能夠掃描二進制文件，并標識應用程序接口（以下簡稱API）使用的所有.NET 框架。然后，它將這些 API和兼容性問題參考文件中存儲的數據進行比較，并針對所使用的API提供一份報告，是關于一個.NET框架4.x和另一個版本之間的API的一些更改。命令行選項可以縮小掃描范圍 （例如，只考慮指定的.NET 框架版本之間的更改）。完整文檔請參閱ApiPort中斷更改掃描使用說明。使用ApiPort工具時，需要牢記的注意事項有以下兩點：

因為 ApiPort 只關注API調用的.NET，因此它有可能會發一些誤報。大多數.NET 兼容性問題只影響某個API的特定代碼路徑。簡單地使用這些 API，并不意味著應用程序就會受到兼容性問題的影響。通讀更改說明，以確定所報告的問題是否有可能在你的特定應用程序中出現。

因為 ApiPort 只關注API調用的.NET，一些兼容性問題無法通過此工檢測出來。例如，當只掃描中間語言時，在 WPF 應用程序中使用已更改的 XAML 控件可能不會被發現。 ApiPort 是一個很有用的工具，但不能替代兼容性測試的。

.NET?框架兼容性分析器

.NET 框架兼容性分析器是一整套Roslyn診斷代碼分析器，其使用源代碼中的語法樹以及語義模型，從而更智能地決定一個項目是否會遇到兼容性問題。他們仍然會存在誤報，但相比ApiPort 工具會準確很多。

這些工具可以通過在NuGet.org?網頁上搜索?Microsoft.DotNet.FrameworkCompatibilityDiagnostics得到。.NET 框架團隊目前正在對這些分析器開放資源碼。想要獲得更多的在開放資源代碼成果的更新，請關注這個博客。

?

報告新的兼容性問題

當把應用程序從一個.NET 框架版本遷移到另一個的時候，你偶爾可能會遇到在 MSDN 或 ApiPort 參考文件中沒有記錄的兼容性問題。如果這種情況發生，請讓我們知道！.NET 團隊將會不斷地保持兼容性文檔最新。

在.NET 框架中，沒有文檔說明的兼容性問題可以用以下方式報告：

• 使用 Visual Studio 里面的”發送笑臉”反饋功能來發送詳細的變更。

• 在ApiPort存儲庫中創建問題來題記錄那些還沒有被記錄在工具的標記文件中的.NET 框架兼容性問題。.NET 的團隊 （或社區成員） 將會調查并適當的添加文檔和支持。

?

結語

.NET 框架力求與每個新的框架版本高度兼容。盡管如此，一些兼容性問題仍然是不可避免的。了解這些變化，并且知道怎樣去緩解這些問題，可以保持你的應用程序在新版本的.NET 框架上成功運行。

本文提及的一些兼容性最佳做法包括：

• 不是必須的情況，不要重定向為較新版本的.NET框架來作為目標框架。因為這樣應用程序可以利用兼容性”quirking”功能，從而使兼容性問題減少到最低限度。

• 如果你在用來運行你的應用程序的.NET 框架版本上有任何的控件，就使用較新版本的.NET 框架。這是因為.NET4.x上面的許多兼容性問題已經在后續版本中得到了修復。例如，在4.0 至 4.6 之間的兼容性問題就比4.0到4.5之間的兼容性問題少。

• 如果應用程序是使用較新的編譯器重新編譯的，就一定要確保進行徹底的測試。這可以暴露編譯器兼容性問題 （雖然這些問題很少見）。

• 使用兼容性工具找出潛在問題，常用的工具有?API 移植性分析器和.NET 框架兼容性分析器。

• 在你期望運行的所有.NET 框架版本上，測試你的應用程序。

使用這些技術，應用程序將會繼續在新版本的.NET 框架中運行。

?

相關資料

• MSDN.NET 遷移指南

• MSDN 的兼容性問題列表

• NET API移植性分析器

• .NET 框架兼容性分析器

• .NET 框架支持生命周期

原文地址：https://blogs.msdn.microsoft.com/dotnet/2016/05/02/introduction-to-net-framework-compatibility/

---

.NET社區新聞，深度好文，微信中搜索dotNET跨平臺或掃描二維碼關注

總結

以上是生活随笔為你收集整理的.NET 框架兼容性简介的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。