我的书签
添加书签
移除书签.NET Framework 技术在 .NET Core 上不可用.NET Framework technologies unavailable on .NET Core
本文内容
一些适用于 .NET Framework 库的技术不可用于 .NET Core，例如 AppDomains、远程处理、代码访问安全性 (CAS) 和安全透明度。如果库依赖于这些技术中的一个或多个，请考虑使用下面所述的替代方法。有关 API 兼容性的详细信息，CoreFX 团队在 GitHub 上列出了行为更改/兼容性破坏和弃用的/旧 API 列表。
当前未实现某个 API 或技术并不因此意味着有意不对其提供支持。应该首先在 GitHub 存储库中搜索 .NET Core，以确定遇到的特定问题是否为有意设计，但是如果找不到这样的指示符，请在 GitHub 的 dotnet/corefx 存储库问题中提交问题，以请求特定 API 和技术。问题中的移植请求已标有 port-to-core 标签。
AppDomainAppDomains
应用程序域 (AppDomain) 可将应用相互隔离。AppDomain 需要运行时支持并且通常价格昂贵。不支持创建其他应用域。我们不计划在将来添加此功能。对于代码隔离，建议将流程分隔开来或将容器用作一种替代方法。对于动态加载的程序集，我们建议使用新的 AssemblyLoadContext 类。
.NET Core 公开了一些 AppDomain API 曲面，以便可以更轻松地从 .NET Framework 进行代码迁移。一些 API 可正常工作（例如 AppDomain.UnhandledException），一些成员不会执行任何操作（例如 SetCachePath），也有一些会引发 PlatformNotSupportedException（例如 CreateDomain）。对照 dotnet/corefx GitHub 存储库中的 System.AppDomain 引用源检查所使用的类型，确保选择与已实现的版本相匹配的分支。
远程处理Remoting
.NET 远程处理被认为是存在问题的体系结构。它用于进行跨 AppDomain 的通信，该通信现已不再受支持。同样，远程处理也需要运行时支持，进行维护的成本较高。出于这些原因，.NET Core 不支持 .NET 远程处理，并且我们不计划在将来添加对它的支持。
对于跨进程通信，可将进程间通信 (IPC) 机制视为远程处理的备用方案，如 System.IO.Pipes 或 MemoryMappedFile 类。
对于跨计算机的通信，可将基于网络的解决方案用作备用方案。最好使用低开销纯文本协议，例如 HTTP。此处，ASP.NET Core 使用的 Web 服务器 Kestrel Web 服务器是一个选择。也可考虑将 System.Net.Sockets 用于基于网络的跨计算机的方案。有关更多选项，请参阅 .NET 开放源代码开发人员项目：消息传送。
代码访问安全性 (CAS)Code Access Security (CAS)
沙盒依赖为托管应用程序或库使用或运行提供资源的运行时或框架进行限制，其在 .NET Framework 上不受支持，因此在 .NET Core 上也不受支持。.NET Framework 和运行时中存在太多发生特权提升以继续将 CAS 视为安全边界的情况。此外，CAS 使实现更加复杂，通常会对无意使用它的应用程序造成正确性-性能影响。
可使用操作系统提供的安全边界，例如虚拟化、容器或具有最少特权集的用于运行进程的用户帐户。
安全透明度Security Transparency
与 CAS 相似，借助安全透明度可以以声明性方式将沙盒代码与安全关键代码隔离，但是不再支持将它作为安全边界。Silverlight 大规模使用了此功能。
可使用操作系统提供的安全边界，例如虚拟化、容器或用于运行进程的用户帐户具有最少的一组特权。
System.EnterpriseServicesSystem.EnterpriseServices
.NET Core 不支持 System.EnterpriseServices (COM+)。
