次の方法で共有

.NET Framework テクノロジが .NET で使用できない

  • [アーティクル]

.NET Framework ライブラリで使用できるいくつかのテクノロジは、アプリ ドメイン、リモート処理、コード アクセス セキュリティ (CAS) など、.NET 6 以降では使用できません。 ライブラリがこのページに記載されているテクノロジの 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 などの低オーバーヘッドのプレーン テキスト プロトコルを使用することをお勧めします。 Kestrel Web サーバーは、ASP.NET Core で使用される 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

.NET 6 以降では、Windows Workflow Foundation (WF) はサポートされていません。 別の方法については、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 クラスを参照してください。

マルチモジュール アセンブリの読み込み

.NET 6 以降では、複数のモジュール (MSBuild でOutputType=Module) で構成されるアセンブリはサポートされていません。

別の方法として、個々のモジュールを 1 つのアセンブリ ファイルにマージすることを検討してください。

XSLT スクリプト ブロック

XSLT スクリプト ブロック は、.NET Framework でのみサポートされています。 .NET 6 以降ではサポートされていません。

関連項目