[vs17.14] Include ConfigurationManager in Microsoft.Build.vsix - #14496
[vs17.14] Include ConfigurationManager in Microsoft.Build.vsix#14496AlesProkop wants to merge 1 commit into
Conversation
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 91fec5dd-9331-4376-8ba1-b9bb5d4fc34b
There was a problem hiding this comment.
Pull request overview
This PR fixes a Visual Studio servicing regression where MSBuild’s Full Framework binding redirect for System.Configuration.ConfigurationManager points to MSBuild\Current\Bin\System.Configuration.ConfigurationManager.dll, but the Microsoft.Build.vsix payload did not include that assembly—causing in-proc tasks with ConfigurationManager dependencies to fail to load under the redirected policy.
Changes:
- Add
System.Configuration.ConfigurationManager.dllto theMicrosoft.Build.vsixpayload underMSBuild\Current\Bin. - Bump the servicing version from
17.14.52to17.14.53.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.
| File | Description |
|---|---|
| src/Package/MSBuild.VSSetup/files.swr | Adds System.Configuration.ConfigurationManager.dll to the VSIX file manifest for MSBuild\Current\Bin. |
| eng/Versions.props | Increments VersionPrefix to 17.14.53 for the servicing build. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
Code Review: [vs17.14] Include ConfigurationManager in Microsoft.Build.vsix
Clean servicing PR. No issues found.
- Version bump (17.14.52 to 17.14.53): Routine servicing increment.
- New System.Configuration.ConfigurationManager.dll entry: Correctly added to the VSIX.
- No NGEN attributes: Consistent with non-hot-path assemblies like Microsoft.Bcl.HashCode.dll, System.Threading.Channels.dll, System.ValueTuple.dll.
- No behavioral changes, so no ChangeWave, tests, or breaking-change concerns.
LGTM - no blocking or major issues.
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.allowedlist in your workflow frontmatter:
network:
allowed:
- defaults
- "awmgmcpg"See Network Configuration for more information.
Generated by Expert Code Review (on open) for #14496 · 45.8 AIC · ⌖ 4.99 AIC · ⊞ 5K
|
Closing as we will try to revert the addition of the .dll first. |
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. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 98ea148f-b805-4636-8f5a-48016ad923d5
Fixes #14404
Context
The MSBuild configuration redirects
System.Configuration.ConfigurationManagerto version 10.0.0.8, but the explicitMicrosoft.Build.vsixpayload omitted the assembly.Changes Made
System.Configuration.ConfigurationManager.dllinMSBuild\Current\Bin.Testing
./build.cmd -v quiet /p:RunAnalyzers=falsesrc/Package/MSBuild.VSSetup/MSBuild.VSSetup.csprojwith full-framework MSBuild.