I just started a new job and one of my first tasks is to create local nuget packages from the existing libraries, to help with versioning, maintenance, etc. This task had already been started by another engineer. However, he chose to grab many libraries that relate, create a project holding all these libraries, and publish it as one package (specifically a nuget package).

LibraryA_v1 + LibraryB_v2 + LibraryC_v3 = PackageA_v1
LibraryB_v1 + LibraryC_v3 = PackageB_v2

Then, PackageA_v1 and/or PackageB_v2 would be referenced by whatever project that needs them. However, I see a lot of different problems with this approach.

  1. PackageA_v1 and PackageB_v2 are extremely unstable. Anytime a library changes, the package would need to update.
  2. Since the packages are unstable, it is highly likely that the principle "Depend upon packages whose I metric is lower than yours" would be broken.
  3. I can't seem to access the libraries within the packages (in a simple C# test application), which was the original intent.
  4. The last problem I see is that libraries of different versions could be imported into the same project, possibly causing problems (ex. LibraryB_v1 and LibraryB_v2 would be in the same project, if PackageA_v1 and PackageB_v2 are both referenced)

From my studies in software engineering and the principle previously mentioned, I think each library should be kept separate in their own nuget packages. However, my co-worker had obviously thought differently. So, should libraries be packaged together based on similar traits?

  • 1
    I generally agree with you. The packages should roughly be the same granularity as your C# projects. Jan 7, 2019 at 21:23

1 Answer 1


You shouldnt bundle libraries together into packages at all.

Put each library in its own package and use the nuspec dependencies to indicate if one relies on another

  • Great point on using nuspec dependencies. I think this is what they're really looking for too.
    – Corey P
    Jan 8, 2019 at 13:47

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.