Skip to content

[rel/18.6] Remove stale Microsoft.Extensions.FileSystemGlobbing binding redirect - #16083

Merged
Amaury Levé (Evangelink) merged 1 commit into
microsoft:rel/18.6from
Evangelink:dev/amauryleve/remove-stale-filesystemglobbing-redirect-rel-18.6
Jun 2, 2026
Merged

[rel/18.6] Remove stale Microsoft.Extensions.FileSystemGlobbing binding redirect#16083
Amaury Levé (Evangelink) merged 1 commit into
microsoft:rel/18.6from
Evangelink:dev/amauryleve/remove-stale-filesystemglobbing-redirect-rel-18.6

Conversation

@Evangelink

Copy link
Copy Markdown
Member

Backport of #16082 to rel/18.6.

What

Remove the stale Microsoft.Extensions.FileSystemGlobbing <bindingRedirect> from src/testhost.x86/app.config and src/datacollector/app.config (kept in src/vstest.console/app.config — the only EXE that legitimately uses FilePatternParser and ships the DLL beside itself).

Why this matters specifically for rel/18.6

The rel/18.6 VMR build is failing on this check (see dnceng-public build 1435728):

testhost.x86.exe: Microsoft.Extensions.FileSystemGlobbing has a binding redirect but the DLL is not in the package layout
datacollector.exe: Microsoft.Extensions.FileSystemGlobbing has a binding redirect but the DLL is not in the package layout

In vstest's own pipeline this is masked because the verifier (Find-ExeInPackages in eng/verify-binding-redirects.ps1) prefers a non-TestHostNetFramework location and picks the EXEs from Microsoft.TestPlatform.nupkg's tools/net462/Common7/IDE/Extensions/TestPlatform/ folder, where Microsoft.Extensions.FileSystemGlobbing.dll is sitting next to them. In the VMR, Microsoft.TestPlatform.csproj gates IsPackable on '$(DotNetBuild)' != 'true' ("relies on a VS license"), so only Microsoft.TestPlatform.CLI is produced — and the EXEs end up in its contentFiles/any/net10.0/TestHostNetFramework/ folder where the DLL doesn't ship.

On main/rel/18.8 _VerifyNuGetPackages itself is skipped under DotNetBuild=true, so the latent stale redirect doesn't surface there. That skip was not backported to rel/18.6, so the hardened verifier (from #15778) running in the VMR pack catches the issue here.

The cleanest fix is to remove the stale redirect (same anti-pattern as the DiagnosticSource fix in #15776 / #15765).

…ng redirect

Cherry-pick of the main fix (PR microsoft#16082) to unblock the rel/18.6 VMR build.

testhost.x86 and datacollector neither reference Microsoft.Extensions.FileSystemGlobbing nor ship the DLL beside their EXE in the Microsoft.TestPlatform.CLI nupkg (TestHostNetFramework folder). Same anti-pattern as the DiagnosticSource fix (microsoft#15776).

On main and rel/18.8 the _VerifyNuGetPackages target is skipped under DotNetBuild=true, so the latent issue is masked in the VMR. On rel/18.6 that skip is not present, so the hardened verifier (from microsoft#15778) running in the VMR pack catches the stale redirect and fails the build.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
@Evangelink
Amaury Levé (Evangelink) merged commit ce53df7 into microsoft:rel/18.6 Jun 2, 2026
7 checks passed
@Evangelink
Amaury Levé (Evangelink) deleted the dev/amauryleve/remove-stale-filesystemglobbing-redirect-rel-18.6 branch June 3, 2026 14:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants