18

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)

svick
  • 236,525
  • 50
  • 385
  • 514
Jay
  • 9,561
  • 7
  • 51
  • 72
  • 1
    As for "why", when the documentation says that you "currently" must do something, it usually means the devs didn't have the time to implement the functionality. – svick May 26 '17 at 13:07
  • @svick Oh that's very cynical (but probably right!) I'll leave this post open for a while in case there is some sort of way around the 1 assembly / NuGET package limitation that presents itself in the near future. – Jay May 26 '17 at 13:54

1 Answers1

3

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.

Pang
  • 9,564
  • 146
  • 81
  • 122
Ivan Zaruba
  • 4,236
  • 5
  • 20
  • 29
  • 1
    This doesn't answer my question, and IMHO, you are missing my point. I'm not advocating not using packages; rather I am talking about creating maintainable packages. If I have a single package which is used for doing something simple like writing files to a cache, I like to separate the individual components (of that package) out into their own assemblies (business logic / data access / contracts in between). It's cleaner than just creating a huge package with all that stuff in a single dll, and you can easily build using TDD. Future changes within the package are also less bother. – Jay Apr 28 '18 at 09:44
  • The individual parts of the nuget package are not really good candidates for standalone packages, but I am forced to either create stand alone packages or a monolithic dll. *That* is my problem. – Jay Apr 28 '18 at 09:44
  • I've never thought you were advocating not using packeges. Your question was regarding the purpose of having a "Dll Per Package" design out-of-box rather than "Dll And Dependencies Per Package". You're talking about creating maintainable packages and so do I. The "Dll per package" approach allows you to maintain each part of you application individualy though you still have an option to create your custom package. – Ivan Zaruba Apr 28 '18 at 10:46
  • You are not forced to put all your logic into a single Monolithic.dll. NuGet package, being a simple zip file (with an extension changed to .nupkg) allows you to store any number of files. – Ivan Zaruba Apr 28 '18 at 10:47
  • Having re-read, I would probably accept this as the answer if you were to remove the entire first half of your post describing your opinion as to why it is a bad idea, and just left the bit in that answered the question (the bit starting with 'Regarding the question...'). That is only because the way the answer is currently structured led me to mis-understand your answer and I believe it would also cause other people who may have the same problem to mis-understand your answer too. – Jay Apr 28 '18 at 11:02
  • Ok, agreed. It was not obvious for me at first what you meant by "Why is this the case?". – Ivan Zaruba Apr 28 '18 at 11:17