在本文中，我們將回顧一些未能進(jìn)入.NET Core 的歷史性.NET 技術(shù)。有趣之處在于，這些技術(shù)的 API 被復(fù)制過(guò)來(lái)了，這暗示著微軟當(dāng)時(shí)在考慮將來(lái)在.NET Core 中對(duì)它們進(jìn)行實(shí)現(xiàn)。

全局程序集緩存

全局程序集緩存（GAC）背后的理論是，所有.NET 庫(kù)都可以存儲(chǔ)在單個(gè)集中的位置。在這種方式下，它與COM庫(kù)類似。但與 COM 不同的是，它可以存儲(chǔ)每個(gè)庫(kù)的多個(gè)版本。通過(guò)這種方式，微軟希望可以避免困擾 90 年代應(yīng)用程序的“DLL 地獄”情景。

但是，版本問(wèn)題仍然存在。此外，獲得代碼簽名證書(shū)的需要以及 Windows Vista 帶來(lái)的安全性的增加使得 GAC 成為一項(xiàng)令人討厭的技術(shù)。到.NET 4.5 發(fā)布時(shí)，幾乎沒(méi)有應(yīng)用程序?qū)?GAC 用于非微軟庫(kù)。主要的例外是商業(yè)庫(kù)，但即使是這些庫(kù)也已經(jīng)轉(zhuǎn)向了對(duì) NuGet 更友好的交付模型。

因此，也就不奇怪，微軟在.NET Core 中從根本上改變了他們的哲學(xué)。在新模型中，所有庫(kù)依賴項(xiàng)都與應(yīng)用程序一起部署，從而使得應(yīng)用程序可以與其他.NET Core 應(yīng)用程序隔離開(kāi)來(lái)。因此，.NET Core 中沒(méi)有 GAC 的概念。

盡管如此，GAC API 在.NET Core 中仍然存在。它們所做的事情不多，例如，指示程序集是否在 GAC 中的屬性被硬編碼為返回 false。

為了進(jìn)一步明確意圖，所有的 GAC API 現(xiàn)在都被標(biāo)記為已過(guò)時(shí)，微軟正考慮在未來(lái)的版本中刪除它們。

Remoting

.NET Remoting是受DCOM和Java Remoting（Java RMI）的啟發(fā)。這三種方法的基本思想都是一個(gè)應(yīng)用程序可以使用代理對(duì)象來(lái)操作在另一個(gè)應(yīng)用程序中運(yùn)行的真實(shí)對(duì)象。雖然它在技術(shù)上可以工作，但.NET Remoting 從來(lái)就沒(méi)有流行過(guò)，因?yàn)橐_地使用它很難，而且人們一般認(rèn)為它很脆弱。

考慮到這一點(diǎn)，.NET Core 從未實(shí)現(xiàn)過(guò).NET Remoting API。就像 GAC API 一樣，它只有不可操作的占位符。因此，它們也被標(biāo)記為已過(guò)時(shí)，而最終目的是將其刪除。

代碼訪問(wèn)安全

繼續(xù)這個(gè)主題，代碼訪問(wèn)安全（CAS）是另一種 API 被復(fù)制到.NET Core 中，但被標(biāo)記為已過(guò)時(shí)的.NET Framework 技術(shù)。

代碼訪問(wèn)安全創(chuàng)建于 Docker 等隔離容器之前。在.NET Framework 時(shí)代，多個(gè)應(yīng)用程序會(huì)托管在單個(gè) Internet Information Server（IIS）實(shí)例中。理論上，每個(gè)應(yīng)用程序都將被隔離到一個(gè)單獨(dú)的應(yīng)用程序域中，但要打破這種隔離并干擾在 IIS 中運(yùn)行的其他應(yīng)用程序并不難。

代碼訪問(wèn)安全的創(chuàng)建就是為了限制這種可能的損害。其基本思想是，危險(xiǎn)的 API 會(huì)被加上表示風(fēng)險(xiǎn)的屬性。IIS 之類的主機(jī)可以配置為運(yùn)行具有不同“信任”級(jí)別的應(yīng)用程序，從理論上講，是將它們放入一個(gè)沙箱中。

CAS 的另一個(gè)用途是用于瀏覽器托管的應(yīng)用程序。早在 Silverlight 出現(xiàn)之前，就已經(jīng)可以在 Internet Explorer 中運(yùn)行 Windows 窗體應(yīng)用程序了。應(yīng)用程序的信任級(jí)別部分取決于它是從哪里加載的，內(nèi)部站點(diǎn)會(huì)獲得更高的權(quán)限。

但是和許多早期的.NET 技術(shù)一樣，要正確地實(shí)現(xiàn) CAS 很困難。惡意應(yīng)用程序有許多方法可以繞過(guò) CAS 限制，而良性應(yīng)用程序卻常常為這些限制所限。結(jié)果，瀏覽器托管的應(yīng)用程序很快就把它禁用了，而 IIS 在很大程度上忽略了 CAS 信任級(jí)別。

Thread.Abort

這可能會(huì)令你感到驚訝。Thread.Abort在.NET Core 中從未實(shí)現(xiàn)過(guò)。雖然它總是被認(rèn)為有危險(xiǎn)，但總也不可避免。在 ASP.NET 中，像請(qǐng)求超時(shí)或客戶端斷開(kāi)連接這樣簡(jiǎn)單的事情就會(huì)觸發(fā)一個(gè)Thread.Abort調(diào)用。如果你沒(méi)有認(rèn)真地編寫(xiě)代碼進(jìn)行處理，這可能會(huì)導(dǎo)致資源泄漏，比如獲取的鎖或打開(kāi)的數(shù)據(jù)庫(kù)事務(wù)。

到 ASP.NET Core 被創(chuàng)建時(shí)，CancellationToken已成為一個(gè)安全且被廣泛接受的Thread.Abort替代者，因此就不需要在.NET Core 的第一個(gè)版本中實(shí)現(xiàn)它了。盡管.NET Core 已經(jīng)將其功能擴(kuò)展到 Web 站點(diǎn)之外，但其他主要的應(yīng)用程序框架都不需要Thread.Abort，因此它會(huì)繼續(xù)拋出PlatformNotSupportedException。

在.NET 5 中，該方法終被標(biāo)記為已過(guò)時(shí)。

原文鏈接：https://www.infoq.cn/article/5McxpFwRxeKGeiBfTKPy

總結(jié)

以上是生活随笔為你收集整理的.NET 5 的重大改变：消失的历史技术的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。