Skip to content

[release/10.0.1xx] Fix --environment variables not applied to test process without launch profile - #54613

Merged
Evangelink merged 1 commit into
dotnet:release/10.0.1xxfrom
Evangelink:dev/amauryleve/backport-53306-to-10.0.1xx
Jun 5, 2026
Merged

Evangelink merged 1 commit into
dotnet:release/10.0.1xxfrom
Evangelink:dev/amauryleve/backport-53306-to-10.0.1xx

Conversation

@Evangelink

@Evangelink Evangelink commented Jun 5, 2026 •

Copy link
Copy Markdown
Member

Backport of #53306 to release/10.0.1xx.

Why this backport is needed

#53306 was merged to main and backported to release/10.0.2xx (#54430), release/10.0.3xx (#54429), and release/10.0.4xx (#54428), but release/10.0.1xx was skipped. Since 10.0.1xx is still actively serviced (preparing 10.0.110), users on the GA feature band are still hitting the bug reported in #54323.

Summary

Fixes environment variables specified via --environment (-e) not being applied to test processes when no launch profile is present.

Problem

In TestApplication.CreateProcessStartInfo(), the loop that applies command-line environment variables was inside the if (Module.LaunchSettings is not null) block. This meant that if:

  • No launchSettings.json existed, or
  • --no-launch-profile was used

...then --environment variables were silently ignored and never set on the test process.

This is inconsistent with dotnet run, where SetEnvironmentVariables() always applies command-line env vars regardless of whether a launch profile is present.

Fix

Move the command-line env var loop outside of the launch profile block. Command-line vars still override launch profile vars when both are present (they are applied after launch profile vars).

Changes

  • src/Cli/dotnet/Commands/Test/MTP/TestApplication.cs

Fixes #54323


Tactics

Summary

This is a backport of #53306 to the release/10.0.1xx servicing branch, fixing a bug in TestApplication.CreateProcessStartInfo() in src/Cli/dotnet/Commands/Test/MTP/TestApplication.cs. The loop that applied command-line environment variables (specified via --environment / -e) was incorrectly nested inside the if (Module.LaunchSettings is not null) block, causing those variables to be silently ignored whenever no launch profile was present. The fix moves the env var loop outside the launch profile conditional so it always executes, matching the existing behavior of dotnet run. The change is a targeted 12-line restructuring appropriate for a servicing release.

Customer Impact

Customers using dotnet test with the --environment (-e) flag would silently have those environment variables ignored on the test process if no launchSettings.json was present in their project or if --no-launch-profile was passed. This affects all projects using the Microsoft.Testing.Platform (MTP) test execution path on .NET SDK 10.0.1xx (all currently shipped 10.0.1xx releases, up to the forthcoming 10.0.110). The env vars were never forwarded to the test process, which could cause test failures or incorrect behavior in any scenario relying on injected env vars. No straightforward workaround exists without adding a launchSettings.json file.

Regression?

Unknown — not enough information to determine exact origin. The bug was present in the MTP test path and reported in issue #54323. The original fix (#53306) was merged to main on 2026-05-19 and subsequently backported to release/10.0.2xx (#54430), release/10.0.3xx (#54429), and release/10.0.4xx (#54428). The release/10.0.1xx branch was unintentionally skipped; this PR corrects that gap.

Testing

This is a direct backport of #53306, which was already validated in main and three other active servicing branches without reported regressions. The diff is a mechanical code move (12 lines: 6 added, 6 deleted, net-zero) with identical logic — only the position relative to the LaunchSettings null-check changes. CI validation ran on this PR. No new unit tests were added (consistent with the original fix). Manual validation can be done by running dotnet test --environment KEY=VALUE on a project without a launchSettings.json and confirming the env var is present in the test process environment.

Risk

Low. The change moves an existing env var application loop from inside a LaunchSettings != null guard to immediately after it, making it unconditional. The logic is identical — only the guard is removed. The scope is a single file with a minimal 12-line diff. The same change has been in production in main and three other servicing branches since May 2026 with no reported issues.

Environment variables specified via --environment (-e) on the command
line were only applied when a launch profile was present. If no launch
profile existed (or --no-launch-profile was used), the variables were
silently ignored.

Move the command-line env var loop outside of the launch profile block,
matching the behavior of 'dotnet run' which always applies command-line
env vars regardless of launch profile presence. The command-line vars
still override launch profile vars when both are present.
Copilot AI review requested due to automatic review settings June 5, 2026 08:28

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR backports the fix from #53306 to release/10.0.1xx, ensuring dotnet test (Microsoft.Testing.Platform mode) applies environment variables provided via --environment/-e even when no launch profile is present.

Changes:

  • Apply TestOptions.EnvironmentVariables unconditionally (not gated on Module.LaunchSettings being present).
  • Preserve precedence: command-line environment variables are still applied after launch-profile variables (when a launch profile exists).
Show a summary per file
File Description
src/Cli/dotnet/Commands/Test/MTP/TestApplication.cs Moves the command-line env-var application loop outside the launch-profile block so -e/--environment always affects the test process.

Copilot's findings

  • Files reviewed: 1/1 changed files
  • Comments generated: 0

@Evangelink
Evangelink enabled auto-merge June 5, 2026 09:29
@marcpopMSFT

Copy link
Copy Markdown
Member

/tactics

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants