[dotnet-run] Allow overriding launch profile environment variable values

[tmat]

dotnet run -lp Profile uses env variables from the specified profile and ignores the values set in the current environment.
This is true even when the environment variable is explicitly set via an environment directive, e.g. dotnet [env:X=Y] -lp Profile.
As a result, there is no way to override an environment variable value set in the profile.

dotnet-watch launches projects via dotnet run. When invoked by Aspire DCP server it needs to implement Aspire launch profile semantics, which require any explicitly specified environment variable value to override the value in the launch profile. To implement this protocol correctly we need to be able to invoke dotnet run with specified env variable values overridden.

Possible options:

• change run to only set env vars from the LP if there isn't a value already set in the executing environment [breaking change]
• change run to only set env vars from the LP if there isn't a value already set in the by [env:X=Y] directive [less breaking]
• change run to have a new -e/--environment KEY=VALUE option that can be used to override the value [almost not breaking]

Note:
Command line arguments passed explicitly on dotnet run command line override those specified in launch profile. This is the desired behavior and it seems environment variables should behave the same way.

Related env variable directive issue:
#40484

[tmat]

@dsplaisted @baronfel @davidfowl @marcpopMSFT

[marcpopMSFT]

Triage
We discussed the various options proposed and while many would work, they would require creating new concepts. We think the -e CLI option for run makes the most sense as it aligns with dotnet test which already has that command as well as other ecosystems that have a similar option.

@tmat Chet said you were willing to potentially implement this. Is this something you were willing to take on? The environment part is probably straight forward but the trick here would be ensuring that the launch profile doesn't override a value specified by the -e option.

[tmat]

I can give it a try and see if I can figure it out.

[tmat]

If we go with -e what's the purpose of env directives? Should we make them obsolete?

[baronfel]

We get them for free from S.CL and I believe other teams have used them in the past (we had bugs logged a couple years ago where an S.CL update accidentally removed them and teams screamed). This -e is just a more clear/surfaced in help way that we can more concretely control.

[tmat]

OK. Just seems odd to have 2 features that do similar things but are different in subtle ways.