0

Using the first-ever template that I created in dotnet new, I generated a solution in Visual Studio 2022 with an ASP.NET Core Web API project; this project contains an appsettings.json file and a controller with a GET action, which retrieves a company with a name property:

public class Company
{
    public in ID { get; init; }
    public string Name { get; init }
}

I have a staging and a production SQL database.

The staging database has a company with the name "StagingCompany". The production database has a company with the name "ProductionCompany".

I first test the Web API using a connection string to my staging database, and I GET the company named "StagingCompany" as I would expect.

However, when I change the connection string to point to my production database, I still GET the company named "StagingCompany" when I was expecting to get "ProductionCompany". When I debug my code, I can see that the desired production connection string is being loaded during the Program.cs dependency injection, so I don't believe this is an issue of my appsettings.json connection string being overridden by another connection string from some other mysterious config file:

builder.Services.AddDbContext<CompanyContext>(options =>
    {
        options.UseSqlServer(builder.Configuration["ConnectionStrings:Company"], //the connection string loaded here is correct
            sqlServerOptionsAction: sqlOptions =>
            {
                sqlOptions.MigrationsAssembly(Assembly.GetExecutingAssembly().GetName().Name);
                sqlOptions.EnableRetryOnFailure(maxRetryCount: 15, maxRetryDelay: TimeSpan.FromSeconds(30), errorNumbersToAdd: null);
            });
    });

The appsettings.json looks like this:

"ConnectionStrings": {
    "Company": "Server=Address;Initial Catalog=Company;Persist Security Info=True;User ID=id;Password=password;Connect Timeout=120"
  }

I searched for any potential config files within the solution that could interfere with appsettings.json. I confirmed that I'm not using any User Secrets. I confirmed that the correct connection string was being loaded during the dependency injection.

I expected the ASP.NET Core Web API to create a connection with the production database using the production connection string that was loaded during the dependency injection, but it instead connected to the staging database.

I've never had this problem before, so it must have something to do with the dotnet new template being used. If the desired connection string is being read and loaded during dependency injection, why is it not being used? Is it possible for a former "cached" connection to override the current one?

jmagen
  • 41
  • 3
  • Within your program.cs file how are you using those connectinString? Using single variable to switch between the strings or using two seperate connection string variable? Please share your program.cs configuration details. In addition, include, this details `builder.Configuration["ConnectionString"]` – Md Farid Uddin Kiron Jul 13 '23 at 05:24
  • Check both appsettings.Dvelopment.json and appsettings.Production.json. Restarting the project may also solve the problem – AminFarajzadeh Jul 13 '23 at 10:52
  • @MdFaridUddinKiron I added the relevant section of my appsettings.json and updated the AddDBContext section of my program.cs to show exactly how I'm loading the connection string. I had left out the "Company" child key in my original post because, for the sake of example, I didn't think it was relevant. There is only a single connectionString variable being used; when I change the value of "ConnectionStrings:Company" from the staging connectionString to the production connectionString, Program.cs reads the production connectionString (as expected), but my requests still go to staging db. – jmagen Jul 13 '23 at 15:23
  • But according to your code snippet, I cannot see any relevant code where you are deciding which environment context or connection string need to select. – Md Farid Uddin Kiron Jul 14 '23 at 07:02
  • @MdFaridUddinKiron I've figured it out, and it was a dumb oversight on my part. My CompanyContext is a database-first context, and I didn't realize that the staging database connection string was hardcoded into the context... now that the context is actually using the connectionString from appsettings.json, it works as expected. Thanks for making me look deeper into this. – jmagen Jul 14 '23 at 16:38

0 Answers0