How gets `RunArguments` property evaluated?

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?

[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.

[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.