My question is about production workflow with NuGet packages for shared code.
Say we have project Pr1, that depends on NuGet package N1, that depends on package N2. Pr1 added as a reference projects for other projects within the solution. Those projects also have dependencies on packages N1 and N2.
Now imagine, I've made changes in N2 package. After that I need to update package version of N2 for N1, for Pr1 and also for every project that use N2 and Pr1 together, because if I don't do that, I can get runtime errors. The cause of them is in fact that assemblies is being copied to bin directory of dependent projects, and that version is not the same it was build against.
This workflow give a pain even greater than shared code in form of SVN-externals, but we are migrating to Git, and shared code is not the thing it can work effectively (subtrees and submodules is no the same as externals!).
Also, we have not only one solution of projects, but many, and dependency chain is much longer than for this toy example, so changing versions become very painful and give a filing of wasting of time.
I suggest moving your projects to the
PackageReference
style (away frompackages.config
) that VS 2017 and NuGet 4 now introduced (with the recent 15.2 update, this is supported for classic .net projects as well - not only .net core / .net standard projects). The big difference is that dependencies flow transitively, so you only specify a package reference from Pr1 to N1 and automatically get the version of N2 that N1 references. If you then add a project reference from a project Pr2 to Pr1, this project will get references to N1 and N2 automatically. So if you update the version of N1 that Pr1 uses, it will get the updates to N2 that N1 requires and Pr2 will also use the new N1 and N2 without making any changes.See this NuGet blog post for how to use PackageReference, especially the section "What about other project types that are not .NET Core?"