0
votes

I've got a webapp for containers running in Azure that I have working locally with a local appsettings file.

once I deploy to Azure, I want the container to pull appsettings values from the azure settings. These are set via AzureDevops and appear correctly when I check the portal.

However, the site is not pulling the appsettings values from Azure once deployed. It is using the ones from the file. I am using the double-underscore names as specified.

I have created a testcontroller to output the appsettings values. This is an a snippet of what the test view outputs:

Build version: 2019.1.23.1
Location: local
Database__DatabaseConnectionString: Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=application;Data Source=.
---
-------
Env vars: Key WEBSITE_AUTH_SIGNING_KEY Value ASDS*(&*&*(SDSD05C29
Key DOTNET_RUNNING_IN_CONTAINER Value true
Key WEBSITE_ROLE_INSTANCE_ID Value 0
Key Database__DatabaseConnectionString Value Server=tcp:servername01.database.windows.net,1433;Initial Catalog=application;Persist Security Info=False;User ID=applicationUser;Password=password;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;
Key APPSETTING_Database__DatabaseConnectionString Value Server=tcp:servername01.database.windows.net,1433;Initial Catalog=application;Persist Security Info=False;User ID=applicationUser;Password=password;MultipleActiveResultSets=False;Encrypt=True;TrustServerCertificate=False;Connection Timeout=30;

As can be seen, the Database__DatabaseConnectionString should be consumed by the app. But it's not being.

What could be the problem here? This should be standard functionality according to the aspnetcore documentation.

1

1 Answers

0
votes

Turns out this was a bug in the application. The controllers in question has an injected IOptions being injected into the constructor. Unfortunately, one of the controllers had different behaviour as a concrete instance was being inject in instead. As this object was not being correctly initialised in Startup.cs, this has the effect of passing empty values into the constructor.

Finally as empty values were found, this mean the default appsettings.json values were used.

Having fixed this above bug (by ensuring all controller use the same IOptions values), the azure appsettings values are being picked up and used correctly by the application at startup time.