新しい project.json ファイルを使用して、NuGet パッケージを標準の .NET 4.6 クラス ライブラリに追加することはできますか? もしそうなら、どのように?
1 に答える
新しい project.json ファイルを使用して、NuGet パッケージを標準の .NET 4.6 クラス ライブラリに追加することはできますか?
「標準」が何を意味するのかはわかりませんが、完全な .NET ランタイムで実行している場合は違います。
依存関係をロードする責任はランタイムにあります。coreclr.dll
を使用する完全な .NET フレームワークとは対照的に、CoreCLR ランタイムはを使用しますclr.dll
。
CoreCLR を使用する場合、使用される はファイルLoaderContainer
を認識しているproject.json
ため、読み込む依存関係を検索します。依存関係をオフロードするプロセスは、ASP.NET 5 ドキュメント内のDNX 構造で説明されています。
その方法の詳細を本当に知りたい場合は、 GitHubDefaultHost.cs
でApplicationHostContext.cs
aspnet /dnxソリューションを参照してください。
レイヤー 1 : CLR ネイティブ ホスト:
このレイヤーは、使用している CLR のバージョンに固有であり、次の 2 つの主な役割があります。
CLR を起動します。これを行う方法は、CLR のバージョンによって異なります。Core CLR の場合、このプロセスには、coreclr.dll の読み込み、ランタイムの構成と開始、およびすべてのマネージ コードが実行される AppDomain の作成が含まれます。
レイヤー 2 のマネージド エントリ ポイントの呼び出し。ネイティブ ホストのエントリ ポイントが戻ると、このプロセスは CLR をクリーンアップしてシャットダウンします。つまり、アプリ ドメインをアンロードし、ランタイムを停止します。
レイヤ 2 : マネージド エントリ ポイント
このレイヤーは、マネージ コードで記述された最初のレイヤーであり、次の役割を果たします。
必要な ILoaders を含む LoaderContainer を作成します。ILoader は、アセンブリを名前でロードする役割を果たします。CLR がアセンブリの解決を要求すると、LoaderContainer はその ILoaders を使用して必要なアセンブリを解決します。
ネイティブ プロセスの実行時に提供された --lib から、アセンブリをロードし、依存関係を満たすルート ILoader を提供します。これは通常、DNX パッケージ自体です。
提供されたプログラムのメイン エントリ ポイントを呼び出します。
レイヤー 3: アプリケーション ホスト / アプリケーション
ユーザーがアプリケーション全体を libpath のディスク上のアセンブリにコンパイルする場合、このレイヤーがアプリケーションになります。これを行うには、アプリケーションのエントリ ポイントを含むアセンブリの名前を [ProgramName] 引数に渡すと、レイヤー 2 がそれを直接呼び出します。ただし、他のすべてのシナリオでは、アプリケーション ホストを使用してアプリの依存関係を解決し、アプリを実行します。Microsoft.Net.ApplicationHost は、ランタイムで提供されるアプリケーション ホストであり、いくつかの責任があります。
project.json 内の依存関係を調べ、アプリが使用する依存関係のクロージャーを構築します。依存関係のウォーキング ロジックについては、依存関係の解決に関するドキュメントで詳しく説明されています。
さまざまなソース、NuGet、Roslyn などからアセンブリをロードできる LoaderContainer に ILoader を追加します。
ネイティブ プロセスへの次の引数として名前が指定されたアセンブリのエントリ ポイントを呼び出します。