3

I have an ASP.NET Core 2.1 API that I am deploying to an Azure App Service. I use Azure SQL Server for my backing databases.

Below is a screenshot of the App Service (base) Application Settings blade. This shows the .Net Framework version set to 4.7.

enter image description here

I have the App Service set up with deployment slots.

For each deployment slot, I have connection strings in the Application Settings blade with values specific to that slots databases (I have 3 different databases for each slot and I have 3 slots).

The QA and DEV slots have been working just fine for several months, however, we are now rolling the API out to beta sites using the Production slot (App Service base) and it seems that the connection strings in the Production slot for the App Service are not being reliable read. Specifically, it appears that the 2nd and 3rd connection string are not being reliably read.

Here is a screenshot of the App Service -->Application Setting blade showing the Connection Strings;

enter image description here

As you can see, I have Slot Settings checked for each. The HangfireDbConnectioinString always fails to be read and the UspsReferenceDbConnectionString seems to be flaky, but that may be because the Hangfire database is not getting set up and throws an exception.

I use this same setup for the QA and DEV slots and they work OK. This issue is only happening with the Production slot (base App Service) settings.

If I include the actual connection strings in my AppSettings.json file of my API and redeploy that to the Production slot, the API is able to access the databases correctly. Of course this is not a desirable solution because it puts my connection strings in source control.

In case it matters, here is a screenshot of the base App Service Extensions blade.

enter image description here

Below is the section of code in my Startup.cs that is setting up the databases.

    protected virtual void ConfigureDatabase(IServiceCollection services)
    {

        var sqlTransientErrors = new List<int>() { 10928, 10929, 10053, 10054, 10060, 40197, 40540, 40613, 40143, 64 };

        // Configure DBContexts with resilient SQL connections to SQL Server
        services.AddDbContext<ManifestContext>(options =>
        {
            options.UseSqlServer(Configuration.GetConnectionString("ManifestDbConnectionString"),
                sqlOptions =>
                {
                    sqlOptions.EnableRetryOnFailure(5, TimeSpan.FromSeconds(30),
                        sqlTransientErrors);
                    sqlOptions.CommandTimeout(Convert.ToInt32(Configuration["DbSettings:ManifestDbCommandTimeout"]));
                });
        });

        services.AddDbContext<UspsReferenceContext>(options =>
        {
            options.UseSqlServer(Configuration.GetConnectionString("UspsReferenceDbConnectionString"),
                sqlOptions =>
                {
                    sqlOptions.EnableRetryOnFailure(5, TimeSpan.FromSeconds(30), sqlTransientErrors);
                    sqlOptions.CommandTimeout(Convert.ToInt32(Configuration["DbSettings:UspsReferenceDbCommandTimeout"]));
                });
        });

        // Hangfire persistence store for background tasks
        services.AddHangfire(configuration =>
            configuration.UseSqlServerStorage(Configuration.GetConnectionString("HangfireDbConnectionString")));


    }

As you can see, I am using Configuration.GetConnectionString("HangfireDbConnectionString") to retrieve the connection string from Configuration.

Any ideas?

Jayendran
  • 9,638
  • 8
  • 60
  • 103
whiskytangofoxtrot
  • 927
  • 1
  • 13
  • 41

1 Answers1

0

This is a few years later and your question doesn't make it clear if you were deploying directly to production or deploying to one of your Deployment Slots then swapping to production.

But I'm currently investigating a similar issue and what I think is happening is that the Startup.cs code is only run once, and is not re-run after a deployment slot swap since the app is already warmed up. Since you are reading the config once in the startup.cs and saving it on app load (rather than re-reading each time you need it), you might be loading the values from you deployment slot and not replacing them after swapping to production.

IronSean
  • 1,520
  • 17
  • 31