Report test extension load failures to the user

[Jakub Jareš (nohwnd)]

TestPluginDiscoverer only told the user about a failing extension file when Assembly.Load threw FileLoadException. Two other paths were silent and wrote to EqtTrace only:

• the general Exception handler in GetTestExtensionsFromFiles, which is the one that catches the FileNotFoundException thrown when an extension or one of its dependencies cannot be found;
• the ReflectionTypeLoadException handler in GetTestExtensionsFromAssembly, which carries on with a half-loaded type list.

So an adapter that half-loaded gave the user fewer tests than expected, or a hang, with no way to find out why short of re-running with /diag. Both now report through TestSessionMessageLogger using the existing, already localised FailedToLoadAdapaterFile message, so no .resx or .xlf change is needed.

Scanning stays best effort. Nothing throws and nothing aborts, a partially loaded assembly is still scanned for every extension type, each file is reported once per run, and the two C++ UWP adapters that are probed speculatively when no extension was found are not reported because they are absent everywhere except UWP.

With an adapter whose dependency was deleted, the user now sees:

Failed to load extensions from file 'C:\Temp\missingdep\Fabrikam.TestAdapter.dll'. Please use /diag for more information.

and the run still discovers every test.

This is the diagnostic half of #15577. The packaging cause behind the report on that issue, the missing net462 companion assemblies, was fixed separately in #15739 and shipped in 18.9.0, so this does not close #15577 on its own.

Verified: build.cmd -c Release compiles clean, Microsoft.TestPlatform.Common.UnitTests passes on net481 and net11.0 (401 tests), and a locally built vstest.console reproduces both failure modes end to end.

Related to #15577

🤖

[Copilot]

Pull request overview

Improves user-facing diagnostics when test extension (adapter/logger/etc.) discovery fails, ensuring failures that previously only surfaced in /diag logs are reported as warnings while keeping extension scanning best-effort.

Changes:

• Report extension load failures via TestSessionMessageLogger for general load failures and ReflectionTypeLoadException partial-type-load scenarios.
• Deduplicate user-visible warnings so the same failing extension file is not repeatedly reported across scans.
• Add/extend unit tests to validate warning emission, deduplication, and continued scanning behavior on partial type-load failures.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/Microsoft.TestPlatform.Common/ExtensionFramework/TestPluginDiscoverer.cs	Adds user-visible warning reporting for additional extension load failure paths and introduces per-file warning deduplication.
test/Microsoft.TestPlatform.Common.UnitTests/ExtensionFramework/TestPluginDiscovererTests.cs	Adds tests that capture TestSessionMessageLogger warnings for missing/partially-loaded extensions and verifies dedupe behavior.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[Copilot]

Pull request overview

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

[Jakub Jareš (nohwnd)]

This does the same thing as #16390 and both are green and mergeable, so whichever goes in first makes the other conflict. I read both diffs and moved the one piece that only exists here over to #16390, so this one can be closed without losing anything.

Where #16390 is better:

• It splits the assembly load from the assembly inspection in GetTestExtensionsFromFiles. On main one catch covers both, so a broken TestPluginInformation constructor looks the same as a file that could not be loaded. This PR leaves that alone.
• It replaces FailedToLoadAdapaterFile with FailedToLoadExtensionFile, which carries the reason, so the user sees which dependency is missing instead of being pointed at /diag. The resx, all 13 xlf files and the deliberate pre-touch in TestPluginCache.SetupAssemblyResolver are updated with it.
• It reports a ReflectionTypeLoadException only when no type loaded at all. This PR reports it even when some types loaded, and that would warn on ordinary green runs. Vstest.console logging LoaderExceptions in success scenario as well #290 is exactly that: the MSTest adapter throws ReflectionTypeLoadException during a completely successful run because it references an older ObjectModel.

Where this PR was right and #16390 was not:

The warning in #16390 was deduplicated on UnloadableFiles, which is static and never cleared. ClearExtensions() clears the extension paths and invalidates the cache but does not touch it, so TryAdd returned true once per process. In design mode, where an editor keeps the runner alive across many discovery and run requests, the user heard about a broken extension on the first request and then never again. This PR solved that on purpose with a separate ReportedFiles that ClearExtensions() resets.

I settled that with a test rather than by reading the code. Same test source, run on both branches, Release, net11.0 and net481: scan a file that cannot be loaded, assert the warning, call TestPluginCache.Instance.ClearExtensions(), scan again, count the warnings.

• On nohwnd-warn-when-test-extension-fails-to-load: 1 warning after the first scan, still 1 after the clear. Once per process.
• On pilot/tell-the-user-when-a-test-extension-fails: 2 warnings. Once per run.

So the reset here was fixing something real, and it is now in #16390. It keeps that PR's structure and separates the two concerns instead of coupling them: UnloadableFiles answers whether loading the file is worth another try, ReportedFiles answers whether the user has already seen the warning, and ClearExtensions() empties both. Clearing the first one fixes a second thing along the way, an extension whose missing dependency has since appeared is tried again on the next request instead of staying skipped until the process exits.

Tests carried over from here into #16390:

• Warn again after the extension cache is cleared. It fails without the reset, 1 warning instead of 2.
• Warn only once when the casing of the path differs.
• The PartiallyLoadedAssembly fake, now used for two tests: no warning when only some types fail to load, which is the Vstest.console logging LoaderExceptions in success scenario as well #290 guard, and a warning naming the missing dependency when no type loads at all.

Dropped: the two tests here that assert a warning on a partial type load. Under #16390 that case is deliberately quiet, so the assertion is inverted rather than ported.

Microsoft.TestPlatform.Common.UnitTests passes on both target frameworks with all of that in place. Nothing else in this PR is missing from #16390, so I think this one can be closed.

🤖