TRX default output directory changed between MSTest.Sdk 4.2.3 and 4.3.0?

[chvollm]

Hi team, I am seeing a behavior change in TRX output location across SDK versions and want to confirm whether this is expected.

Environment:

.NET SDK: 10.0.400-preview.0.26322.102
Runner: Microsoft.Testing.Platform
Command used:
dotnet test -- --report-trx --report-trx-filename test_results.trx

Observed behavior:

With MSTest.Sdk 4.2.3 (MTP 2.2.3): TRX is generated under the build output TestResults folder.
With MSTest.Sdk 4.3.0 (MTP 2.3.1): TRX is generated under a top-level TestResults folder for the project.
Question:

Was the default base directory for TRX output intentionally changed in this version range?
If yes, where is this documented?
What is the recommended way to keep the previous location behavior?
Notes:

I found release notes about report filename improvements (placeholders and path support), but I did not find a clear note explicitly describing a default output directory change.

[Evangelink]

This behavior change is the result of a fix that spans both the .NET SDK and Microsoft.Testing.Platform:

• The .NET SDK now communicates the original dotnet test working directory to child test applications.
• Microsoft.Testing.Platform 2.3.x uses that directory as the base for the default TestResults directory.

The intent was to fix relative path and result directory handling so that outputs consistently resolve from the directory where dotnet test was invoked. Unfortunately, the issue took us too long to fix, and changing the behavior after users had relied on the previous behavior caused a break that we did not anticipate—at least not at the scale reflected by the number of impacted users.

I am exploring solutions that preserve a central TestResults location while avoiding collisions between test applications. One possibility is to place each application's results in a generated subdirectory using a template such as {asm}_{tfm}_{platform}. We need to evaluate the compatibility and tooling implications before settling on the exact shape.

In the meantime, an explicit --results-directory remains the way to control the output location.

[chvollm]

Thanks! I can work with --results-directory, I was just wondering if it is just me or something funny going on. And the build breaking unexpectedly was a bit annoying.

[Evangelink]

And the build breaking unexpectedly was a bit annoying.

HAve you had build break? I am aware of the warning about file being overriden but not a build break.

[chvollm]

Only because of a script that tried to parse the results file and did not fail because of a missing file but returned 0 successful tests. Because of that my build failed. So I had the opportunity to improve my script. 😉

[Evangelink]

Alright! Sorry again for the break, I am working on a fix and glad we somehow help you improve your script ;)

[yannic-hamann-abb]

We ran into this because of automated dependencies updates of Microsoft.Testing.Extensions.CodeCoverage.

This breaks for us the convenience of this one liner:

dotnet-coverage collect 'dotnet test --solution "MySolution.sln" --configuration Release --report-xunit-trx --report-xunit-trx-filename test_result.trx' -f xml -o 'coverage.xml'

Within MySolution.sln are separate UnitTests and IntegrationTests projects.

Our pipeline broke because the file path changed but also the output files are colliding and overwriting each other, effectively causing one of the test results to be discarded.

Pathes changed from

    - /MySolution/MySolution.UnitTests/bin/Release/net10.0/TestResults/test_result.trx
    - /MySolution/MySolution.IntegrationTests/bin/Release/net10.0/TestResults/test_result.trx

to:

    - /MySolution/TestResults/test_result.trx
    - /MySolution/TestResults/test_result.trx

Amaury Levé (@Evangelink) can we do anything to e.g. name test_results differently while still being able to use dotnet-coverage collect?

[Evangelink]

I traced the exact boundary. This is the interaction of two intended fixes rather than a TRX-only directory change:

• dotnet/sdk#52570 made dotnet test pass its invocation directory to child MTP test applications through DOTNET_CLI_TEST_COMMAND_WORKING_DIRECTORY. It first shipped in the .NET SDK 10.0.200 feature band.
• microsoft/testfx#7265 made Microsoft.Testing.Platform use that value as the base for its working and results directories. It first shipped in Microsoft.Testing.Platform 2.3.1 / MSTest.Sdk 4.3.0.

Both sides are required to observe the change. In practical terms, MSTest.Sdk 4.3.0 is where existing users first see the new behavior when running with .NET SDK 10.0.200 or newer. MSTest.Sdk 4.2.3 does not consume the environment variable, so it keeps the test-application output directory as the fallback.

What users can do today:

1. Pass an explicit --results-directory when a specific base directory is required. For a solution containing several test projects, a shared directory plus the same explicit report filename can still collide.

2. With the MTP TRX reporter (--report-trx), either omit --report-trx-filename—the default filename is unique per assembly/TFM/architecture—or use the placeholders added in microsoft/testfx#8223, for example:

   dotnet test --report-trx --report-trx-filename "test_results_{asm}_{tfm}_{arch}.trx"

   Add {pid} when duplicate assembly names are possible.

3. Reporters that do not support those placeholders, including a fixed shared --report-xunit-trx-filename, need separate per-project result directories (or separate project invocations) for now.

The SDK-side general solution has now merged in dotnet/sdk#55475. It adds:

dotnet test --results-directory-layout per-module --report-trx --report-trx-filename test_result.trx

This creates TestResults/<project>/<tfm>_<rid-or-arch>/..., so every test application can safely use the same report filename. The default remains flat for compatibility. The change merged to the .NET SDK main branch on August 5 and is not in a released stable SDK yet; main is currently the .NET 11 Preview 7 line.