Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

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"

Chiusa
#12,032 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Una pull request collegata è già stata integrata.

  • #12049 di @Evangelink — integrata

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
48/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
csharp

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C#
Stelle
1.1k
Fork
312
Merge medio
9h 17m
PR unite (30g)
391

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di microsoft/testfx

Tutte le issue di microsoft/testfx

Issue simili

Altre issue su C#

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.