[vs17.14] Remove the ConfigurationManager binding redirect

[AlesProkop]

Fixes #14404

Context

MSBuild.exe.config redirects System.Configuration.ConfigurationManager to 10.0.0.8, and the amd64/arm64 config adds a codeBase pointing at MSBuild\Current\Bin\System.Configuration.ConfigurationManager.dll. That assembly is not in Microsoft.Build.vsix, so an in-proc task that carries its own ConfigurationManager has its bind hijacked to a file that does not exist and fails with FileNotFoundException. Regression from #14127 (17.14.40 -> 17.14.51).

The redirect is not needed by MSBuild. On .NET Framework the System.Configuration.ConfigurationManager reference assembly only type-forwards into the GAC's System.Configuration, so the shipped binaries reference System.Configuration, Version=4.0.0.0 and never bind to the package assembly:

Microsoft.Build.dll                          -> System.Configuration 4.0.0.0
Microsoft.Build.Framework.dll                -> (none)
Microsoft.Build.Utilities.Core.dll           -> (none)
Microsoft.Build.Tasks.Core.dll               -> (none)
MSBuild.exe                                  -> (none)
System.Configuration.ConfigurationManager.dll -> System.Configuration 4.0.0.0

This is the alternative to #14496, which instead added the missing assembly to the VSIX payload.

Changes Made

• Remove the System.Configuration.ConfigurationManager dependentAssembly entry from src/MSBuild/app.config and src/MSBuild/app.amd64.config (redirect + codeBase), leaving a comment explaining why there is none.
• Bump the servicing version to 17.14.54.

Task-local System.Configuration.ConfigurationManager binds now resolve the way they did before 17.14.51.

Testing

• ./build.cmd -v quiet /p:RunAnalyzers=false — ValidateMSBuildPackageDependencyVersions passes for x86, x64 and arm64. The only failure is the pre-existing local-only arcade OptProf GenerateTrainingInputFiles error, which reproduces unchanged on the unmodified base commit.
• Verified the generated MSBuild.exe.config for all three platforms no longer contains a ConfigurationManager dependentAssembly and that the generated NuGetFrameworkWrapper.redirects.cs (which mirrors these redirects into the task AppDomain config) no longer contains one either.

[Copilot]

Pull request overview

This PR removes the System.Configuration.ConfigurationManager binding redirect (and associated codeBase) from MSBuild’s .NET Framework app configs to prevent host-level binding policy from hijacking task-local ConfigurationManager loads—addressing a VSIX packaging regression reported in #14404. It also bumps the servicing version for the vs17.14 branch.

Changes:

• Remove the System.Configuration.ConfigurationManager dependentAssembly binding redirect from src/MSBuild/app.config.
• Remove the same redirect + codeBase from src/MSBuild/app.amd64.config, replacing it with an explanatory comment referencing #14404.
• Bump VersionPrefix to 17.14.54.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated no comments.

File	Description
src/MSBuild/app.config	Removes ConfigurationManager binding redirect; adds a comment explaining why MSBuild shouldn’t redirect it on .NET Framework.
src/MSBuild/app.amd64.config	Removes ConfigurationManager binding redirect and codeBase that could point to a missing VSIX payload file; adds rationale comment.
eng/Versions.props	Increments the servicing VersionPrefix to 17.14.54.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[github-actions]

Expert Code Review — PR #14560

✅ 24/24 dimensions clean — no findings.

This is a targeted servicing fix that removes a broken binding redirect for System.Configuration.ConfigurationManager from the .NET Framework MSBuild config files.

Analysis

Technical correctness: The explanation in the PR description is accurate. On .NET Framework, the NuGet package System.Configuration.ConfigurationManager (publicKeyToken cc7b13ffcd2ddd51) is a type-forwarding shim that delegates to the GAC's System.Configuration 4.0.0.0. MSBuild assemblies compiled against this reference end up binding to System.Configuration 4.0.0.0 at runtime, never to the NuGet package assembly. The redirect to version 10.0.0.8 with a codeBase pointing to a file not present in Microsoft.Build.vsix was actively harmful: any in-proc task carrying its own copy of System.Configuration.ConfigurationManager had its binding hijacked to a non-existent path, causing a load failure.

Backwards compatibility: Removing the redirect restores the pre-17.14.51 behavior. This is a regression fix, not a new behavioral change, so no ChangeWave gate is required.

VS Servicing model: The version bump 17.14.53 → 17.14.54 in eng/Versions.props is appropriate for a patch-level servicing release on the vs17.14 branch.

Asymmetry between configs: app.config (x86) had the redirect without a codeBase element, while app.amd64.config had it with a codeBase. Both are removed correctly — the codeBase is strictly more harmful (explicit missing-file reference), but the redirect itself was also unnecessary and was silently shadowing any task-local version.

Test coverage: No regression test is included. Binding redirect behavior in .NET Framework requires a full runtime host to exercise and is not easily unit-testable. For a servicing fix of this scope this is acceptable, though an integration test or manual repro in the linked issue (#14404) would be valuable documentation of the scenario.

Security, concurrency, performance, API surface: All N/A for this change — it is purely a config file edit.

Warning

Firewall blocked 1 domain

The following domain was blocked by the firewall during workflow execution:

• awmgmcpg

To allow these domains, add them to the network.allowed list in your workflow frontmatter:

network:
  allowed:
    - defaults
    - "awmgmcpg"

See Network Configuration for more information.

Generated by Expert Code Review (on open) for #14560 · sonnet46 · 51.9 AIC · ⌖ 5.17 AIC · ⊞ 4.9K

[ViktorHofer]

Looking...