[FEATURE REQ] Add `IConfiguration` integration for `TokenProvider` when using `AddAzureAppConfiguration()` about azure-sdk-for-net HOT 6 CLOSED

Thank you for your feedback. Tagging and routing to the team member best able to assist.

from azure-sdk-for-net.

Hi @julealgon. Thanks for reaching out and we regret that you're experiencing difficulties. I cannot speak for the extensions related to AddAzureAppConfiguration, as you've noted those are provided by the Microsoft.Extensions.Configuration.AzureAppConfiguration and maintained by the Azure SDK team.

Microsoft.Extensions.Azure allows for explicitly creating/setting a credential for clients via the AzureClientBuilder.UseCredential method, which also has an overload that allows you to define a credential factory, which I believe is the TokenProvider that you're asking about. More context and examples can be found in Dependency injection with the Azure SDK for .NET.

It is also possible to define the credential types recommended for production environments directly from configuration, allowing for both a global credential applied to all clients and credentials scoped to a specific service client. This allows credentials to be configured without the use of environment variables. More context and discussion can be found in Create Microsoft Entra credential types using configuration files.

That all said, I cannot speak for what Microsoft.Extensions.Configuration.AzureAppConfiguration may or may not support. If I understand correctly, the pattern that you're describing for creating/configuring the AppConfig provider is entirely defined in that package and may not fully integrate with Microsoft.Extensions.Azure. You may want to consider opening and issue in the repository where Microsoft.Extensions.Configuration.AzureAppConfiguration is maintained for your request.

I'm going to mark this as addressed, as I believe the feature that you're looking for needs to come from the AppConfig package. If I've misunderstood your scenario or request, please feel free to unresolve and continue the discussion.

from azure-sdk-for-net.

Hi @julealgon. Thank you for opening this issue and giving us the opportunity to assist. We believe that this has been addressed. If you feel that further discussion is needed, please add a comment with the text "/unresolve" to remove the "issue-addressed" label and continue the conversation.

from azure-sdk-for-net.

@jsquire

Hi @julealgon. Thanks for reaching out and we regret that you're experiencing difficulties. I cannot speak for the extensions related to AddAzureAppConfiguration, as you've noted those are provided by the Microsoft.Extensions.Configuration.AzureAppConfiguration and maintained by the Azure SDK team.

Yes. I'll probably open a separate request over there at least for the idea of providing an overload where the tokenProvider is defaulted to DefaultAzureCredential. I know that part is totally out of scope for this repo.

Microsoft.Extensions.Azure allows for explicitly creating/setting a credential for clients via the AzureClientBuilder.UseCredential method, which also has an overload that allows you to define a credential factory, which I believe is the TokenProvider that you're asking about. More context and examples can be found in Dependency injection with the Azure SDK for .NET.

None of that applies to the underlying client used by Azure AppConfiguration's standard integration though, as that client is used much earlier in the "host building" pipeline where not even the DI container is ready yet. My expectation was that, this package being a "helper for when using Microsoft.Extension.* abstractions", that it would also support the hosting aspect of Microsoft.Extensions, which it just doesn't at this point (it focuses only on the container-related aspects).

That all said, I cannot speak for what Microsoft.Extensions.Configuration.AzureAppConfiguration may or may not support. If I understand correctly, the pattern that you're describing for creating/configuring the AppConfig provider is entirely defined in that package and may not fully integrate with Microsoft.Extensions.Azure. You may want to consider opening and issue in the repository where Microsoft.Extensions.Configuration.AzureAppConfiguration is maintained for your request.

I'm going to mark this as addressed, as I believe the feature that you're looking for needs to come from the AppConfig package. If I've misunderstood your scenario or request, please feel free to unresolve and continue the discussion.

I disagree here. The purpose of Microsoft.Extensions.Azure is precisely to provide further helpers and abstractions to deal with Azure clients when leveraging Microsoft.Extensions constructs, like DI, but the entire hosting configuration abstraction is also part of that and has been ignored by this package.

This is why I feel adding such extensions here makes sense for this case. The native AppConfiguration package only concerns itself with the "raw" operations, while this here should add support for hosting, configuration, dependency injection and logging, which are all standard abstractions from Microsoft.Extensions.

Surely it would be possible to at least isolate the TokenCredential creation logic into a more reusable component that doesn't necessarily need DI integration? The core logic has zero dependencies and only takes an IConfiguration as parameter, which I have in the configuration stage. The only reason I can't currently use the factory directly is because extra dependencies it has for other behaviors, so right now it is clearly violating SRP and because of that making it hard or impossible for people to use just one aspect of its functionalities.

Before closing this issue, please reconsider extracting that logic that creates the token provider from config into a separate, public class, that more people can leverage. That would be an extremely simple way of allowing one to tap into the capability during configuration setup without needing you to write a bunch of custom extensions on top of AzureAppConfiguration (although that would probably be the ideal approach moving forward).

from azure-sdk-for-net.

@julealgon: I think there's a disconnect as to the intent and purpose of Microsoft.Extensions.Azure. The package is intended to provide the infrastructure to allow clients from the Azure SDK to be integrated with ASP.NET dependency injection and allow DI client creation to integrate with configuration. It is not intended to be a general-purpose utility package nor a helper for using the Microsoft.Extension.* abstractions.

When this package was created, IConfiguration was still tightly coupled to ASP.NET scenarios. In the time since, the .NET team has evolved IConfiguration into a more general abstraction. We are in the process of considering what a general story for IConfiguration support would look like in the Azure SDK, but those are still early efforts. What we do not want to do in the meantime is expand the scope of the Microsoft.Extensions.Azure package and either lock ourselves into a design or introduce potential confusion due to having competing ways to accomplish the same task.

from azure-sdk-for-net.

@jsquire

@julealgon: I think there's a disconnect as to the intent and purpose of Microsoft.Extensions.Azure. The package is intended to provide the infrastructure to allow clients from the Azure SDK to be integrated with ASP.NET dependency injection and allow DI client creation to integrate with configuration. It is not intended to be a general-purpose utility package nor a helper for using the Microsoft.Extension.* abstractions.

To me, these are basically synonyms at this point though, but fair enough.

When this package was created, IConfiguration was still tightly coupled to ASP.NET scenarios. In the time since, the .NET team has evolved IConfiguration into a more general abstraction. We are in the process of considering what a general story for IConfiguration support would look like in the Azure SDK, but those are still early efforts. What we do not want to do in the meantime is expand the scope of the Microsoft.Extensions.Azure package and either lock ourselves into a design or introduce potential confusion due to having competing ways to accomplish the same task.

I see. Well, if the team is already looking into native IConfiguration integration somewhere else, then I'm good.

For now, I'll try to keep this "as dumb as possible" for us and avoid defining any custom extensions and attempting to integrate with Microsoft.Extensions.Azure for this purpose then. I'll focus on just defining the 3 environment variables as per the requirements on EnvironmentCredential and go from there. It adds some overhead in terms of envvar management for us, but at least the application side is not that impacted.

I'm looking forward to those improvements you mentioned. I'm closing this then.

from azure-sdk-for-net.