Why should you care?

Developers hit LocalDB on laptops while staging uses Azure SQL — same ShopNest code, different connection string per environment.

See it live — copy this example

Paste into a .NET project with EF Core packages, then run with LocalDB/SQL Server (dotnet ef / dotnet run).

// appsettings.Development.json
{
  "ConnectionStrings": {
    "ShopNest": "Server=(localdb)\mssqllocaldb;Database=ShopNest;Trusted_Connection=True;TrustServerCertificate=True"
  }
}

builder.Services.AddDbContext<ShopNestDbContext>(o =>
    o.UseSqlServer(builder.Configuration.GetConnectionString("ShopNest")));

What happened?

• GetConnectionString reads the named entry.
• UseSqlServer hands it to the provider.
• TrustServerCertificate=True is common for local dev certificates.

Practice next

1. Add appsettings.Development.json with the ShopNest connection string.
2. Verify LocalDB with sqllocaldb info in a terminal.
3. Never commit production passwords — use User Secrets or Azure Key Vault.
4. Add MultipleActiveResultSets=True and note when MARS helps Include queries.
5. Switch Database=ShopNest_Dev and run dotnet ef database update against the new DB.

Remember

Connection strings belong in configuration, not code. Name entries consistently (ShopNest, DefaultConnection). Match server name to your LocalDB or SQL Express instance.

ShopNest environment swap

Same ShopNest.Api deploys to staging with Azure SQL connection string from environment variables.

Outcome: No code change when promoting builds — only configuration changes.