Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

MTP.MSBuild 2.5 regression: `dotnet build -t:Test` with `--report-trx` (or `--hangdump`/`--crashdump`) fails with "MSBuild extension failed to receive test application information"

Open
  • Is something wrong?
#12,032 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
48/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
csharp
Domain
build-system, testing

Research direction

Start by reading TestingPlatformBuilderHook.cs and TestHostControllersTestHost.ProcessConfiguration.cs, then trace the MSBuild callbacks that request module information. Reproduce with the provided three-file project and dotnet build -t:Test -p:TestingPlatformCommandLineArguments=--report-trx; compare behavior with and without the controller-backed option. Done when controller-backed runs through the MSBuild target receive test application information and produce the expected results.

Written by the indexing model from the issue text.

Description

needs/triage

Describe the bug

Starting with Microsoft.Testing.Platform.MSBuild 2.5.0 (MSTest.Sdk 4.5.0), running tests through the MSBuild integration fails when the test app runs under a test host controller. This covers dotnet build -t:Test and the InvokeTestingPlatform target. TRX reporting always uses a controller, so --report-trx triggers the failure. --hangdump and --crashdump fail the same way. The build reports:

error : MSBuild extension failed to receive test application information from '<path>/Repro.dll'

The same project passes on MSTest.Sdk 4.4.1 (MTP.MSBuild 2.4.1). On 4.5.1 it also passes when no controller-backed option is used. Running the app directly, or using dotnet test in Microsoft.Testing.Platform mode with --report-trx, works on 4.5.1. Only the MSBuild -t:Test / InvokeTestingPlatform path is affected.

Version used

  • MSTest.Sdk 4.5.1, which brings Microsoft.Testing.Platform / Microsoft.Testing.Platform.MSBuild 2.5.1
  • Last known good: MSTest.Sdk 4.4.1 (MTP.MSBuild 2.4.1)
  • First bad: MTP.MSBuild 2.5.0. I confirmed it with MSTest.Sdk 4.4.1 plus an explicit PackageReference to Microsoft.Testing.Platform.MSBuild 2.5.0. MSTest.Sdk 4.4.1 with Microsoft.Testing.Platform 2.5.0 but MTP.MSBuild 2.4.1 passes.
  • .NET SDK 10.0.402 (runtime 10.0.13), Linux x64 (Azure Linux 3.0)

Steps To Reproduce

Create the three files below in an empty directory that has no Directory.Build.* files above it.

global.json:

{
  "sdk": {
    "version": "10.0.402",
    "rollForward": "latestFeature"
  },
  "msbuild-sdks": {
    "MSTest.Sdk": "4.5.1"
  }
}

Repro.csproj:

<Project Sdk="MSTest.Sdk">

  <PropertyGroup>
    <TargetFramework>net10.0</TargetFramework>
  </PropertyGroup>

</Project>

Test1.cs:

using Microsoft.VisualStudio.TestTools.UnitTesting;

namespace Repro;

[TestClass]
public sealed class Test1
{
    [TestMethod]
    public void Passes()
    {
    }
}

Then run:

dotnet build -t:Test -p:TestingPlatformCommandLineArguments=--report-trx

Results:

MSTest.Sdk Arguments Result
4.5.1 --report-trx fails
4.5.1 (none) passes
4.4.1 --report-trx passes
4.5.1 --hangdump with -p:EnableMicrosoftTestingExtensionsHangDump=true fails
4.5.1 --crashdump with -p:EnableMicrosoftTestingExtensionsCrashDump=true fails
4.4.1 --hangdump / --crashdump (same properties) passes

Expected behavior

The tests run and a TRX file is produced, as on 4.4.1:

  Run tests: '<repro>/bin/Debug/net10.0/Repro.dll' [net10.0|x64]
  Passed! - Failed: 0, Passed: 1, Skipped: 0, Total: 1, Duration: 155ms - Repro.dll (net10.0|x64)
  Tests succeeded: '<repro>/bin/Debug/net10.0/Repro.dll' [net10.0|x64]

Build succeeded.

Actual behavior

  Repro -> <repro>/bin/Debug/net10.0/Repro.dll
  Run tests: '<repro>/bin/Debug/net10.0/Repro.dll' [net10.0|x64]
~/.nuget/packages/microsoft.testing.platform.msbuild/2.5.1/buildMultiTargeting/Microsoft.Testing.Platform.MSBuild.targets(500,5): error : MSBuild extension failed to receive test application information from '<repro>/bin/Debug/net10.0/Repro.dll' [<repro>/Repro.csproj]

Build FAILED.
    0 Warning(s)
    1 Error(s)

Additional context

My analysis, based on reading the v4.5.1 sources:

  • The regression was introduced by #11484, which added TestingPlatformBuilderHook.
    • When the arguments contain --internal-testhostcontroller-pid, the hook does not call AddMSBuild().
    • Instead it registers only the MSBuild command-line provider.
    • The apparent intent is that the controller process reports to MSBuild in a packaged/AppContainer scenario.
  • TestHostControllersTestHost adds --internal-testhostcontroller-pid to every child test host it starts, not only packaged ones.
  • TRX always runs through a test host controller (#10808), and so do HangDump and CrashDump.
  • The resulting sequence:
    1. The MSBuild task starts Repro.dll --internal-msbuild-node <pipe> --report-trx.
    2. The controller starts the child host.
    3. The child skips the MSBuild lifetime callbacks, so it never sends ModuleInfoRequest.
    4. Nothing relays this information for the non-packaged controller case.
    5. InvokeTestingPlatformTask ends with no module info and logs DidNotReceiveModuleInfo.
  • To confirm the cause, I used a custom entry point (GenerateTestingPlatformEntryPoint=false, GenerateSelfRegisteredExtensions=false).
    • Main registers MSTest and the TRX provider and calls builder.AddMSBuild() unconditionally.
    • With MSTest.Sdk 4.5.1 and --report-trx, dotnet build -t:Test then passes and writes the TRX file.
  • The same skip logic is still present on main and rel/4.5 as of today.

A possible fix: only skip AddMSBuild() in the child when the controller actually relays the MSBuild information, for example only for the packaged/AppContainer path.

Dominant language
C#
Stars
1.1k
Forks
312
Avg merge
8h 29m
Merged PRs (30d)
421

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from microsoft/testfx

All issues in microsoft/testfx

Similar issues

More C# issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.