CODEWITHSUNDEEP
dependenciesnuget
Dylan Beattie
Dylan Beattie

Reputation: 54140

How should I manage dependencies between projects that deploy as separate NuGet packages?

I'm using NuGet to manage shared libraries that I'm using in a couple of WebAPI projects, and I'm not sure how to manage the dependencies between the various bits of my shared project.

My shared libraries are configured as a solution containing three projects:

           +------MyUtils.Core------+
           |                        |
MyUtils.WebApi.Windsor    MyUtils.WebApi.Security

Both the Windsor and the Security modules depend on Core, but should remain deployable as separate NuGet packages.

My question is - should I publish Core as a NuGet package in its own right, and then add that package to Windsor and Security, or should I just add project references to Core in both Windsor and Security projects and then publish them as separate projects?

If the latter, do I risk potential conflicts if I were building a project that had both Windsor and Security, and I upgraded one of them to a version that included a different version of MyUtils.Core?

Upvotes: 3

Views: 788

Answers (1)

Jim Counts
Jim Counts

Reputation: 12795

Here's what I would do, assuming I understand the question...

Make 3 packages. MyUtils.Core is the easiest because it has no dependencies. When you create Core, it will get a version number, one way or another (you could use the assembly version number, or assign manually.)

When you create the other two packages, specify the exact version number for Core (docs.nuget.org)

Example MyUtils.WebApi.Windsor.nuspec:

<dependency id="MyUtils.Core" version="[1.0.1.1]" />

Once you do this you can update Security to use the next version, say 1.0.1.2. But, you will avoid conflicts in projects that consume both. When the version number is specified exactly, NuGet will refuse to update Security unless it can find a version of Windsor that also depends on 1.0.1.2. If it can't find a compatible package, no update. If it can, then it will update both when Security is updated.

By default, the version number is specified like so,

<dependency id="MyUtils.Core" version="1.0.1.1" />

And in this case it means any version of MyUtils.Core >= 1.0.1.1. So if you used the default syntax you would risk conflicts in projects that use both Windsor and Security, but you should be able to avoid it with the exact version syntax.

Lets say you went the other route, and did not create a package for Core, and used project references. Then presumably you would put a copy of Core.dll in each package that needed it. Well, the consuming project can only take a reference to one copy of Core.dll at a time. I'd have to play around with NuGet to see which reference it would add (highest version vs. most recently installed) but the bottom line is that if you had breaking changes, then one of your dependent libraries would break. So it seems like taking the project reference might not be the best solution.

Of course, you only need to do this if there actually is a conflict to avoid. If your 1.0.1.2 is backward compatible then there is no reason not to allow the default behavior in NuGet.

Upvotes: 1

Related Questions