dotnet packプロジェクト参照

Question

データプロバイダのファサード、データプロバイダとデータプロバイダの実装自体の契約など、いくつかのアセンブリで機能を分離することは非常に好きです。私の考えでは、機能の個々のコンポーネントをテストし、将来的に一つのものを簡単に交換することができます（私の例の場合、データプロバイダは簡単に交換できます）。

3つのプロジェクトでソリューションを作成し、プロジェクト参照を使用すると、エントリアセンブリでdotnet-buildを実行すると、すべての参照が出力フォルダにコピーされます。 NuGETパッケージを作成するためにエントリアセンブリプロジェクトをドットネットでパックすると、NuGETパッケージにはエントリアセンブリ（契約やデータプロバイダではない）のみが含まれます。

これは設計によるものです。 documentation for .NET Core dotnet-pack

プロジェクト間参照はプロジェクト内にパッケージ化されていません。 現在、プロジェクト間の依存関係がある場合は、プロジェクトごとにパッケージを用意する必要があります。

私の質問は - なぜこの場合ですか？コードを論理アセンブリに分割したい場合は、別々のNuGETパッケージを作成してそれらを参照するか、すべてのコードを単一のアセンブリにまとめてください。プロジェクト参照をNuGETパッケージに含める方法はありますか？

私は少し遅れVS2017/.NETコアV1.1（csproj、ないxproj）

Answer 1

を使用して、しかし私は、私はすべての参照先のプロジェクトのアセンブリが内にパックしたくない理由を説明してみましょうしていますデフォルトではエントリパッケージです。

.NETコアインフラストラクチャはモジュール式に設計されており、パッケージモデルに基づいています。基本的に、.NET Core SDKとドットネットmuxer（.NETコアのブートストラップとホストプロセス）は、パッケージを直接扱うCore CLRであるdllではなく、パッケージとそのメタデータで最初に動作します。したがって、最高レベルの.NET Coreでは、パッケージID /バージョンがプライマリであり、パッケージ内のDLL名/バージョンがセカンダリです。

パッケージ自体は（一部のコンテンツを含むアーカイブでも）名前とバージョンで識別される抽象です。

我々は望ましいdotnet packのふるまいを持ち、すべての参照が同じエントリパッケージにパックされていると仮定します。 プロジェクトの参照チェーンがあれば、内部にすべてのdllを含む単一のパッケージが得られます。これはおそらく、私たちのニーズに十分収まるが、それはまた、違反：

• .NETのコアのモジュールのアイデアを（我々は唯一のID /バージョンである抽象的なパッケージ、よりむしろ のDLL考える必要があるため - それは追加します多くの混乱と複雑さがあります。オールインワンパッケージを使用しない、複数のバージョンの場合はdllの解決を処理するなどのオプションが必要なので、
• SRP（ の一部参照されたdllを再構築する必要がある場合は、 パッケージ全体を更新する必要があります）。質問に関しては

、私はdotnet packが生成されます、必要を達成するための可能な方法は、あなたが

これを持っ

<PropertyGroup> 
    <NuspecFile>App.nuspec</NuspecFile> 
</PropertyGroup> 

を詰めることにしたいDLLを指定することができ、カスタム.nuspecファイルを使用することだと思いますMyPackage.nuspecに関するパッケージ。

さらに、契約と実装の3つのプロジェクトがあり、3つのパッケージ参照を追加したくない場合は、これらの3つを依存関係として持ち、単一のパッケージを参照するパッケージを作成できます。

現在のパッケージ・プロジェクト・モデルは非常にシンプルで、カスタム・ユースケースでは柔軟性があります。