[API Proposal]: IConfigurationRoot should derive from IDisposable

[adamsitnik]

Background and motivation

When working on #86146 I've realized that ConfigurationBuilder.Build returns an instance of IConfigurationRoot, which does not derive from IDisposable, but all implementations of IConfigurationRoot implement IDisposable. So the users need to cast the result returned by ConfigurationBuilder.Build to IDisposable and call Dispose themselves to cleanup the resources properly.

IConfigurationRoot config = new ConfigurationBuilder().AddXmlFile("settings.xml", false, true).Build();

(config as IDisposable)?.Dispose();

API Proposal

namespace Microsoft.Extensions.Configuration;

- public interface IConfigurationRoot : IConfiguration
+ public interface IConfigurationRoot : IConfiguration, IDisposable
{
    /// <summary>
    /// Force the configuration values to be reloaded from the underlying <see cref="IConfigurationProvider"/>s.
    /// </summary>
    void Reload();

    /// <summary>
    /// The <see cref="IConfigurationProvider"/>s for this configuration.
    /// </summary>
    IEnumerable<IConfigurationProvider> Providers { get; }
}

API Usage

using IConfigurationRoot config = new ConfigurationBuilder().AddXmlFile("settings.xml", false, true).Build();

Alternative Designs

No response

Risks

Any custom implementations of IConfigurationRoot that don't implement IDisposable will have to implement it, moreover users of IConfigurationRoot will most likely get a compiler warning about not disposing the instance.

Without introducing the mentioned changes we risk common resource leaks like in #86146.

Tagging subscribers to this area: @dotnet/area-extensions-configuration
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Background and motivation

When working on #86146 I've realized that ConfigurationBuilder.Build returns an instance of IConfigurationRoot, which does not derive from IDisposable, but all implementations of IConfigurationRoot implement IDisposable. So the users need to cast the result returned by ConfigurationBuilder.Build to IDisposable and call Dispose themselves to cleanup the resources properly.

IConfigurationRoot config = new ConfigurationBuilder().AddXmlFile("settings.xml", false, true).Build();

(config as IDisposable)?.Dispose();

API Proposal

namespace Microsoft.Extensions.Configuration;

- public interface IConfigurationRoot : IConfiguration
+ public interface IConfigurationRoot : IConfiguration, IDisposable
{
    /// <summary>
    /// Force the configuration values to be reloaded from the underlying <see cref="IConfigurationProvider"/>s.
    /// </summary>
    void Reload();

    /// <summary>
    /// The <see cref="IConfigurationProvider"/>s for this configuration.
    /// </summary>
    IEnumerable<IConfigurationProvider> Providers { get; }
}

API Usage

using IConfigurationRoot config = new ConfigurationBuilder().AddXmlFile("settings.xml", false, true).Build();

Alternative Designs

No response

Risks

Any custom implementations of IConfigurationRoot that don't implement IDisposable will have to implement it.

Without introducing the mentioned changes we risk common resource leaks like in #86146.

Author:	adamsitnik
Assignees:	-
Labels:	api-suggestion, untriaged, area-Extensions-Configuration
Milestone:	-

[ericstj]

I'm not sure the IConfigurationRoot is solely responsible for owning the FileProvider. Instead I think we should try to look at what's the best practice for lifetime management (and instance management) of the FileProvider. IMO it should be higher in the stack here. Might make sense to ask the original architects what they had in mind @davidfowl @eerhardt @halter73

[adamsitnik]

I'm not sure the IConfigurationRoot is solely responsible for owning the FileProvider.

My main goal of this proposal was to prevent similar resource leaks by letting the users know that ConfigurationBuilder.Build always returns something that implements IDisposable. I expect that very few users perform following IDisposable check:

IConfigurationRoot config = new ConfigurationBuilder().Build();

(config as IDisposable)?.Dispose(); // this is the problem

In most cases it's probably fine, as the config usually lives as long as the app does. But it's definitely not 100% of all the use cases (a good example are test projects which may create a lot of such instances).

[ericstj]

My point was that I'm not convinced that IConfigurationRoot / IConfigurationProvider should be the one's who own the file provider. For them to solely own it - that's an awful lot of FileProviders we end up creating. So if they don't own it then some other component would own it and these would need to implement ref-counting.

I think a better solution is that we have a single FileProvider and try to plumb the lifetime of that into some part of the app model so that we don't need ref counting.