NuGet strategy when working with multiple VS solutions and multiple projects

Question

I'm looking for some thoughts on which approach would be considered best practice.

Scenario: .NET SVN repository consisting out of multiple projects, some sharing the same NuGet package. Multiple solution files also exist with a subset, some overlapping, of projects in each.

Example:

a.sln
--> proj1 - log4net, nunit(v1.0.0)
--> proj2 - log4net, json
--> proj3 - log4net, nunit(v1.0.0)

b.sln
--> proj2 - log4net, json
--> proj4 - nunit(v1.0.0)

The problem arrises when a developer opens a.sln and updates the nunit(v1.0.0) package for all projects within that solution to say, v2.0.0 . This leaves proj4 's nunit still on v1.0.0 , and assuming all binaries are copied to one output folder, the solution that is built first will determine which version of nunit becomes available.

Approach #1: Compose one project, used by both a.sln and b.sln , that's sole purpose is contain all the NuGet references for all the projects, and output all files to a folder, say Externals . Modify all projects to manually reference the dll 's inside this folder.

Approach #2: Be deligent when updating packages and repeat the process for each solution.

Approach #3: Create one solution that contains all the projects and avoid multiple solutions.

I have a strong preference but would like to get community feedback and be open minded.

Answer 1

• Approach #1 - the problem with that I see is that it forces updates onto other projects, leading to potential compilation issues. Also, you may have a project that would prefer the older NuGet package

• Approach #2 - as per #1 and in addition, unless developers are across the other solutions, they might not think to update them. We developers can be finicky when working on a bug with blinders on

• Approach #3 - though somewhat easier from a maintenance perspective, it does not guarantee that some projects are all using the same NuGet packet. eg two different versions of nunit . In Visual Studio when installing and/or updating a NuGet package, the developer can override which projects will receive the package. Depending on the size of your projects, some developers might not like the idea of creating a monolithic solution (even if projects can be right-click Unload Project ) due to general performance impact

In my opinion Approach #3 may be easier due to the convenience of mass installing the same package to all your projects in one step. Approach #1 comes close too but I fear you will find that you're going to have to deploy the NuGet packages into the other projects regardless due to dependencies - "Type xxx is defined in an assembly that is not referenced. Please add it to references" .

Incompatible Versions

This leaves proj4's nunit still on v1.0.0, and assuming all binaries are copied to one output folder, the solution that is built first will determine which version of nunit becomes available.

Agreed, this strikes me as the ultimate problem and something we have run into. Even if your team is disciplined with using say log4net version X everywhere, good chances you will run into a situation where using some third party library also requires log4net but version Y . So the issue of incompatible versions rises again.

AppDomains

If you find that your solution must be deployed with multiple versions of 3rd party assemblies, you may want to look into child .NET AppDomains. The idea is that you deploy your assemblies not into one big folder (where older files can be clobbered by newer ones or vice versa), but a root folder and child folder for each assembly bound to a particular third-party .dll.

The reason you need child AppDomains is that an assembly may not be loaded more than once per AppDomain even if the other assemblies are located in different folders.

eg

<my app folder>
|--folder a
  |--log4net v1.dll
  |--nunit 3.dll
|--folder b
  |--log4net v2.dll
  |--nunit 4.dll

After all, nUnit uses child AppDomains when running your tests.