Review this launchSettings.json. What does the file do, which tools use it, and what would you change?

1. What a launch profile actually is

A launch profile is a set of instructions that a tool reads before it starts your app. The app itself never opens launchSettings.json. The tool turns the profile into an ordinary process start: a command line, a working directory and a set of environment variables.

 Properties/launchSettings.json
         |
         v
 tool reads the selected profile
 (Visual Studio, Rider, VS Code C# Dev Kit, dotnet run, dotnet watch)
         |
         +-- applicationUrl        --> ASPNETCORE_URLS for the process
         +-- environmentVariables  --> process environment variables
         +-- commandLineArgs       --> args passed to Main
         +-- workingDirectory      --> current directory of the process
         +-- launchBrowser/launchUrl --> tool opens a browser (app unaware)
         |
         v
 your app starts and reads configuration as normal
 (it has no idea a launch profile existed)

That is why the file has no effect after dotnet publish: nothing in the deployed environment reads it.

2. Every common profile setting

3. Which tool reads it, and how

In .NET 10, file-based apps (dotnet run app.cs) can have launch profiles too, in a file named after the app such as app.run.json, next to the .cs file.

4. Where profile values sit in configuration

 launch profile  --sets-->  process environment variables
                                   |
 WebApplication.CreateBuilder(args) loads, later wins:
   1. appsettings.json
   2. appsettings.{Environment}.json
   3. user secrets              (only when Environment = Development)
   4. environment variables     <-- launch profile values land here
   5. command-line arguments    <-- commandLineArgs land here

Two consequences follow from this order:

• A connection string in a profile overrides the safe local one in user secrets and in appsettings.Development.json, silently.
• Setting ASPNETCORE_ENVIRONMENT=Production stops user secrets loading at all, and loads appsettings.Production.json instead. People then paste secrets into the profile to make it work, which is how the file in this question came to exist.

The double underscore in a variable name such as ConnectionStrings__OrdersDb maps to the : separator, so it becomes ConnectionStrings:OrdersDb.

5. What the environment name switches

So the environment name changes real behaviour, but it isn't what reaches production data. The connection string is. Fixing only the environment name leaves the live database one F5 away.

6. User secrets internals

• dotnet user-secrets init adds a <UserSecretsId> GUID to the project file.
• Values are stored as plain JSON outside the repo: %APPDATA%\Microsoft\UserSecrets\<id>\secrets.json on Windows, ~/.microsoft/usersecrets/<id>/secrets.json on macOS and Linux.
• They are not encrypted. They only keep values out of source control, so they are for development values only.
• dotnet user-secrets list shows what is set; dotnet user-secrets clear removes everything for the project.

7. Responding to the committed secret

Order matters. Rotating first limits the damage; cleaning history first only hides the evidence.

1. Rotate the SQL credential and the payment gateway key now. Assume both are compromised.
2. Audit database and gateway logs for use of the old credentials since the commit date.
3. Assess whether personal information could have been accessed. If so, follow the incident process, including the Notifiable Data Breaches scheme under the Privacy Act 1988.
4. Remove the values from history with git filter-repo or BFG, force-push, and ask everyone to re-clone. Forks and existing clones still hold the old values, which is why step 1 comes first.
5. Prevent a repeat: secret scanning with push protection, managed identity, and no network path from developer machines to production data.

8. A good team pattern

 repo (committed)                       developer machine (not committed)
 -----------------                      ---------------------------------
 launchSettings.json                    user secrets: local connection string,
   https / http profiles                              sandbox API keys
   ASPNETCORE_ENVIRONMENT=Development
   localhost URLs only                  local SQL Server container
 appsettings.json (no secrets)
 appsettings.Development.json
   (non-secret local defaults)

 Azure (deployed)
 ----------------
 App Service settings + Key Vault references, managed identity

If someone needs production-like behaviour locally, add a clearly named profile such as staging-like with ASPNETCORE_ENVIRONMENT=Staging that points at non-production resources.

9. Diagnosing "it uses the wrong settings"

1. Check which profile ran. In the IDE look at the run dropdown; on the command line, dotnet run uses the first Project profile.
2. Log app.Environment.EnvironmentName and the bound URLs at start-up.
3. Log which configuration provider supplied a key without logging its value. In development, ((IConfigurationRoot)builder.Configuration).GetDebugView() shows each key and its source; never call it in production because it prints values.
4. Look for machine-level environment variables with the same name, which override appsettings the same way the profile does.
5. Run with --no-launch-profile to rule the file out.

10. Performance and security notes

• Launch profiles have no runtime performance cost; they only affect how the process starts.
• 0.0.0.0 or * exposes the app to every network the laptop joins. Combined with HTTP and the Development exception page, it can leak stack traces and data on shared Wi-Fi.
• Keep launchSettings.json in code review and run a secret scanner on every pull request.

11. .NET 11 awareness

Launch profiles are stable and nothing in the .NET 11 previews changes the advice here. Check the release notes for dotnet run changes when .NET 11 ships.

12. Try it yourself

1. Run dotnet new webapi -n Orders.Api and open Properties/launchSettings.json.
2. Run dotnet run, then dotnet run --launch-profile https, and compare the URLs printed.
3. Run dotnet user-secrets init, set ConnectionStrings:OrdersDb, and log whether it is present (not its value).
4. Add the same key to the profile's environmentVariables and confirm the profile value wins.
5. Change the profile to Production and confirm the user secret disappears.
6. Run dotnet run --no-launch-profile and note that the app now uses default URLs and the Production environment.

The file under review (do not copy):

{
  "profiles": {
    "Orders.Api": {
      "commandName": "Project",
      "launchBrowser": true,
      "applicationUrl": "http://0.0.0.0:5000",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Production",
        "ConnectionStrings__OrdersDb": "Server=orders-prod.database.windows.net;Database=Orders;User Id=orders_app;Password=Winter2026!;",
        "PaymentGateway__ApiKey": "live_4f9a2c..."
      }
    }
  }
}

The corrected Properties/launchSettings.json:

{
  "$schema": "https://json.schemastore.org/launchsettings.json",
  "profiles": {
    "https": {
      "commandName": "Project",
      "launchBrowser": false,
      "applicationUrl": "https://localhost:7181;http://localhost:5181",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "http": {
      "commandName": "Project",
      "launchBrowser": false,
      "applicationUrl": "http://localhost:5181",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    }
  }
}

Local secrets instead (values stay in your user profile, outside the repo):

dotnet user-secrets init --project src/Orders.Api
dotnet user-secrets set "ConnectionStrings:OrdersDb" "Server=localhost,1433;Database=Orders;User Id=sa;Password=$LOCAL_SQL_PASSWORD;TrustServerCertificate=True" --project src/Orders.Api
dotnet run --project src/Orders.Api --launch-profile https

Reading it safely in Program.cs:

var builder = WebApplication.CreateBuilder(args);

var connectionString = builder.Configuration.GetConnectionString("OrdersDb")
    ?? throw new InvalidOperationException("Connection string 'OrdersDb' is not configured.");

var app = builder.Build();
app.MapGet("/health", () => Results.Ok(new { status = "ok" }));
app.Run();