Added overload for DaprClient DI registration

[WhitWaldo]

Description

Today, an extension method enables easy DI registration of the DaprClient on an IServiceCollection, but it doesn't allow for an IServiceProvider to be passed in so values can be pulled from injected dependencies. Having this option has some benefits - for example, say I'm passing in configuration values via a JSON file or environment variables. I could trivially register the values for either in the service's IConfiguration (e.g. services.Configuration.AddEnvironmentVariables(); and recall via configuration.GetValue<string>("DAPR_HTTP_ENDPOINT"), but only if I can get an instance of the IConfiguration to get the values out of. That's not available in the DI registration extension today, so this PR contributes an overload that provides it.

Where today, we might use the following:

var builder = WebApplication.CreateBuilder(args);
var httpEndpoint = Environment.GetEnvironmentVariable("DAPR_HTTP_ENDPOINT");
builder.Services.AddDaprClient(opt => {
  opt.UseHttpEndpoint(httpEndpoint);
});

This additional overload would also enable the following:

var builder = WebApplication.CreateBuilder(args);
builder.Configuration.AddEnvironmentVariables("DAPR_");
builder.Services.AddDaprClient((serviceProvider, daprClient) => {
  var configuration = serviceProvider.GetRequiredService<IConfiguration>();
  var httpEndpoint = configuration.GetValue<string>("HTTP_ENDPOINT");
  daprClient.UseHttpEndpoint(httpEndpoint);
});

I use it here to inject a value out of environment variables, but it could just as easily be a secret out of an Azure Key Vault instance or a value passed from Azure App Configuration or anything else that's registered in the application.

I don't know that there's anywhere in the documentation this is specifically called out, but I'll give the docs another pass.

Issue reference

We strive to have all PR being opened based on an issue, where the problem or feature have been discussed prior to implementation.

Please reference the issue this PR will close: #1288

Checklist

Please make sure you've completed the relevant tasks for this PR, out of the following list:

• Code compiles correctly
• Created/updated tests
• Extended the documentation

[philliphoff]

@WhitWaldo How would this interact with the AddDaprConfigurationStore() and AddDaprSecretStore() methods which, themselves, take a DaprClient argument? Would that end up in a circular-reference-like situation?

[WhitWaldo]

@philliphoff I can't say I've ever really tried to inject something to use when configuring an IConfigurationBuilder before, so I've tried to research if this is something other configuration providers do. As you can bind to secrets in the Key Vault, I took at look at their extension methods and they don't have an overload for IServiceCollection either.

In theory, I think you'd be able to do something like:

public static IConfigurationBuilder AddDaprConfigurationStore(this IConfigurationBuilder builder, IServiceCollection serviceCollection)
{
  var daprClient = serviceCollection.BuildServiceProvider().GetRequiredService<DaprClient>();
  // Remainder..
}

And that would eliminate any circular dependencies as the DI provider would be scoped just to that method, but I don't know that I've ever seen anyone actually do something like that. I guess I've always seen configuration happen first, then an IConfiguration passed into other DI registrations as necessary, not vice versa.

Regardless, this PR wouldn't create any such circular dependency in the case of AddDaprConfigurationStore or AddDaprSecretStore as the DaprClient isn't being injected here and an instance would have to be built with the static method for either of those use cases.

It's potentially worth doing more research to see if there's anything out there by which configuration is performed using a DI-registered service, but again, I'm not aware of anything off the top of my head.

[WhitWaldo]

I looked at the implementation for both the Azure Key Vault configuration provider extension methods and those for the Azure App Configuration provider and neither one incorporates a mechanism to utilize an injected service during configuration registration, so I think we'd be safe leaving the Dapr configuration extensions untouched (again, no circular dependencies as nothing gets injected to them).

[marcduiker]

@holopin-bot @WhitWaldo Thanks Whit!

[holopin-bot]

Congratulations @WhitWaldo, the maintainer of this repository has issued you a badge! Here it is: https://holopin.io/claim/clzva0z1y01600cihk1fhjab7

This badge can only be claimed by you, so make sure that your GitHub account is linked to your Holopin account. You can manage those preferences here: https://holopin.io/account.
Or if you're new to Holopin, you can simply sign up with GitHub, which will do the trick!