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"
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
- Ambito
- build-system, testing
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
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
PackageReferencetoMicrosoft.Testing.Platform.MSBuild2.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 callAddMSBuild(). - 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.
- When the arguments contain
TestHostControllersTestHostadds--internal-testhostcontroller-pidto 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:
- The MSBuild task starts
Repro.dll --internal-msbuild-node <pipe> --report-trx. - The controller starts the child host.
- The child skips the MSBuild lifetime callbacks, so it never sends
ModuleInfoRequest. - Nothing relays this information for the non-packaged controller case.
InvokeTestingPlatformTaskends with no module info and logsDidNotReceiveModuleInfo.
- The MSBuild task starts
- To confirm the cause, I used a custom entry point (
GenerateTestingPlatformEntryPoint=false,GenerateSelfRegisteredExtensions=false).Mainregisters MSTest and the TRX provider and callsbuilder.AddMSBuild()unconditionally.- With MSTest.Sdk 4.5.1 and
--report-trx,dotnet build -t:Testthen passes and writes the TRX file.
- The same skip logic is still present on
mainandrel/4.5as 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
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di microsoft/testfx
-
type/automation type/tech-debt
Difficoltà 4/5 1-2 giorni Idoneità per principianti 48/100
I maintainer di solito rispondono entro 1 giorno
-
area/dump needs/triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 45/100
microsoft/testfx#11981 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
type/automation type/tech-debt
Difficoltà 5/5 Più di una settimana Idoneità per principianti 5/100
I maintainer di solito rispondono entro 1 giorno
-
area/server-mode-jsonrpc
Difficoltà 5/5 Più di una settimana Idoneità per principianti 8/100
I maintainer di solito rispondono entro 1 giorno
-
[mutation-test-improver] Monthly Report 2026-10Forse già presa Una pull request collegata a questa issue è aperta o già unita. Apertatype/automation type/test-gap
Difficoltà 4/5 3-5 giorni Idoneità per principianti 35/100
microsoft/testfx#11704 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di microsoft/testfx
Issue simili
-
area-multitenancy area-security p1-recommended priority-high technical-debt
Difficoltà 2/5 Meno di un'ora Idoneità per principianti 75/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
-
help wanted needs-unity ready for a contributor
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
eyalgolan/statecraft-israel#1542 ·
I maintainer di solito rispondono entro 1 giorno
-
kind/enhancement Provider Upgrade pulumi/pulumi-azure R1 Task
Difficoltà 2/5 1-3 ore Idoneità per principianti 65/100
pulumi/pulumi-azure#3669 ·
-
[BUG] FromCString causes 1 byte OOB read in native codeForse già presa Una pull request collegata a questa issue è aperta o già unita. Apertatype/bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno