Need a gut check. When building a client lib, you may want to include DI registration ext methods on IServiceCollection. But that requires a dependency on Microsoft.Extensions.DependencyInjection. Do you put that in the lib or do you create another package with those methods? - ThreadSky

haacked.com • 47 days ago

Need a gut check. When building a client lib, you may want to include DI registration ext methods on IServiceCollection. But that requires a dependency on Microsoft.Extensions.DependencyInjection. Do you put that in the lib or do you create another package with those methods?

Comments

hexmaster.nl•47 days ago

Depends, the dependency you take here is pretty common so I'd put it in the lib. If the dependency is something fancy, I'd give it a second thought

rainweaver.bsky.social•47 days ago

I think it’s a de facto standard nowadays, I’d say it’s fine. I for one am going down that path as well.

haacked.com•47 days ago

For now I’m adding a MyLibrary.Hosting package that adds the extension methods for registering and configuring it.

drusellers.com•47 days ago

I feel like that’s how a lot of libraries do just that. But in the end, it depends on how complex your registration is in my opinion. I would look at Serilog and Quartz as an example. 🤔

aaron-powell.com•47 days ago

What will the discoverability be like for having two different packages?

Obviously the Hosting package will depend on the other package, but does it seem like there'd be enough usages to warrant not having DI baked in as a first-party feature of the main package?

jeremydmiller.bsky.social•47 days ago

If you want to make your library a little harder to use, create as many adapter libraries as you can.

That dependency is small, and not that many people try to do w/o some kind of IHostBuilder bootstrapping

haacked.com•47 days ago

Yeah, I've come around to just putting it all in the main project.

martindotnet.bsky.social•47 days ago

In OpenTelemetry, we use a separate hosting package for that.

Honestly, though, that would literally never stop me using a library.

ormico.zackmoore.xyz•47 days ago

This is just an off the cuff answer, but I'm currently working on a major and painful framework upgrade made worse by too many un-needed cross dependencies; put it in a seperate pkg and use the abstraction instead of the big pkg if you can.

ormico.zackmoore.xyz•47 days ago

I get went you might not want to. It's extra work and it probably feels like who cares and will this really matter. And maybe it wont I dont know your context but I can tell you that on large projects these thing can make a difference when your dependency updates start cascading & things aren't neat

ormico.zackmoore.xyz•47 days ago

Otoh maybe maybe it doesn't matter if the intended use always includes DI just consider whether it's an issue if dotnet changes the DI interface and your pinned to a specific interface or pkg version

kevindoyon.com•47 days ago

I don't know the best practice, but there's also Microsoft.Extensions.DependencyInjection.Abstractions

Comments

Posting Rules

Reply