Honor @(RuntimeEnvironmentVariable) item changes when launching the app#54922
Open
rolfbjarne wants to merge 7 commits into
Open
Honor @(RuntimeEnvironmentVariable) item changes when launching the app#54922rolfbjarne wants to merge 7 commits into
rolfbjarne wants to merge 7 commits into
Conversation
Commit bd5d3af added support for passing `dotnet run -e KEY=VALUE` environment variables to MSBuild as the `@(RuntimeEnvironmentVariable)` item group (opt-in via the `RuntimeEnvironmentVariableSupport` project capability), so targets can inspect them. However, when the app/executable was eventually launched, only the original `-e` values were applied to the process environment. Any additions or changes a target (e.g. `ComputeRunArguments`) made to the `@(RuntimeEnvironmentVariable)` item group were ignored. Fix: for opted-in projects, after `ComputeRunArguments` runs, read the final `@(RuntimeEnvironmentVariable)` item group back and apply it to the launched command instead of the raw `-e` dictionary. Non-opted-in projects keep using the `-e` values directly, so behavior is unchanged. Added `EnvironmentVariablesToMSBuild.HasRuntimeEnvironmentVariableSupport` and `ReadFromItems`, plus a regression test and a test-asset target that modifies the item group before the app runs. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Member
Author
Contributor
There was a problem hiding this comment.
Pull request overview
This PR fixes dotnet run -e KEY=VALUE handling for projects that opt in to @(RuntimeEnvironmentVariable) support, ensuring that any MSBuild target modifications to the item group (e.g., via ComputeRunArguments) are reflected in the launched app’s process environment.
Changes:
- Update
RunCommandto (for opted-in projects) read back the final@(RuntimeEnvironmentVariable)items afterComputeRunArgumentsand apply them when launching the app. - Add
EnvironmentVariablesToMSBuild.HasRuntimeEnvironmentVariableSupportandEnvironmentVariablesToMSBuild.ReadFromItemshelpers to centralize capability checks and item reading. - Add a regression test plus a test-asset target/app output to verify that target-injected/modified environment variables are honored at execution time.
Reviewed changes
Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| src/Cli/dotnet/Commands/Run/RunCommand.cs | Uses final @(RuntimeEnvironmentVariable) items (when opted in) to set the launched command’s environment variables. |
| src/Cli/dotnet/Commands/Run/EnvironmentVariablesToMSBuild.cs | Adds helpers to detect opt-in capability and read environment variables back from MSBuild items. |
| test/dotnet.Tests/CommandTests/Run/GivenDotnetRunSelectsDevice.cs | Adds regression coverage asserting MSBuild target changes to env var items affect the launched app. |
| test/TestAssets/TestProjects/DotnetRunDevices/DotnetRunDevices.csproj | Adds a target that mutates/injects @(RuntimeEnvironmentVariable) items prior to ComputeRunArguments for testing. |
| test/TestAssets/TestProjects/DotnetRunDevices/Program.cs | Emits RUNE_* environment variables so tests can validate what the app actually received. |
`ReadFromItems` hardcoded `StringComparer.Ordinal`, but `-e/--environment` parsing uses `OrdinalIgnoreCase` on Windows (where environment variable names are case-insensitive) and `Ordinal` elsewhere. Match that comparer so the read-back item group dedups variable names consistently with the original `-e` dictionary, avoiding subtle override/duplication issues when a target changes the casing of a `@(RuntimeEnvironmentVariable)` item. Addresses PR review feedback. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Revert the previous OS-specific comparer change. As Jonathan Peppers noted, the OS running `dotnet run` doesn't necessarily match the OS the app will run on (e.g. building an Android project on Windows), so basing the comparer on RuntimeInformation of the current process is incorrect. Use Ordinal and preserve the @(RuntimeEnvironmentVariable) items exactly as MSBuild produced them, with a comment explaining the reasoning. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
The ReadFromItems and HasRuntimeEnvironmentVariableSupport helpers added for 'dotnet run -e' RuntimeEnvironmentVariable support previously only had indirect, end-to-end coverage via the DotnetRunDevices CLI test. Add focused in-memory unit tests that build a ProjectInstance from inline XML and exercise both helpers directly: - HasRuntimeEnvironmentVariableSupport: capability present/absent, only-other capabilities, and case-insensitive matching. - ReadFromItems: empty, single, multiple items, and missing Value metadata. - AddAsItems -> ReadFromItems round-trip. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This was referenced Jun 24, 2026
jonathanpeppers
approved these changes
Jun 24, 2026
This was referenced Jun 24, 2026
dotnet.Tests was migrated to MSTest.Sdk on main; merging that in left the two test additions from this branch using xUnit [Fact], which no longer compiles (CS0246 'Fact'). Convert them to MSTest: - EnvironmentVariablesToMSBuildTests: add [TestClass], [Fact] -> [TestMethod]. - GivenDotnetRunSelectsDevice.ItHonorsRuntimeEnvironmentVariableChangesFromTargetsWhenRunningApp: [Fact] -> [TestMethod] (the rest of the class was already migrated by the merge). Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Commit bd5d3af added support for passing
dotnet run -e KEY=VALUEenvironment variables to MSBuild as the@(RuntimeEnvironmentVariable)item group (opt-in via theRuntimeEnvironmentVariableSupportproject capability), so targets can inspect them.However, when the app/executable was eventually launched, only the original
-evalues were applied to the process environment. Any additions or changes a target (e.g.ComputeRunArguments) made to the@(RuntimeEnvironmentVariable)item group were ignored.Fix
For opted-in projects, after
ComputeRunArgumentsruns, read the final@(RuntimeEnvironmentVariable)item group back and apply it to the launched command instead of the raw-edictionary. Non-opted-in projects keep using the-evalues directly, so their behavior is unchanged.EnvironmentVariablesToMSBuild.HasRuntimeEnvironmentVariableSupport(de-duplicating the capability check) andEnvironmentVariablesToMSBuild.ReadFromItems.InvokeRunArgumentsTargetreturn whether the project opted in, soGetTargetCommandForProjectcan read the item group back and pass it toSetEnvironmentVariables.Behavior change
For opted-in projects this is an intentional, user-visible behavior change: the final
@(RuntimeEnvironmentVariable)item group now wins over the raw-evalues when launching the app. Projects without theRuntimeEnvironmentVariableSupportcapability are unaffected.Tests
Added a regression test (
ItHonorsRuntimeEnvironmentVariableChangesFromTargetsWhenRunningApp) and a test-asset target (_ModifyRuntimeEnvironmentVariable) that changes/injectsRUNE_*variables before the app runs; the launched app now observes the modified/injected values. Verified the fullGivenDotnetRunSelectsDeviceclass (23 tests) and the standarddotnet run -eoverride tests pass.