CODEWITHSUNDEEP
c#.netassembliesnuget.net-assembly
Iarek
Iarek

Reputation: 1242

Referencing assemblies that use NuGet packages from a project that also uses some of these packages

I have a complex library A that consists of several c# projects producing the following assemblies:

The library is written by me, and I have full access to its source code. It depends on several NuGet packages, let's say they are:

These libraries (MongoDb driver and EntLib) are not installed in GAC.

I also have a web project B and I want to use library A in it as a reference to a DLL (not including projects into solution B). The web project depends on several NuGet packages, among them:

Versions of these packages in solutions A and B do not match as they are not developed synchronously. Library A was developed a year ago and used as is since then.

Question: what is the proper way to distribute library A so that:

  1. Any solution could use it even if lib A dependencies are not referenced.
  2. If a solution has its own versions of lib A dependencies, they do not conflict.

My current approach:

  1. From my solutions, I reference the four dlls: A.Core, A.Caching, A.Logging, A.MongoDb.
  2. Then I add all its NuGet dependecies to the solution, if they are not present.
  3. It breaks sometimes as solution B uses mongocsharpdriver version 1.5 and lib A uses version 1.1 (the versions are not that compatible).

So, what shall I do? What will be the correct way of dealing with conflict 'references vs. references of references'?

Upvotes: 8

Views: 3023

Answers (1)

Rich Tebb
Rich Tebb

Reputation: 7126

The best way to manage shared references is to create your own NuGet package for library A which, among other things, defines any dependencies (including versions) that library A relies on. If you don't want to publish library A to the public NuGet feed, you can host your own feed.

NuGet has some complex dependency resolution rules that will attempt to locate a dependency version that is compatible with your project and its dependencies. Unfortunately, this still won't solve your problem in point 3 above, where your solution and its dependent library use mutually incompatible versions of the same external dependency. In this case, you'll just have to re-work either your solution B or library A so that they use the same version of mongocsharpdriver.

Upvotes: 7

Related Questions