.NET Core で使用できない .NET Framework テクノロジ.NET Framework technologies unavailable on .NET Core

.NET Framework ライブラリで使用できるテクノロジの中には、.NET Core で使用できないものがあります。たとえば、AppDomain、リモート処理、コード アクセス セキュリティ (CAS)、セキュリティ透過性、System.EnterpriseServices などです。Several technologies available to .NET Framework libraries aren't available for use with .NET Core, such as AppDomains, Remoting, Code Access Security (CAS), Security Transparency, and System.EnterpriseServices. ライブラリがこれらのテクノロジの 1 つ以上に依存する場合、以下に示す代替方法を検討してください。If your libraries rely on one or more of these technologies, consider the alternative approaches outlined below. API の互換性の詳細については、「.NET Core の破壊的変更」を参照してください。For more information on API compatibility, see .NET Core breaking changes.

API またはテクノロジが現在実装されていないからといって、意図的にサポートされていないわけではありません。Just because an API or technology isn't currently implemented doesn't imply it's intentionally unsupported. GitHub リポジトリで .NET Core を検索して、発生した特定の問題が設計によるものかどうかを確認します。Search the GitHub repositories for .NET Core to see if a particular issue you encounter is by design. このようなインジケーターが見つからない場合は、特定の API とテクノロジを求めるために dotnet/runtime リポジトリでイシューを報告してください。If you don't find such an indicator, file an issue in the dotnet/runtime repository to ask for specific APIs and technologies.

AppDomainAppDomains

アプリケーション ドメイン (AppDomains) はアプリを互いに分離します。Application domains (AppDomains) isolate apps from one another. AppDomain ではランタイム サポートが必要で、通常は高額です。AppDomains require runtime support and are generally expensive. 追加のアプリ ドメインの作成はサポートされておらず、今後この機能を追加する予定はありません。Creating additional app domains is not supported, and there are no plans to add this capability in the future. コードの分離のためには、代替方法として別個のプロセスやコンテナーを使用します。For code isolation, use separate processes or containers as an alternative. アセンブリを動的に読み込むには、AssemblyLoadContext クラスを使用します。To dynamically load assemblies, use the AssemblyLoadContext class.

.NET Framework からのコードの移行を簡単にするために、.NET Core では AppDomain API サーフェスの一部を公開しています。To make code migration from .NET Framework easier, .NET Core exposes some of the AppDomain API surface. API の中には、正常に機能するもの (AppDomain.UnhandledException など)、処理を行わないメンバー (SetCachePath など)、PlatformNotSupportedException をスローするもの (CreateDomain など) があります。Some of the APIs function normally (for example, AppDomain.UnhandledException), some members do nothing (for example, SetCachePath), and some of them throw PlatformNotSupportedException (for example, CreateDomain). dotnet/runtime GitHub リポジトリSystem.AppDomain 参照ソースに対して使用する種類を確認してください。Check the types you use against the System.AppDomain reference source in the dotnet/runtime GitHub repository. 必ず、実装されているバージョンに合ったブランチを選択してください。Make sure to select the branch that matches your implemented version.

リモート処理Remoting

.NET リモート処理は、問題のあるアーキテクチャであると判断されました。.NET Remoting was identified as a problematic architecture. AppDomain 間の通信で使用されていますが、今後はサポートされなくなります。It's used for cross-AppDomain communication, which is no longer supported. また、リモート処理にはランタイム サポートが必要で、維持するのに高いコストがかかります。Also, Remoting requires runtime support, which is expensive to maintain. これらの理由から、.NET リモート処理は .NET Core でサポートされておらず、また将来サポートが追加される予定もありません。For these reasons, .NET Remoting isn't supported on .NET Core, and we don't plan on adding support for it in the future.

プロセス間の通信では、リモート処理に代わる方法として、System.IO.Pipes クラスまたは MemoryMappedFile クラスなどのプロセス間通信 (IPC) メカニズムを検討してください。For communication across processes, consider inter-process communication (IPC) mechanisms as an alternative to Remoting, such as the System.IO.Pipes class or the MemoryMappedFile class.

マシン間では、代替方法としてネットワーク ベースのソリューションを使用してください。Across machines, use a network-based solution as an alternative. 可能であれば、HTTP などのオーバーヘッドの少ないプレーンテキストのプロトコルを使用してください。Preferably, use a low-overhead plain text protocol, such as HTTP. この場合、ASP.NET Core で使用される Web サーバーの Kestrel Web Server も選択できます。The Kestrel web server, the web server used by ASP.NET Core, is an option here. また、ネットワーク ベースのマシン間のシナリオとして、System.Net.Sockets の使用も検討してください。Also, consider using System.Net.Sockets for network-based, cross-machine scenarios. その他のオプションについては、.NET オープン ソース開発者プロジェクト:メッセージングに関する記事をご覧ください。For more options, see .NET Open Source Developer Projects: Messaging.

コード アクセス セキュリティ (CAS)Code Access Security (CAS)

サンド ボックスは、マネージド アプリケーションやライブラリが使用または実行するリソースの制限を、ランタイムまたはフレームワークに依存しています。これは .NET Framework ではサポートされていないため、.NET Core でもサポートされていません。Sandboxing, which relies on the runtime or the framework to constrain which resources a managed application or library uses or runs, isn't supported on .NET Framework and therefore is also not supported on .NET Core. .NET Framework やランタイムでは、特権の昇格が発生するケースが多すぎるため、このまま CAS をセキュリティ境界と見なすことはできません。There are too many cases in the .NET Framework and the runtime where an elevation of privileges occurs to continue treating CAS as a security boundary. さらに、CAS は実装が複雑化しており、その使用を予定していないアプリケーションでは、多くの場合で正確性のパフォーマンスに影響します。In addition, CAS makes the implementation more complicated and often has correctness-performance implications for applications that don't intend to use it.

仮想化、コンテナー、ユーザー アカウントなど、オペレーティング システムが提供するセキュリティ境界を使用して、最小限の特権セットでプロセスを実行します。Use security boundaries provided by the operating system, such as virtualization, containers, or user accounts, for running processes with the minimum set of privileges.

セキュリティ透過性Security Transparency

CAS と同様に、セキュリティ透過性はサンドボックス コードをセキュリティ クリティカルなコードから宣言的に分離しますが、現在はセキュリティ境界としてはサポートされていませんSimilar to CAS, Security Transparency separates sandboxed code from security critical code in a declarative fashion but is no longer supported as a security boundary. この機能は、Silverlight で頻繁に使用されます。This feature is heavily used by Silverlight.

仮想化、コンテナー、ユーザー アカウントなど、オペレーティング システムが提供するセキュリティ境界を使用して、最低限の特権セットでプロセスを実行します。Use security boundaries provided by the operating system, such as virtualization, containers, or user accounts, for running processes with the least set of privileges.

System.EnterpriseServicesSystem.EnterpriseServices

System.EnterpriseServices (COM+) は、.NET Core でサポートされていません。System.EnterpriseServices (COM+) is not supported by .NET Core.

関連項目See also