问题
I quite like separating functionality across a few assemblies, for example a facade to a data provider, contracts for the data provider and the data provider implementation itself... to my mind, it makes it easy to unit test the individual components of a piece of functionality and easy to swap out one thing in the future (in the case of my example, it makes the data provider easy to swap out).
If I create a solution with 3 projects and use project references, when I dotnet-build on the entry assembly, all the references are copied to the output folder. When I dotnet pack the entry assembly project to create a NuGET package, only the entry asembly (not the contracts or the data provider) are included in the NuGET package
This appears to be by design; the documentation for .NET Core dotnet-pack states that
Project-to-project references aren't packaged inside the project. Currently, you must have a package per project if you have project-to-project dependencies.
My question is - why is this the case? If I want to separate my code into logical assemblies, I am forced to either create separate NuGET packages and reference those, or simply lump all my code into a single assembly. Is there any way to include project references in a NuGET package?
I am using VS2017 / .NET Core v1.1 (csproj, not xproj)
回答1:
A possible way to achieve the needed is to use a custom .nuspec file where you can specify the dlls you want to be packed
<PropertyGroup>
<NuspecFile>App.nuspec</NuspecFile>
</PropertyGroup>
Having this, dotnet pack will produce the package with respect to MyPackage.nuspec.
Furthermore, if you have like 3 projects with contracts and implementation and you don't want to add 3 package references, you can create a meta-package that simply has those 3 as dependencies and reference that single meta-package.
来源：https://stackoverflow.com/questions/44178357/dotnet-pack-project-references