Closed 0Lucifer0 closed 5 years ago
This is an ordering and ownership issue. The server creates the IServerAddressesFeature instance and maintains a reference to it. https://github.com/aspnet/KestrelHttpServer/blob/6551eae321cd6306b485906ea47e8d41e932d65b/src/Kestrel.Core/KestrelServer.cs#L58 https://github.com/aspnet/HttpSysServer/blob/91c518e13d7ede44e6cb88df895d9a242b07726e/src/Microsoft.AspNetCore.Server.HttpSys/MessagePump.cs#L56 If you provide your own implementation then the server doesn't know about it, it's still looking at the old one.
While possibly un-expected, it is working as intended. Do you have a specific reason for needing to set the feature?
Not really a specific reason and the 2nd solution (main) work great. But still seems like a bug because the logger use the new one so the logger say listening on port 1337 even if port is 5000. My initial goal was to try to change the port in the startup and not in the UseUrls
https://github.com/aspnet/Hosting/blob/f9d145887773e0c650e66165e0c61886153bcc0b/src/Microsoft.AspNetCore.Hosting/WebHostExtensions.cs make the console log to return something else than what we are really listening in this example
We periodically close 'discussion' issues that have not been updated in a long period of time.
We apologize if this causes any inconvenience. We ask that if you are still encountering an issue, please log a new issue with updated information and we will investigate.
Hello, it seems the ServerFeatures.Set doesn't work correctly.
this is a code sample to test this issue