网站设计谈判,做网站需要固定ip,重庆网站建设有限公司,网页设计模板html图片在本文中#xff0c;我们将回顾一些未能进入.NET Core 的历史性.NET 技术。有趣之处在于#xff0c;这些技术的 API 被复制过来了#xff0c;这暗示着微软当时在考虑将来在.NET Core 中对它们进行实现。全局程序集缓存全局程序集缓存#xff08;GAC#xff09;背后的理论是… 在本文中我们将回顾一些未能进入.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 RemotingJava RMI的启发。这三种方法的基本思想都是一个应用程序可以使用代理对象来操作在另一个应用程序中运行的真实对象。虽然它在技术上可以工作但.NET Remoting 从来就没有流行过因为要正确地使用它很难而且人们一般认为它很脆弱。考虑到这一点.NET Core 从未实现过.NET Remoting API。就像 GAC API 一样它只有不可操作的占位符。因此它们也被标记为已过时而最终目的是将其删除。代码访问安全继续这个主题代码访问安全CAS是另一种 API 被复制到.NET Core 中但被标记为已过时的.NET Framework 技术。代码访问安全创建于 Docker 等隔离容器之前。在.NET Framework 时代多个应用程序会托管在单个 Internet Information ServerIIS实例中。理论上每个应用程序都将被隔离到一个单独的应用程序域中但要打破这种隔离并干扰在 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
