在本文中，我们将回顾一些未能进入.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 的概念。

尽管如此，GAC API 在.NET Core 中仍然存在。它们所做的事情不多，例如，指示程序集是否在 GAC 中的属性被硬编码为返回 false。

为了进一步明确意图，所有的 GAC API 现在都被标记为已过时，微软正考虑在未来的版本中删除它们。

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 中，该方法终被标记为已过时。

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