Enable provider logging when running in Azure Functions

[zhenlan]

Azure Functions use ILogger, but our provider logging doesn't work out of the box today.

[zhenlan]

cc @avanigupta

[avanigupta]

Is this specifically for isolated mode or in-process? Or both?

[zhenlan]

Both, if possible, but will prioritize the isolated mode if we have to choose.

[goldsam]

How could this have been broken? If you take an injected dependency on ILoggerFactory or ILogger<XXX>, wouldn't this have worked in any environment?

[zhiyuanliang-ms]

@goldsam

When you are calling public static IConfigurationBuilder AddAzureAppConfiguration(this IConfigurationBuilder configurationBuilder, IEnumerable<string> connectionStrings, bool optional = false) method, how would you get access to DI container?

[goldsam]

@zhiyuanliang-ms

I see the issue and recognize this is a unique challenge. AzureAppConfigurationSource depends on services (indirectly via ConfigurationClientManager) that ideally would be injected such as ILoggerFactory/ILogger and ConfigurationClient.

Here are some ideas:

• Introduce a Func<IServiceProvider> ServiceProviderResolver {get; set;} property on AzureAppConfigurationOptions that would be used to lazily resolve an ILoggerFactory (and perhaps the ConfigurationClient as well).
• Introduce more specific callbacks such as Func<ILoggerFactory> LoggerFactoryResolver {get; set;}
• Introduce extensions methods on IConfigurationBuilder to store state in IConfigurationBuilder.Properties that could be used to resolve these services.

There are things in ConfigurationClientManager that could be exposed as part of the public API via AzureAppConfigurationOptions to solve the problem.

I think the common use case is to build an IConfiguration to which IOptions are bound. When AddOptions and Configure extension methods are used, these options are lazily resolved at runtime. The implication is that lazy options binding would occur after application startup when the DI container exists and the dependent services are available.