How gets `RunArguments` property evaluated?

[maraf]

I would like to change RunArguments based on other property value

I have this snippet

<_RunExtraArguments Condition="'$(WasmEnableThreads)' == 'true'">--apply-cop-headers</_RunExtraArguments>
<RunArguments>&quot;$(_BlazorDevServerDll)&quot; --applicationpath &quot;$(TargetPath)&quot; $(_RunExtraArguments)</RunArguments>

If WasmEnableThreads property is set in the csproj, it works as expected (_RunExtraArguments is set to --apply-cop-headers). But if I pass it as an agrument on command line dotnet run /p:WasmEnableThreads=true, the WasmEnableThreads property value is empty when RunArguments are computed.

Do you have any advice on how accomplish such use case?

[vitek-karas]

The problem is that dotnet run doesn't process the arguments, it passes everything to the app. So in your example: dotnet run /p:WasmEnableThreads=true the app will be executed with a command line parameter /p:WasmEnabledThreads=true.

I vaguely remember that there was an issue on this topic here already, but I can't find it right now.

[KalleOlaviNiemitalo]

AFAICT, in .NET SDK 7.0.105, dotnet run passes /p:WasmEnableThreads=true to the application, but processes -p:WasmEnableThreads=true or --property:WasmEnableThreads=true to set the property.

[maraf]

I tested it today with 8.0.100-preview.4.23220.2

• /p:WasmEnableThreads=true is passed to the "run" process (as documentation says)
• both -p:WasmEnableThreads=true and --property:WasmEnableThreads=true are ignored

I have a simple console project echoing arguments

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <RunCommand>cmd.exe</RunCommand>
    <RunArguments>/c &quot;echo '$(WasmEnableThreads)'&quot;</RunArguments>
  </PropertyGroup>
</Project>

The output is

C:\Development\samples\ConsoleSample>dotnet run /p:WasmEnableThreads=true
'' /p:WasmEnableThreads=true

C:\Development\samples\ConsoleSample>dotnet run -p:WasmEnableThreads=true
''

C:\Development\samples\ConsoleSample>dotnet run --property:WasmEnableThreads=true
''

Is it a regression?

[baronfel]

Here's what the behavior should be:

• properties of all kinds (/p, -p, --property, etc) should be applied to
  • the (implicit) build of the project, if necessary
  • the evaluation of the project (to read RunCommand/RunArguments)
• properties should not be applied to the application that is run
• if a user wants the properties to be applied to the application that is run, they need to specify -- to signal that all tokens after the -- are forwarded to the application and not consumed by the run command.

@nagilson can you verify the first two points on preview5? If we're not applying the properties to the evaluation then we need to start doing so.

[dsplaisted]

It looks like there are two problems:

• We are not consistent about how we handle the different forms: /p, -p, or --property, ie whether we use them for the build or forward them to the application that is run. We should use them for the build in all these cases (unless they are after the -- separator).
• We do not pass these global properties to the evaluation where we get the RunCommand and RunArguments properties. We should do this (in RunCommand.GetTargetCommand)

[pavelsavara]

We have open WASM issue https://github.com/dotnet/runtime/issues/85674 in which we also discuss how to also separate arguments to host VM and also mono VM. Possibly with multiple --

Host VM (not dotnet): We are running inside NodeJS, browser or wasmtime VM, all of those have their own parameters. For example which env variables should be propagated into the VM, or which directories should be mounted. I imagine that docker VM would be in the same category, if it becomes supported host.

Mono runtime (dotnet VM): there are runtime flags would be good to set, usually to enable more logging, debugging, profiling.

Perhaps there should be pass-thru argument like --host:xxx=yyy and --runtime:aaa=bbb before application -- ? As an alternative to multiple --.

We considered some side channel, like runtimeconfig.json. It causes extra file download in browser. Extra FS access permissions in wasmtime which is not always possible. Also I'm not clear if passing runtime arguments to dotnet run should modify runtimeconfig.json file.

[radical]

We do not pass these global properties to the evaluation where we get the RunCommand and RunArguments properties. We should do this (in RunCommand.GetTargetCommand)

Can we spin this off into a separate issue so it can be fixed independent of the discussion here?

[baronfel]

Triage: This is solved as of .NET 9 - the ComputeRunArguments target was added to allow MSBuild-logic to influence the RunArguments, RunCommand, and RunWorkingDirectory. In addition, the CLI addressed @dsplaisted's two noted issues by consistently modelling and parsing all forms of the MSBuild property option, and applying it to the implicit evaluations that the dotnet run command does to find the command to invoke.