做者 | Jonathan Allen數據庫
譯者 | 平川瀏覽器
在本文中，咱們將回顧一些未能進入.NET Core 的歷史性.NET 技術。有趣之處在於，這些技術的 API 被複制過來了，這暗示着微軟當時在考慮未來在.NET Core 中對它們進行實現。緩存
全局程序集緩存安全
全局程序集緩存（GAC）背後的理論是，全部.NET 庫均可以存儲在單個集中的位置。在這種方式下，它與 COM 庫相似。但與 COM 不一樣的是，它能夠存儲每一個庫的多個版本。經過這種方式，微軟但願能夠避免困擾 90 年代應用程序的「DLL 地獄」情景。框架
可是，版本問題仍然存在。此外，得到代碼簽名證書的須要以及 Windows Vista 帶來的安全性的增長使得 GAC 成爲一項使人討厭的技術。到.NET 4.5 發佈時，幾乎沒有應用程序將 GAC 用於非微軟庫。主要的例外是商業庫，但即便是這些庫也已經轉向了對 NuGet 更友好的交付模型。編碼
所以，也就不奇怪，微軟在.NET Core 中從根本上改變了他們的哲學。在新模型中，全部庫依賴項都與應用程序一塊兒部署，從而使得應用程序能夠與其餘.NET Core 應用程序隔離開來。所以，.NET Core 中沒有 GAC 的概念。spa
儘管如此，GAC API 在.NET Core 中仍然存在。它們所作的事情很少，例如，指示程序集是否在 GAC 中的屬性被硬編碼爲返回 false。代理
爲了進一步明確意圖，全部的 GAC API 如今都被標記爲已過期，微軟正考慮在將來的版本中刪除它們。orm
Remoting對象
.NET Remoting 是受 DCOM 和 Java Remoting（Java RMI）的啓發。這三種方法的基本思想都是一個應用程序可使用代理對象來操做在另外一個應用程序中運行的真實對象。雖然它在技術上能夠工做，但.NET Remoting 歷來就沒有流行過，由於要正確地使用它很難，並且人們通常認爲它很脆弱。
考慮到這一點，.NET Core 從未實現過.NET Remoting API。就像 GAC API 同樣，它只有不可操做的佔位符。所以，它們也被標記爲已過期，而最終目的是將其刪除。
代碼訪問安全
繼續這個主題，代碼訪問安全（CAS）是另外一種 API 被複制到.NET Core 中，但被標記爲已過期的.NET Framework 技術。
代碼訪問安全建立於 Docker 等隔離容器以前。在.NET Framework 時代，多個應用程序會託管在單個 Internet Information Server（IIS）實例中。理論上，每一個應用程序都將被隔離到一個單獨的應用程序域中，但要打破這種隔離並干擾在 IIS 中運行的其餘應用程序並不難。
代碼訪問安全的建立就是爲了限制這種可能的損害。其基本思想是，危險的 API 會被加上表示風險的屬性。IIS 之類的主機能夠配置爲運行具備不一樣「信任」級別的應用程序，從理論上講，是將它們放入一個沙箱中。
CAS 的另外一個用途是用於瀏覽器託管的應用程序。早在 Silverlight 出現以前，就已經能夠在 Internet Explorer 中運行 Windows 窗體應用程序了。應用程序的信任級別部分取決於它是從哪裏加載的，內部站點會得到更高的權限。
可是和許多早期的.NET 技術同樣，要正確地實現 CAS 很困難。惡意應用程序有許多方法能夠繞過 CAS 限制，而良性應用程序卻經常爲這些限制所限。結果，瀏覽器託管的應用程序很快就把它禁用了，而 IIS 在很大程度上忽略了 CAS 信任級別。
Thread.Abort
這可能會令你感到驚訝。Thread.Abort 在.NET Core 中從未實現過。雖然它老是被認爲有危險，但總也不可避免。在 ASP.NET 中，像請求超時或客戶端斷開鏈接這樣簡單的事情就會觸發一個 Thread.Abort 調用。若是你沒有認真地編寫代碼進行處理，這可能會致使資源泄漏，好比獲取的鎖或打開的數據庫事務。
到 ASP.NET Core 被建立時，CancellationToken 已成爲一個安全且被普遍接受的 Thread.Abort 替代者，所以就不須要在.NET Core 的第一個版本中實現它了。儘管.NET Core 已經將其功能擴展到 Web 站點以外，但其餘主要的應用程序框架都不須要 Thread.Abort，所以它會繼續拋出PlatformNotSupportedException。
在.NET 5 中，該方法終被標記爲已過期。
原文連接：
.NET 5 Breaking Changes: Historic Technologies
https://www.infoq.com/news/2020/12/net-5-breaking-changes-2/