I am investigating how I can use NuGet to distribute developer frameworks and tools within my organization. I have the server setup and am able to generate packages and add them to consuming projects. I am now looking to expand this into a more real-world situation.
In my case, I will have a framework that we distribute to all of the development teams in the organization. This framework has a “core” class library then a set of technology-specific libraries such as Acme.Web, Acme.Silverlight and so on. Each of these libraries references the “core” assembly.
I have packaged each of these assemblies into it’s own NuGet package including “core” which is set as a dependency within the other packages. This is because developers may chose to only reference “core” when creating class libraries but also want those types when creating web apps, etc.
The other idea is that I could release a new version of my “core” assembly without requiring updates in all of the other packages. Or can I?
Imagine the case where I have project A, add NuGet package B that has a dependency on NuGet package C then package C is updated. Is it possible to distribute this update without rebuilding, repackaging and reposting package B? If so, are there any steps I need to take to ensure there are no versioning issues?
It sounds like the question you are asking is, given the following dependency graph:
-> means depends on
If there happens to be an update to C, lets say C 1.1, you want to know if you can publish that update to C and have consumers update it without breaking B.
I’m going to assume you’re packing assemblies here. If that’s the case then you can definitely do that. NuGet does a few things to help make this work for assemblies that have a strong name (i.e it adds the necessary binding redirects). You just need to make sure you use proper versioning (I strongly recommend you read David Ebbo’s posts on the subject).
To give you a basic understanding on how this would work. Say you’re in a team of 3, You, Developer 1 and 2.
In the above scenario you changed the version from C 1.0 to C 1.0.1 and didn’t have to re-publish B.
Now, if you made a huge breaking change and bumped the version to C 2.0, then maybe you want to consider re-packing B and increasing the version number and making that version of B depend on C 2.0: