9

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

  • A.Core
  • A.Caching
  • A.Logging
  • A.MongoDb

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:

  • mongocsharpdriver
  • EnterpriseLibrary.Caching
  • EnterpriseLibrary.Logging

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:

  • mongocsharpdriver
  • EnterpriseLibrary.Logging

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'?

Improve this question

1 Answer 1

Reset to default
7

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Create my own package is a great option I was not aware of. I believe it is the best thing that can be done here. Thank you!

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.