ASP.NET+C#：本地调试与Azure部署的连接字符串配置问题

Let’s tackle your two questions one by one with practical, straightforward solutions tailored to your setup:

1. Coordinating Connection String Retrieval Without Duplicating Variables #

Great news—you don’t need to rewrite your core code! Azure App Service’s Connection Strings configuration section is built to automatically override values in your web.config’s <connectionStrings> collection. That means your existing line:

string dbConn = WebConfigurationManager.ConnectionStrings["myConnStringName"].ConnectionString;

will work perfectly both locally and on Azure, no changes required.

If you want to add a safety fallback (for edge cases where someone might accidentally store the string in App Settings instead), you can use a null-coalescing operator to keep everything in one variable declaration:

string dbConn = WebConfigurationManager.ConnectionStrings["myConnStringName"]?.ConnectionString 
                ?? ConfigurationManager.AppSettings["myConnStringName"];

This tries your preferred connection strings collection first, then falls back to App Settings only if that fails—all without duplicating variables.

2. Using Local Secrets File Without Committing It + Azure Override #

Here’s how to keep your MySecrets.config local while letting Azure handle production credentials securely:

Step 1: Exclude the secrets file from source control #

If you’re using Git, add this line to your .gitignore file:

MySecrets.config

This ensures the file never gets pushed to your repo. For other version control systems (like TFS), use their equivalent ignore mechanism (e.g., .tfignore).

Step 2: Keep your local web.config setup #

Leave this line in your local web.config—it will load your local secrets during debugging:

<connectionStrings configSource="MySecrets.config" />

Step 3: Configure Azure to override the connection string #

• Go to your Azure App Service in the portal
• Navigate to Configuration > Connection Strings
• Add a new connection string with the exact same name (myConnStringName) as in your web.config
• Paste your production connection string value, select the appropriate type (e.g., SQL Server), and save

Azure will automatically prioritize its own connection string value over what’s in your deployed web.config—even if the deployed config still references MySecrets.config. If you want to clean up the deployed config, use Web.config Transformation:

Create a Web.Release.config file (if you don’t have one) and add this transform to remove the configSource attribute when publishing:

<connectionStrings configSource="" xdt:Transform="SetAttributes(configSource)" xdt:Locator="Match(name)" />

This ensures the deployed web.config doesn’t reference a file that doesn’t exist in Azure.

That’s it! Local debugging uses your MySecrets.config, production uses Azure’s secure configuration, and your secrets stay out of source control entirely.

内容的提问来源于stack exchange，提问作者Zizzipupp