0

I've been interested in following what other successful libraries are doing with their nuget packages. Unfortunately, I can't seem to find any materials to read online and I don't even know what to search for.

What I'm referring to is how a nuget package can be broken down into something like this:

  • CompanyName
  • CompanyName.Core
  • CompanyName.Abstractions
  • CompanyName.DependencyInjections
  • CompanyName.{Feature}
  • Etc.

I kind of get the basic idea by just snooping around public repos on github but I wanted to read more about this. I know you'd generally make a separate project for feature related codes or common codes but what I currently don't quite get is the Abstractions and DependencyInjections. I know it's there to make it easier and flexible for the consumer but how exactly?

For Abstractions:

  1. Do I literally pull out all my interfaces and abstract classes and put it here?
  2. Where do I draw the line?

For DependencyInjections:

  1. Do all my IServiceCollection extensions live here?
  2. How would the consumer utilize this DependencyInjection? In my experience, I very seldom install both the main nuget package and DepedendencyInjections package. Most of the time, the main package is enough.

I would really appreciate if you can shed some light on this or better yet, give some reading materials I could read.

Thank you!

2
  • 3
    This isn't as standardized as you might think. To be honest, I've never dealt with a NuGet package that had "abstractions" and "dependency injections" sub-packages. I don't think any of us can give you an authoritative answer. Only the maintainers of those NuGet packages can answer your question. Jul 26, 2023 at 15:33
  • 1
    Well-established libraries are often split across packages to help with legacy .NET Framework projects using ancient versions of MSBuild/NuGet, where dependency management had traditionally been a major pain point. Library authors had to be careful only to depend on other packages that they really needed because larger projects could find themselves in "DLL Hell" with conflicting dependency versions from different libraries. The Modern NuGet/MSBuild/.NET ecosystem has made most of these problems go away so there's often no reason to split libraries across a lot of packages any more. Jul 26, 2023 at 21:01

0

Your Answer

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