Thank you for the additional information.
So basically the issue is this- App Configuration loads it's information into .NET Core's Configuration system. The advantage with this is that it can load data from multiple places, including your environment variables. It looks like, as you have noticed that the AWS SDK currently specifically targets environment variables instead. Fortunately, there is a Environment.SetEnvironmentVariable()
method you can use to essentially transfer the values from the Configuration system into your Environment variables.
So if I modify the ASP.NET Core tutorial for App Config I get something like this:
public static IHostBuilder CreateHostBuilder(string[] args) =>
Host.CreateDefaultBuilder(args)
.ConfigureWebHostDefaults(webBuilder =>
{
webBuilder.ConfigureAppConfiguration((hostingContext, config) =>
{
//building the config at this point loads in things like environment variables and configuration files so you can get to your connection string
var settings = config.Build();
config.AddAzureAppConfiguration(options =>
{
options.Connect(settings["ConnectionStrings:AppConfig"])
});
//new code
//Just like we did to get the connection string, building the config will load in the App Configuration data
settings = config.Build();
Environment.SetEnvironmentVariable("<AWS Setting">, settings["<AWS Setting>"]);
//The AWS SDK calls this method which will now be populated with the value from App Config
var result = Environment.GetEnvironmentVariable("<AWS Setting");
});
webBuilder.UseStartup<Startup>();
});
}
If you'd like an alternative to App Config and you are using something built within App Services, App Services allows you to enter a Key Vault reference as an app setting. The downside to this is that the reference has to include the version, so if you rotate keys you will have to go in and update the app settings. App Config also allows Key Vault references, but it has the advantage of handling the versioning for you.