Is this a safe assumption? Can't any FileConfigurationSource have Build called more than once?

Also, I've noticed others implement IConfigurationBuilder before. Some are forks of ConfigurationManager, others are unique. I can share some data offline.

A couple other options to consider:

1. Just create a new FileProvider if the previous one is disposed. The logic for creating a new one isn't specific to the provider (it's implemented in an extension method we own IIRC).
2. Share a single FIleProvider for default and don't dispose it. We still leak until finalization, but only one is leaked.
3. Implement ref-counting, or disposal pattern for the source. If we just add IDispose to the source impl, will it get called by whichever component manages it's lifetime today?

@ericstj Thank you for feedback! A lot of good questions! Here are my findings:

Is this a safe assumption? Can't any FileConfigurationSource have Build called more than once?

ConfigurationManager can call it more than once. It's called by ReloadSources which is called... anytime a source is being deleted, inserted or any property changes

Also, I've noticed others implement IConfigurationBuilder before. Some are forks of ConfigurationManager, others are unique.

ConfigurationManager is sealed, I could change this condition from to check for explicit type.

Just create a new FileProvider if the previous one is disposed.

I was thinking about it. The idea I had was to null the FileProvider after disposing it and let ReloadSources re-assign it:

But then I've realized that ReloadSources creates new providers firsts, then tries to replace (it needs new ones to get rid of old ones) them:

and it tries to do that in thread-safe way:

Changing the order would most likely be possible, but I don't see a possibility to do it in a simple way with low risk (I was searching for a fix that could be backported to 8.0)

Share a single FIleProvider for default and don't dispose it. We still leak until finalization, but only one is leaked.

This is something I've not considered. How would it affect perf on various OSes? Is it better to have a single instance of PhysicalFilesWatcher rather than many?

Currently a new instance if being allocated if the user has not configured a default one (but I don't know whether for example ASP.NET does not do that somewhere else):

Implement ref-counting

I am not a big fan of ref-counting (it's hardly ever implemented properly and always brings a lot of complexity).

or disposal pattern for the source. If we just add IDispose to the source impl, will it get called by whichever component manages it's lifetime today

From my perspective, the main issue is that ConfigurationRoot is given with a list of providers, but it does not have reference to the sources. So it can not dispose the sources with the current public API.

ConfigurationManager has both and can dispose either one or both of them.

In #100642 I've extended the provider abstraction with a reference to source (most of the implementations already implement a property that returns the source). It allows for disposing what is needed. But introducing a new public API would be a breaking change (so it can not be backported).

Is this a safe assumption? Can't any FileConfigurationSource have Build called more than once?
...

ConfigurationManager is sealed, I could change this condition from to check for explicit type.

My point was that special casing ConfigurationManager isn't really a fix. Anyone can call

IConfigurationSource source = new DerivedFileConfigurationSource();
using (IConfigurationProvider provider = source.Build(builder)) { }
using (IConfigurationProvider provider = source.Build(builder)) { }

I believe it's intentional that Sources can produce multiple providers. So we really shouldn't assume that the provider can dispose resources held by the source.

Just create a new FileProvider if the previous one is disposed.
...
Changing the order would most likely be possible, but I don't see a possibility to do it in a simple way with low risk (I was searching for a fix that could be backported to 8.0)

Maybe you don't need to change the order - if your design is to delegate the lifetime of the FileProvider to the IConfigurationProvider then you should really be creating a new FileProvider for each call to Build. I think this is the solution that's most consistent with the change you made.

Share a single FIleProvider for default and don't dispose it. We still leak until finalization, but only one is leaked.
This is something I've not considered. How would it affect perf on various OSes? Is it better to have a single instance of PhysicalFilesWatcher rather than many?

I think it's a tradeoff (but @jozkee might have a better idea as he's our resident FSW expert). I think some systems have expense per-watcher like a background thread and kernel buffers - and those can approach a limit - so more of them uses more resources or could hit the limit - thus the whole polling watcher. From the same token those kernel buffers associated with a watcher limit how many events it can buffer between callbacks - so giving more work to a single one could result in events lost. At least for servicing - let's try to keep the same number of watchers as before. Folks can always set the provider if they want to experiment with a single FSW for perf. If you can see a better option for vNext we can consider that.

Agreed that RefCounting is too big and complex. I think a clear assignment of responsibility of lifetime for the file-provider is what we want. If it's possible to transfer the responsibility to the source and have the source's lifetime managed by something we could do that in the future. I don't think we should make the provider responsible for lifetime of resources held by the source - this regression made it clear that their lifetimes (and instance counts) differ.

Bumping this @adamsitnik