EmccCompile: prefer TryRunProcess over RunShellCommand.

[tmds]

A shell is not needed to run emcc.

[maraf]

Thank you @tmds for the contribution!

There are test failures related to the change

src\mono\wasm\build\WasmApp.Common.targets(868,5): error : (NETCORE_ENGINEERING_TELEMETRY=Build) Failed to compile D:\a\_work\1\s\artifacts\bin\microsoft.netcore.app.runtime.browser-wasm\Release\runtimes\browser-wasm\native\src\driver.c -> D:\a\_work\1\s\artifacts\obj\System.Diagnostics.Tracing.Tests\Release\net11.0-browser\browser-wasm\wasm\for-publish\driver.o
An error occurred trying to start process 'D:\a\_work\1\s\src\mono\browser\emsdk\emscripten\emcc' with working directory 'D:\a\_work\1\s\src\libraries\System.Diagnostics.Tracing\tests'. The specified executable is not a valid application for this OS platform.

https://github.com/dotnet/runtime/pull/126150/checks?check_run_id=68749851592

[maraf]

I'm thinking if there wasn't reason to put the command in batch file, something like too long input

[dotnet-policy-service]

Tagging subscribers to 'arch-wasm': @lewing, @pavelsavara
See info in area-owners.md if you want to be subscribed.

[pavelsavara]

There is problem with too long list of arguments.
This needs to be redesigned to use response files, similar to #123548

[tmds]

I'm thinking if there wasn't reason to put the command in batch file

It seems that on Windows emcc is invokable as emcc because of emcc.bat. You can't Process.Start a bat file. I've added some code to use cmd and a comment to explain.

There is problem with too long list of arguments.
This needs to be redesigned to use response files,

I think this is independent of the changes made here.

[tmds]

@maraf @pavelsavara please take another look.

[pavelsavara]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[tmds]

@pavelsavara can you take another look?

[maraf]

I looked through the history here, and the shell wrapper appears to have been introduced for process execution reliability, not to avoid command-line length limits.

Relevant history:

• RunShellCommand was centralized in src/tasks/Common/Utils.cs in [mono] Fix race condition in Utils + remove duplicated code #46029 as shared process-launch code.
• EmccCompile started using it when the task was added in [wasm] Compile .bc->.o in parallel, before passing to the linker #54053.
• Later fixes like [wasi/wasm] EmccCompile.cs: quote the compiler path #97427 were specifically about quoting CompilerBinaryPath after switching to a custom emcc path in [wasi] Initial wasi/aot build support #95051.
• The helper also sets UTF-8 on Windows and uses /bin/sh on Unix, which fits the same purpose.

On the command-length question: storing the invocation in a .cmd/.sh file does not make it unlimited once executed.

• On Windows, cmd.exe still applies its 8191-character limit to commands run from batch files. Only a direct CreateProcess launch of an .exe gets the larger ~32767-char limit.
• On Unix-like systems, shell execution is still limited by ARG_MAX.

So the history supports that the wrapper was there for invoking emcc/wrapper scripts correctly across platforms, while the "too many arguments" concern is a separate issue and response files would still be the right fix for that.

[tmds]

@maraf that matches my understanding: wethether .NET or cmd launches a process, they are both subject to the same command length limit. The only way to pass something longer is by putting it in a response file.

The change made here is meant to eliminate the shell on non-Windows. On Windows, we still need cmd because emcc is invoked through a .bat file.

[tmds]

@pavelsavara @maraf is this good to merge?

[maraf]

@tmds I'm sorry for the delay!

Regarding the Windows invocation:

/c "chcp 65001 > nul && "C:\path with spaces\emcc.bat" <args>"

cmd.exe has a subtle rule for /c: it only strips the outer quotes when certain conditions hold (roughly: the string starts with ", and there are exactly two quote characters, or no special characters between them). With quoted paths plus quoted arguments there can be many inner quotes, and the parser’s behavior becomes hard to reason about — it is easy to end up with a command cmd interprets differently than intended.

A safer pattern is to pass /S /c "…". The /S flag forces cmd to always strip exactly one pair of outer quotes regardless of the inner quoting, which makes the command line robust when CompilerBinaryPath or any source path contains spaces or special characters.