Dispose configuration in WebHost #9149
Conversation
|
/cc @davidfowl |
poke
force-pushed
the
extensions-938-webhost-dispose-configuration
branch
from
66bb9e4 to
b8317c9
Compare
|
The disposal of the host configuration depends on the changes to |
poke
force-pushed
the
extensions-938-webhost-dispose-configuration
branch
from
b8317c9 to
318a31b
Compare
|
Since there wasn’t any PR from the bot over the course of the day that increased the version on the M.E.Configuration package, I just went totally rogue and edited the section that “should ONLY be updated by automation”… manually. That way, I can at least compile the final version of this change and hopefully it does work on the CI end too. If we need to wait for a proper update of the versions, then that’s of course fine with me too. |
|
Yeah, we're going to need to wait for the rest of Extensions deps to get updated. Pulling just one isn't a good idea. @dougbu can you notify us here after the next update? |
|
I don’t have the tools so that’s the best I can do right now 😁 And yeah, the CI really doesn’t like this apparently 😅 But at least I could push the latest code out, so you can look over it even if it’s not ready to merge yet. |
We should get new packages from EntityFrameworkCore and AspNetCore-Tooling every day. Those pull in the latest coherent Extensions packages. Coherency usually means Extensions build from day 1 is pulled into EF and Tooling on day 2 and those are pulled into this repo on day 3. Of course, the packages are all reving in parallel. Which specific Extensions build are you looking for? |
|
@dougbu 3.0.0-preview5.19208.3 or later |
|
🆗 3.0.0-preview5.19208.3 Extensions packages should be in AspNetCore tomorrow morning. AspNetCore-Tooling and EntityFrameworkCore have them now. And, both have had successful official builds since taking those dependencies. |
poke
force-pushed
the
extensions-938-webhost-dispose-configuration
branch
from
318a31b to
a4a3656
Compare
|
The dependencies arrived and the PR is updated! Should be good to go now 😊 |
|
[Ongoing build outage, I'll followup] |
|
Yeah, I know, I’m already keeping an eye on #9263 and am ready to rebase to make the CI green. |
Register the application configuration as a factory to make it dispose automatically when the service provider gets disposed. This will dispose the underlying configuration providers and change token registrations. The host configuration will be disposed implicitly when the chained configuration provider within the app configuration gets disposed.
poke
force-pushed
the
extensions-938-webhost-dispose-configuration
branch
from
a4a3656 to
11e1462
Compare
|
It’s green! 🎉 🎉 |
|
Thanks :-) |
This is a companion-PR to dotnet/extensions#1361 which addresses dotnet/extensions#938: When disposing the WebHost, the underlying configurations will also be disposed by the service provider.
Since theIConfigurationthat is passed to theWebHostconstructor is the host configuration, and does not access the configuration directly (theStartupmay though), theWebHosthas to resolve the app configuration from the service provider. This is done early withinInitializeas soon as the service provider is available to avoid having to retrieve it later only for disposal.The host configuration is also disposed
by thetransitively. While the host configuration only ever contains a single environment variables configuration provider (which is not disposable itself), disposing the configuration will also make sure to dispose the change registration.WebHostThe drawback for this is that using the
WebHostBuilder.GetSetting()after the web host is disposed means that the operation is made on an already disposed configuration root. The way the configuration root is currently implemented, this should not actually prevent this from working though.