c# - Make a NuGet package that depends on another, but do not include it inside - Stack Overflow

I want to make a NuGet package A that depends on NuGet package B.

Projects that will use package A will always have package B as a direct dependency.

Hence, I believe that package B does not need to be included inside package A.

Am I right? If yes, how to make that happen in PackageA.csproj? Also, how to specify the version range of package B that is acceptable for package A?

I want to make a NuGet package A that depends on NuGet package B.

Projects that will use package A will always have package B as a direct dependency.

Hence, I believe that package B does not need to be included inside package A.

Am I right? If yes, how to make that happen in PackageA.csproj? Also, how to specify the version range of package B that is acceptable for package A?

• c#
• .net-core
• nuget
• nuget-package

Share Improve this question Follow asked Feb 3 at 19:28 AlexandreAlexandre 59133 silver badges1313 bronze badges 3

• In order to compile project A (which is delivered by NuGet package A), does it need references to the assemblies provided by NuGet package B? – gunr2171 Commented Feb 3 at 19:41
• @gunr2171 yes, A needs references to code of B – Alexandre Commented Feb 3 at 19:47
• 1 If you try this out (build and pack a class library that depends on let's say Microsoft.Extensions.DependencyInjection), and then unzip your package, you should see that it only contains a single dll, the one of your own assembly. Code from the dependencies is not included in your package directly) – Pieterjan Commented Feb 3 at 19:54

Add a comment  | 

2 Answers 2

Sorted by: Reset to default 1

Hence, I believe that package B does not need to be included inside package A.

To be clear: we're talking about the Dependencies field of the nuspec/nupkg XML file, NOT about extra dll files in the lib/... directory of the output nupkg.

You don't need to, but in my opinion it's a good idea to do so anyways.

NuGet packages are just fancy Zip files containing the compiled dlls files. NuGet package A only contains the dll for project A, it doesn't (or, at least, it shouldn't) contain the dll for project B - that's why you have a NuGet package for project B.

When your client application (the one that uses NuGet packages A and B) compiles, A's dll is going to ask that B's dll is present. If you, as the developer, have manually added the NuGet reference for NuGet package B in the client application, everything should work out. You, however, are responsible for making sure it exists and the versions line up.

A real-world example for this is Hangfire and how it loads the database client for MS SQL Server. You have to manually add at least one of the options listed on that page, or it will complain at runtime.

---

Now, back to the "it's a good idea to do so anyways" comment. From the little I know about your project, it seems project A has a hard dependency on project B. If there isn't any sort of swapping of dlls (you could swap using NuGet B in the client application with NuGet C, and NuGet A will be happy using NuGet C's code instead), then I don't see a point of excluding the explicit dependency in NuGet package A.

What you are describing is a project that is dependent on two packages, A and B. Package B can stand alone and be used in projects where Package A is not also used.

But, Package A requires Package B. If you want nuget to manage the dependency, you would put that dependency in the .nuspec file of Pacakage A. If you add Package B as a dependency in this way, you can go to nuget package manager, add Package A, and the nuget manager will automatically go and add Package B if it is not already installed in the project.

Here is a resource for .nuspec syntax. The ranges and wildcards for dependencies may be helpful if this is what you were looking for: nuspec reference

If you are manually managing the dependency, i.e. manually adding Package B, then you don't need to do anything in the packages themselves. You just have to install both packages in the projects where they are needed. This will create your csproj or packages.config entries.