Structuring dependencies for .Net core across Nuget packages

Question

I am working on a microservices system in c# (.Net Core) where for simplicity we place each microservice in it's own repo. Some services are very generic and some are very similar (although for different domains).

Naturally over time as the number of services grew, we identified a lot of re-usable code and patterns across those and moved those to libraries.

We moved a lot of code to nugets trying to keep it as generic as possible, with each nuget package also being it's own repo, which gave us a structure roughly like so:

Utilities
    ||
    \/
Bindings
    ||
    \/
Complete Kit 

Where Utilities is just a bunch of classes useful for all services; Bindings is a nuget that contains contracts for services that do talk to others (these use a bit of shared code from Utilities) and Complete Kit is a one-stop solution for very common domain specific things that only about 40% of services used.

The idea was that if you write something very generic, you might grab just Utilities and then the more specific you get, the higher level package you need.

Unfortunately, due to how nuget works (see this bug i raised: https://github.com/NuGet/Home/issues/6770#issuecomment-378466082), if i was to update just Utilities for a project that also imports Bindings, when Bindings eventually gets an even higher Utilities, updating Bindings fails because my service imports Utilities directly.

What this means for us now is that if i want to update something in Utilities i need to modify code in X repositories (it's actually more than 3, but for simplicity of example i am keeping it way), where the last 2 are just updating dependency version, rebuild the stuff 3 times and wait for it to publish in my VSTS nuget feed.

As number of devs in the team grew, this became somewhat unwieldy, so we are even considering dropping all these libraries and moving to a single Complete Kit style lib.

The nuisance of that proposal is that this one has a ton of external domain-specific third-party dependencies that have nothing to do with 60% of my other services.

Any better suggestions on how to organise this?

EDIT I understand that Nuget won't let me directly bypass dependency chain. The question is really: how do i organise the code such that i can:

• only update classes(code) i need
• allow the generic service to NOT import all the dependencies of other domain's code
• allow the domain specific code access to the same classes from (a)

Answer 1

I know this pain well. Ran into this same issue at my company and we have almost 40 libraries that are managed in a similar regard. Redeploying the chain of them takes considerable tedious manual effort.

If you can map all of the dependencies you can deploy the packages in precedence order including committing to your repository. You can also use the pre-release feature for development which works amazingly.

Not a small task, but one that has abstracted all of this down to a single button click for me. I can deploy a chain of 20 nuget libraries in about 12 minutes all while working on something else.