做者 | 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/