I have built two test net core mvc test apps using Microsoft tutorials.

1. Build an app that uses a connection string for using Azure App Configuration

   Quickstart: Create an ASP.NET Core app with Azure App Configuration

2. Build an app that uses managed identity for using Azure App Configuration (my app TestAppConfigMi)

   Use managed identities to access App Configuration

The first test works running locally using a connection string. The second has errors that indicate the Azure App Configuration endpoint or clientid is null.

• the endpoints are the same for both apps
• the clientid may not be correct but is present in the second app

I don't have much experience. My troubleshooting process has been:

• TestAppConfigMi project builds locally in Visual Studio
• In Azure browser launches with HTTP 500.30

Azure diagnostics

Application: w3wp.exe
CoreCLR Version: 5.0.921.35908
.NET Version: 5.0.9
Description: The process was terminated due to an unhandled exception.
Exception Info: System.ArgumentNullException: Value cannot be null. (Parameter 'uriString')
at System.Uri..ctor(String uriString)
at TestAppConfigMi.Program.<>c__DisplayClass1_0.<CreateHostBuilder>b__2(AzureAppConfigurationOptions options) in D:\a\TestAppConfigMi\TestAppConfigMi\Program.cs:line 29
at Microsoft.Extensions.Configuration.AzureAppConfiguration.AzureAppConfigurationSource.<>c__DisplayClass3_0.<.ctor>b__0()
at Microsoft.Extensions.Configuration.AzureAppConfiguration.AzureAppConfigurationSource.Build(IConfigurationBuilder builder)
   at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build()
   at Microsoft.Extensions.Hosting.HostBuilder.BuildAppConfiguration()
   at Microsoft.Extensions.Hosting.HostBuilder.Build()
   at TestAppConfigMi.Program.Main(String[] args) in D:\a\TestAppConfigMi\TestAppConfigMi\Program.cs:line 17

In Program.cs (line 29)

options.Connect(new Uri(settings["AppConfig:Endpoint"]), new ManagedIdentityCredential("26e962f7-1a26-4f11-84d4-3bfcdd9f7dcc"))

(line 17)

CreateHostBuilder(args).Build().Run();

In Visual Studio AppConfig:Endpoint in appsettings.json

"AppConfig": {
"Endpoint": "xxxx"

is the same as that of secrets.json in the first working app

    {
  "ConnectionStrings:AppConfig": "Endpoint=xxxxx"
}

There are two packages installed: Azure.Identity 1.5.0 Microsoft.Azure.AppConfiguration.AspNetCore 4.5.0

The debug reference is an identifier being null. Whichever way I look at it there is a value present. So I would expect a "not found" or "wrong credentials" type message. Not the app failing as it does.

CodePudding user response：

Reading the stack trace:

Exception Info: System.ArgumentNullException: Value cannot be null. (Parameter 'uriString')

at System.Uri..ctor(String uriString) //<== BAM!

So settings["AppConfig:Endpoint"] must be returning null:

options.Connect(new Uri(settings["AppConfig:Endpoint"]), 

Fix that and you have fixed your (current) problem.

To check your providers are runtime, just debug and inspect settings you will see a list of all the available providers and their resolved values, my guess is it's a typo, or it doesn't exist.

CodePudding user response：

I fixed this problem using the following changes:

Here is the Microsoft tutorial code Use managed identities to access App Configuration

public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
    .ConfigureWebHostDefaults(webBuilder =>
        webBuilder.ConfigureAppConfiguration((hostingContext, config) =>
        {
            var settings = config.Build();
            config.AddAzureAppConfiguration(options =>
                options.Connect(new Uri(settings["AppConfig:Endpoint"]), new ManagedIdentityCredential()));
        })
        .UseStartup<Startup>());

Here is the working code running locally (VS Azure Service Authentication & me having System Managed Identity Data Owner & Data Reader Roles for the Azure App Configuration service) & deployed to Azure (App Service System Managed Identity Data Owner & Data Reader Roles for the Azure App Configuration service)

public static IHostBuilder CreateHostBuilder(string[] args) =>
 Host.CreateDefaultBuilder(args)
    .ConfigureWebHostDefaults(webBuilder =>
        {
            webBuilder.ConfigureAppConfiguration((hostingContext, config) =>
            {
                var settings = config.Build();
                var appConfigurationEndpoint = settings["AzureAppConfigurationEndpoint"];

                config.AddAzureAppConfiguration(options =>
                    {
                        options.Connect(new Uri(appConfigurationEndpoint), new DefaultAzureCredential());
                    });

                webBuilder.UseStartup<Startup>();
            });
        });

The appsettings.json is:

    {
  "Logging": {
    "LogLevel": {
      "Default": "Information",
      "Microsoft": "Warning",
      "Microsoft.Hosting.Lifetime": "Information"
        
    }
  },
  "AllowedHosts": "*",

  "AzureAppConfigurationEndpoint": "https://xxxxxxxxxxx.azconfig.io"
}

I have not examined the reasons why these changes make the difference. I should! But to be practical this is just a small module of a larger project. However I did try various combinations (trying to include as much tutorial code as possible)

I think the issue is that local development needs to be successful before cloud deployment. Therefore we need code that works seamlessly across both environments. So the use of DefaultAzureCredential() rather than ManagedIdentityCredentials() would seem preferable.

I note the Azure.Idntity docs state that the latter ManagedIdentityCredentials() "Attempts authentication using a managed identity that has been assigned to the deployment environment" but does not detail why the former DefaultAzureCredential() is only "intended to simplify getting started with the SDK by handling common scenarios with reasonable default behaviors"?

However it would seem to me that a basic tutorial, such as this one, should consider terms such as "getting started" & "simplification" to be a priority. Also the importance of seeing code working locally should not be underestimated.

I would welcome comments by anyone on these changes. In particular the way the Azure App Configuration endpoint is handled in each example.