-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Allow access to child providers in ChainedConfigurationProvider #44486
Comments
Tagging subscribers to this area: @maryamariyan Issue meta data
|
With the upcoming .NET 6 release, when |
@avanigupta are you still blocked by this or you already have the workaround? /cc @halter73 |
@maryamariyan , we are still blocked since there's no clean workaround for this. |
I investigated this with @avanigupta before the 6.0 release and we confirmed that this is no longer the case in the final release. However, I realize the original issue wasn't about a regression in 6.0, but instead was asking for the ability to enumerate a I think the proposal is basically: namespace Microsoft.Extensions.Configuration
{
public class ChainedConfigurationProvider : IConfigurationProvider, IDisposable
{
+ /// <summary>
+ /// The chained <see cref="IConfigurationProvider"/> instances.
+ /// </summary>
+ IEnumerable<IConfigurationProvider> Providers { get; } And then the usage in // This code is from the ctor of a singleton service that injects IConfiguration configuration.
var configurationRoot = configuration as IConfigurationRoot;
var refreshers = new List<IConfigurationRefresher>();
if (configurationRoot != null)
{
+ void AddRefreshers(IEnumerable<IConfigurationProvider> providers)
+ {
- foreach (IConfigurationProvider provider in configurationRoot.Providers)
+ foreach (IConfigurationProvider provider in providers)
{
if (provider is IConfigurationRefresher refresher)
{
// Use _loggerFactory only if LoggerFactory hasn't been set in AzureAppConfigurationOptions
if (refresher.LoggerFactory == null)
{
refresher.LoggerFactory = _loggerFactory;
}
refreshers.Add(refresher);
}
+ else if (provider is ChainedConfigurationProvider chainedProvider)
+ {
+ AddRefreshers(chainedProvider.Providers);
+ }
}
+ }
+
+ AddRefreshers(configurationRoot.Providers);
} I didn't bother reindenting the code now in the local This is being done so a custom service can reference the configuration providers added by the call to In an ideal world, there would be a single API to both add the @avanigupta What happens if someone tries to call |
Google took me here, I have a similar issue. in Program.cs I build my IConfiguration, then I pass it into WebHostBuilder()UseConfiguration(config) that uses "UseStartup(). I am on Core 3.1, and It fails to register the Azure Configurations too, at IApplicationBuilder.UseAzureAppConfiguration() Is there a workaround for my scenario? |
The easiest workaround probably would be to build your configuration using the Or, if you can upgrade to .NET 6, you could use WebApplicationBuilder.Configuration ConfigurationManager. |
Thanks, @halter73 for that. Both are good solutions for us (not perfect), as a short term solution I applied your first suggestion and refactored my own code to this:
.AddConfigs() is the custom method into which I moved all of our IConfigurationBuilder additions and ended up calling this AddConfigs() twice. |
I was able to resolve it without duplicating the builder code, by configuring the DI using
That resulted in getting the |
During discussion it was believed that exposing the IConfiguration directly instead of inventing the IEnumerable for it was a better approach. namespace Microsoft.Extensions.Configuration
{
public partial class ChainedConfigurationProvider : IConfigurationProvider, IDisposable
{
public IConfiguration Configuration { get; }
}
} |
API Proposal
This API proposal provides the ability to enumerate a
ChainedConfigurationProvider
's child providers:Motivation
Developers tend to add their configuration source via a ChainedConfigurationSource/Provider and they would want to access it from the outer
ConfigurationRoot
.ConfigurationRoot
exposedProviders
. With this new API now, configuration providers that are nested under aChainedConfigurationProvider
if the user callsIConfigurationBulder.AddConfiguration(...)
would now also be able to be accessed.Usage
Sample usage can be found in AzureAppConfigurationRefresherProvider under the Azure/AppConfiguration-DotnetProvider repo.
Original Description
We have an issue in Azure App Configuration where
AzureAppConfigurationProvider
could be nested under aChainedConfigurationProvider
if the user callsIConfigurationBuilder.AddConfiguration(...)
to add configuration built from the App Configuration provider.Sample code snippet of this use case:
Unfortunately, ChainedConfigurationProvider does not provide a way for others to access its child providers. This caused the issue that the App Configuration middleware could not find the instance of AzureAppConfigurationProvider (because in this case its under ChainedConfigurationProvider) and thus cannot obtain the instance of IConfigurationRefresher, which is responsible for refreshing the application configuration (our relevant middleware code here).
Would it be possible to expose the underlying providers in ChainedConfigurationProvider so that we can extract AzureAppConfigurationProvider and enable users to leverage our dynamic refresh functionality?
The text was updated successfully, but these errors were encountered: