.NET で使用できない .NET Framework テクノロジ
.NET Framework ライブラリで使用できるテクノロジの中には、.NET 6 以降で使用できないものがあります。たとえば、アプリ ドメイン、リモート処理、コード アクセス セキュリティ (CAS) などです。 ご利用のライブラリがこのページに一覧表示されているテクノロジの 1 つ以上に依存する場合は、記載されている代替方法を検討してください。
API の互換性の詳細については、.NET の破壊的変更に関するページを参照してください。
アプリケーション ドメイン
アプリケーション ドメイン (AppDomains) はアプリを互いに分離します。 AppDomain にはランタイム サポートが必要で、リソースを大量に消費します。 追加のアプリ ドメインの作成はサポートされておらず、今後この機能を追加する予定はありません。 コードの分離のためには、代替方法として別個のプロセスやコンテナーを使用します。 アセンブリを動的に読み込むには、AssemblyLoadContext クラスを使用します。
.NET Framework からのコードの移行をより簡単にするために、.NET 6 以降では AppDomain API サーフェスの一部を公開しています。 API の中には、正常に機能するもの (AppDomain.UnhandledException など)、処理を行わないメンバー (SetCachePath など)、PlatformNotSupportedException をスローするもの (CreateDomain など) があります。 dotnet/runtime GitHub リポジトリで System.AppDomain 参照ソースに対して使用する種類を確認してください。 必ず、実装されているバージョンに合ったブランチを選択してください。
リモート処理
.NET リモート処理は、.NET 6 以降ではサポートされていません。 .NET リモート処理は、問題のあるアーキテクチャであると判断されました。 これは、現在サポートされていないアプリケーション ドメインとの間の通信に使用されています。 また、リモート処理にはランタイム サポートも必要で、維持するのに高いコストがかかります。
プロセス間のシンプルな通信については、リモート処理に代わる方法として、System.IO.Pipes クラスまたは MemoryMappedFile クラスなどのプロセス間通信 (IPC) メカニズムを検討してください。 より複雑なシナリオでは、オープンソースの StreamJsonRpc プロジェクトによって、既存のストリームまたはパイプ接続上で動作するクロスプラットフォームの .NET Standard リモート処理フレームワークが提供されます。
マシン間では、代替方法としてネットワーク ベースのソリューションを使用してください。 可能であれば、HTTP などのオーバーヘッドの少ないプレーンテキストのプロトコルを使用してください。 この場合、ASP.NET Core で使用される Web サーバーの Kestrel Web サーバーも選択できます。 また、ネットワーク ベースのマシン間のシナリオとして、System.Net.Sockets の使用も検討してください。 前述の StreamJsonRpc は、Web ソケットを介した JSON またはバイナリ (MessagePack 経由) 通信に使用できます。
その他のメッセージング オプションについては、.NET オープン ソース開発者プロジェクト: メッセージングに関するページをご覧ください。
リモート処理はサポートされていないため、デリゲート オブジェクトでの BeginInvoke() と EndInvoke() への呼び出しでは PlatformNotSupportedException がスローされます。 詳細については、「.NET Core のデリゲート BeginInvoke 呼び出しの移行」を参照してください。
コード アクセス セキュリティ (CAS)
サンドボックスは、マネージド アプリケーションやライブラリが使用または実行するリソースの制限を、ランタイムまたはフレームワークに依存しています。これは .NET Framework ではサポートされていないため、.NET 6 以降でもサポートされていません。 .NET Framework やランタイムで特権の昇格が発生するケースが多すぎるため、CAS はセキュリティ境界として扱われなくなっています。 また、CAS は実装が複雑化しており、その使用を予定していないアプリケーションでは、多くの場合で正確性のパフォーマンスに影響します。
仮想化、コンテナー、ユーザー アカウントなど、オペレーティング システムが提供するセキュリティ境界を使用して、最小限の特権セットでプロセスを実行します。
セキュリティ透過性
CAS と同様に、セキュリティ透過性はサンドボックス コードをセキュリティ クリティカルなコードから宣言的に分離しますが、現在はセキュリティ境界としてはサポートされていません。 この機能は、Silverlight で頻繁に使用されます。
最低限の特権セットでプロセスを実行するには、仮想化、コンテナー、ユーザー アカウントなど、オペレーティング システムが提供するセキュリティ境界を使います。
System.EnterpriseServices
System.EnterpriseServices (COM+) は、.NET 6 以降ではサポートされていません。
Workflow Foundation
Windows Workflow Foundation (WF) は、.NET 6 以降ではサポートされていません。 代替については、CoreWF を参照してください。
ヒント
Windows Communication Foundation (WCF) サーバーは、CoreWCF NuGet パッケージを使用して .NET 6 以降で使用できます。 詳細については、CoreWCF 1.0 がリリースされましたに関するページを参照してください。
一部のリフレクション生成 API はサポートされていません
.NET 8 以前のバージョンの .NET (Core) は、System.Reflection.Emit API によって生成されたアセンブリの保存をサポートしておらず、AssemblyBuilder.Save メソッドは使用できません。 さらに、AssemblyBuilderAccess 列挙型の次のフィールドは使用できません。
.NET 9 では、PersistedAssemblyBuilder が実装され、AssemblyBuilder.Save メソッドがリフレクション生成ライブラリに再追加されました。 この API の使用方法の詳細については、System.Reflection.Emit.PersistedAssemblyBuilder クラスを参照してください。
.NET でのさまざまな AssemblyBuilder 実装の詳細については、「System.Reflection.Emit.AssemblyBuilder クラス」を参照してください
複数モジュールのアセンブリの読み込み
複数モジュール (MSBuild の OutputType=Module) で構成されるアセンブリは .NET 6 以降ではサポートされていません。
代わりに、個々のモジュールを 1 つのアセンブリ ファイルにマージすることを検討してください。
XSLT スクリプト ブロック
XSLT スクリプト ブロックは、.NET Framework でのみサポートされています。 .NET 6 以降ではサポートされていません。
関連項目
.NET