I've got an azure app service that I've set up like this:
But when I call IConfiguration.GetConnectionString("db")
I get null
back.
I've read articles like this https://mderriey.com/2018/08/21/azure-app-service-connection-strings-and-asp-net-core/ which say "it just works", but they're all several years old. I assume something's changed, but what?
Enumerating over all settings in my IConfiguration
object I've got no connection strings. I do in development, where my appsettings.development.json
has a connectionStrings: { db: "" }
defined.
I can see and read the ENV variable: POSTGRESQLCONNSTR_db
from within code, and it's value is correct (what I've set via the Azure portal).
Should I expect to be able to do IConfiguration.GetConnectionString("db")
? Or am I expected to switch between reading env variables in prod vs dev.
Do I need to include some nuget package to make IConfiguration
work under Azure with these ENV variables and their mad prefixes?
My startup.cs
basically looks like:
public Startup(IConfiguration configuration)
{
this.Configuration = configuration;
}
public IConfiguration Configuration { get; }
Nothing else in there of interest to this question.
I got confused as well, so here it is:
You have two options to specify Connection String locally:
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development",
"SQLAZURECONNSTR_SomeConnectionString": "DefaultEndpointsProtocol=blah"
}
"ConnectionStrings": {
"SomeConnectionString": "DefaultEndpointsProtocol=blah"
}
Having either way will allow you to get the connection string setting by calling:
IConfiguration.GetConnectionString("SomeConnectionString")
Function call above will also work when deployed to Azure, as it is using EnvironmentVariables
configuration provider to read settings.
The POSTGRESQLCONNSTR_
prefix isn't supported by the environment variables configuration provider. The docs shows this, in an indirect fashion, where it states that the following prefixes are supported:
CUSTOMCONNSTR_
MYSQLCONNSTR_
SQLAZURECONNSTR_
SQLCONNSTR_
It's also apparent in the source code for the provider.
There are a couple of options for working around this:
Custom
in the Connection strings section of the Azure portal.ConectionStrings:db
in the Azure portal.This is being tracked on GitHub: https://github.com/dotnet/runtime/issues/36123.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With