VB.NET App.config values resolving differently in production: machine.config inheritance or stale My.Settings defaults?

Question

In a .NET Framework Visual Basic project, App.config is copied to [AssemblyName].exe.config at build time, and runtime reads go through ConfigurationManager (appSettings, connectionStrings) or the My.Settings proxy generated by the Project Designer. A value that resolves one way on a developer machine can resolve differently on a production server, and several overlapping configuration layers could account for the gap.

machine.config inheritance: machine-level settings can conflict with application-level keys, with behavior that varies by .NET Framework version.
My.Settings defaults: strongly typed settings carry compiled-in default values, so a stale or missing deployed exe.config may not match local behavior.
CI/CD transformation gaps: config or settings files that are not transformed during the pipeline leave production reading developer values.
Runtime mixing: a project that also targets .NET (Core) replaces App.config with appsettings.json, and mixing the two systems can raise runtime exceptions.

The exact precedence between a duplicate appSettings key in machine.config and the application's exe.config should be verified against current framework documentation before relying on either value.

Which layer should be diagnosed first when a VB.NET appSetting resolves differently on the server? When machine.config and the deployed exe.config define the same key, which value does ConfigurationManager.AppSettings return under .NET Framework 4.8? And does My.Settings fall back to its compiled default when the deployed config file is absent or outdated?

Tasadduq Burney · Answer

Configuration Precedence in .NET Framework 4.8
When a VB.NET application resolves a setting differently in production, the primary layer to diagnose first is the physical presence and content of the [AssemblyName].exe.config file on the production server. Most discrepancies stem from CI/CD pipeline failures where the config file is either missing, not transformed, or incorrectly renamed during deployment.

ConfigurationManager.AppSettings Precedence
Under .NET Framework 4.8, ConfigurationManager.AppSettings follows a hierarchical override model. If the same key exists in both the machine.config and the application's exe.config, the exe.config value wins.

Machine Level: machine.config provides the base global defaults.
Application Level: exe.config overrides machine-level settings.

If you are seeing a value from machine.config in production, it typically indicates that the key is missing from the deployed exe.config entirely.

My.Settings and Compiled Defaults
The My.Settings proxy operates differently than a raw ConfigurationManager call. It utilizes a tiered fallback system:

User-scoped settings: Checks the user's local app data folder.
Application-scoped settings: Checks the exe.config file.
Compiled Defaults: If the exe.config is missing, outdated, or the specific key is absent, My.Settings falls back to the default value defined in the Project Designer at compile time.

This means a missing config file will not necessarily cause a crash; instead, the application will silently revert to the developer's design-time defaults.

Verification Steps
To isolate the source of the value, perform these checks on the production server:

File Check: Verify that [AssemblyName].exe.config exists in the application root.
Content Audit: Open the file in a text editor to ensure the key exists and the value was correctly transformed for production.
Runtime Log: If possible, log both ConfigurationManager.AppSettings("Key") and My.Settings.Key. If they differ, you are likely dealing with a scope mismatch (User vs. Application) or a stale compiled default.

Diagnostic Detail Needed: Are the settings in question marked as Application or User scope in the Project Designer? User-scoped settings are stored in a separate user.config file in the user's profile, which bypasses the exe.config entirely.

VB.NET App.config values resolving differently in production: machine.config inheritance or stale My.Settings defaults?

1 answer

Configuration Precedence in .NET Framework 4.8

ConfigurationManager.AppSettings Precedence

My.Settings and Compiled Defaults

Verification Steps

Your perspective belongs here.

0 question comments