Skip to content

Remove stale Microsoft.Extensions.FileSystemGlobbing binding redirect from testhost.x86 and datacollector - #16082

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

Remove stale Microsoft.Extensions.FileSystemGlobbing binding redirect from testhost.x86 and datacollector#16082
Amaury Levé (Evangelink) merged 1 commit into
microsoft:mainfrom
Evangelink:dev/amauryleve/remove-stale-filesystemglobbing-redirect

Conversation

@Evangelink

Copy link
Copy Markdown
Member

What

Remove the stale Microsoft.Extensions.FileSystemGlobbing <bindingRedirect> from src/testhost.x86/app.config and src/datacollector/app.config. The redirect is kept in src/vstest.console/app.config (the only EXE that legitimately ships and uses the assembly, via FilePatternParser).

Why

Neither testhost.x86.exe nor datacollector.exe references Microsoft.Extensions.FileSystemGlobbing, and the DLL doesn't ship beside them in the Microsoft.TestPlatform.CLI nupkg's contentFiles/any/net10.0/TestHostNetFramework/ folder. A binding redirect pointing to a DLL that isn't on the probing path is the same anti-pattern fixed for System.Diagnostics.DiagnosticSource in #15776 (root cause of #15765MissingMethodException on net462 with DisableAppDomain=true).

How it was discovered

This is the latent issue the hardened verifier from #15778 catches. The failure currently surfaces only on the rel/18.6 VMR build:

  1. Microsoft.TestPlatform.csproj gates IsPackable on '$(DotNetBuild)' != 'true' (the package "relies on a VS license"), so in VMR mode it isn't produced. That nupkg is the one that ships testhost.x86.exe/datacollector.exe in tools/net462/Common7/IDE/Extensions/TestPlatform/ with Microsoft.Extensions.FileSystemGlobbing.dll right next to them — which is what masks the stale redirect in vstest's normal pipeline (Find-ExeInPackages prefers non-TestHostNetFramework layouts).
  2. Once that layout disappears, the verifier only finds the EXEs inside Microsoft.TestPlatform.CLI's TestHostNetFramework/ folder, where the DLL isn't shipped → error.
  3. The DotNetBuild != 'true' skip on _VerifyNuGetPackages (commit 37087fc) is on main and rel/18.8 but not backported to rel/18.6 or rel/18.7, so the verifier still runs in the VMR pack on those branches.

This PR fixes the underlying issue. It should be cherry-picked to rel/18.6 (where it actively unblocks the VMR build) and rel/18.7 for consistency.

testhost.x86 and datacollector neither reference Microsoft.Extensions.FileSystemGlobbing nor ship the DLL beside their EXE in the Microsoft.TestPlatform.CLI nupkg (TestHostNetFramework folder). The stale redirect is the same anti-pattern fixed for DiagnosticSource in microsoft#15776: a redirect to an assembly that isn't shipped can cause MissingMethodException on net462 with DisableAppDomain=true.

Only vstest.console references the assembly (via FilePatternParser), so the redirect is kept in src/vstest.console/app.config where the DLL ships next to vstest.console.dll.

This is also the latent issue surfaced by the hardened verifier added in microsoft#15778 - currently visible on the rel/18.6 VMR build because (1) Microsoft.TestPlatform.nupkg (which ships the EXEs together with FileSystemGlobbing.dll under tools/net462/Common7/IDE/Extensions/TestPlatform/) is gated off when DotNetBuild=true, leaving the verifier to look only inside Microsoft.TestPlatform.CLI's TestHostNetFramework folder; and (2) the DotNetBuild != 'true' skip on _VerifyNuGetPackages was not backported to rel/18.6.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Copilot AI review requested due to automatic review settings June 2, 2026 09:43

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Removes a stale Microsoft.Extensions.FileSystemGlobbing binding redirect from the .NET Framework testhost.x86 and datacollector app.configs, aligning binding redirects with the assemblies these executables actually ship alongside and preventing validation failures when the target DLL is absent.

Changes:

  • Removed Microsoft.Extensions.FileSystemGlobbing <dependentAssembly> binding redirects from src/testhost.x86/app.config and src/datacollector/app.config.
  • Kept vstest.console behavior unchanged (no redirect removal there in this PR).
Show a summary per file
File Description
src/testhost.x86/app.config Drops the stale Microsoft.Extensions.FileSystemGlobbing bindingRedirect from testhost.x86 configuration.
src/datacollector/app.config Drops the stale Microsoft.Extensions.FileSystemGlobbing bindingRedirect from datacollector configuration.

Copilot's findings

  • Files reviewed: 2/2 changed files
  • Comments generated: 0

@Evangelink
Amaury Levé (Evangelink) enabled auto-merge (squash) June 2, 2026 09:45
Amaury Levé (Evangelink) added a commit that referenced this pull request Jun 2, 2026
…ng redirect (#16084)

Cherry-pick of the main fix (PR #16082) for consistency with rel/18.6.

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 (#15776).

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Amaury Levé (Evangelink) added a commit that referenced this pull request Jun 2, 2026
…ng redirect (#16083)

Cherry-pick of the main fix (PR #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 (#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 #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 353e2eb into microsoft:main Jun 2, 2026
14 checks passed
@Evangelink
Amaury Levé (Evangelink) deleted the dev/amauryleve/remove-stale-filesystemglobbing-redirect branch June 3, 2026 14:18
This was referenced Aug 15, 2026
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.

3 participants