-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Decouple the Kestrel transport layer from Microsoft.AspNetCore.Hosting #11479
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
Feels post-3.0 based on your description :). But sounds like goodness |
Work in 3.0:
Post 3.0:
|
This feels super at risk for 3.0. |
If we don't take it in 3.0, the next main place is 5.0 which isn't LTS anyway so it's perfect to do a major reshuffle like this. |
It's too late, among the other things, to try and squeeze this in. It sounds like a good fit for 5.0 though. |
Agreed |
Upvoted this ticket. I love Would be nice to have it available for generic host too. Actually it is doable now, maybe it is just an undoccumented feature?
|
Both Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets and Microsoft.AspNetCore.Server.Kestrel.Transport.Libuv depend on Microsoft.AspNetCore.Hosting because they expose extension methods on
IWebHostBuilder
, with the move to generic host and exposing the ability to create client connections from these transports (#10872), it's odd to have this dependency.It seems like to preserve
UseSockets
andUseLibuv
, we'll need to have extensions methods like these somewhere, either on theIWebHostBuilder
or on theIServiceCollection
. It seems like we'll need to introduce new packages to that have just the code without the extensions and another one that has the wire up code (much like we have the kestrel meta package today).cc @shirhatti @anurse
The text was updated successfully, but these errors were encountered: