[wasm] First attempt at a wasm app host

[radical]

First attempt at implementing a wasm app host

Regular dotnet apps can be run with dotnet run. But this is not the case for
wasm apps. We use xharness to run the test apps that we generate for library
tests.

Templates for browser, and console wasm projects were added recently, but they
have to be run manually by either invoking a v8 script, or running a
http-server in the bundle directory. Though to use a debugger with this
requires starting the debug proxy separately, and connecting few bits.

WasmAppHost

This PR adds a new WasmAppHost, which can be used through dotnet run:

• it can run "wasm app" from it's AppBundle directory, using various hosts
  like v8, node, or a browser. An example use:

  $ dotnet new wasmconsole
  $ dotnet run
  WasmAppHost --runtime-config /tmp/c0/bin/Debug/net7.0/browser-wasm/AppBundle//c0.runtimeconfig.json
  [02:26:40] info: host[0] Running: node main.cjs
  [02:26:40] dbug: host[0] Using working directory: /tmp/c0/bin/Debug/net7.0/browser-wasm/AppBundle
  Incoming arguments:
  Application arguments:
  Debugger.Debug: DEBUGGING ENABLED
  
  mono_wasm_runtime_ready fe00e07a-5519-4dfe-b35a-f867dbaf2e28
  Could not find symbols file dotnet.js.symbols. Ignoring.
  Initializing.....
  Hello, Console!
  

  The console template project is run with node by default.

• it supports a --debug parameter, which (for the browser case) would startup
  a webserver, and the debug proxy for Chrome, and firefox.

$ dotnet new wasmbrowser

$ dotnet run --debug
WasmAppHost --runtime-config /workspaces/test/br0/bin/Debug/net7.0/browser-wasm/AppBundle//br0.runtimeconfig.json --debug --forward-console
Debug proxy for chrome now listening on http://127.0.0.1:9300/. And expecting chrome at http://localhost:9222/
Hosting environment: Production
Content root path: /workspaces/test/br0/bin/Debug/net7.0/browser-wasm/AppBundle
Now listening on: http://127.0.0.1:9300
Debug proxy for firefox now listening on tcp://127.0.0.1:6300. And expecting firefox at port 6000 .

App url: http://127.0.0.1:9000/index.html
App url: https://127.0.0.1:38331/index.html

• This enables using dotnet run with wasm samples, and library tests too.

How do I try this out?

You'll need a dotnet with the updated packs. For now, you can use:

$ ./dotnet.sh build -p:TargetOS=Browser -p:TargetArchitecture=wasm -p:Configuration=Release src/tests/BuildWasmApps/Wasm.Build.Tests/Wasm.Build.Tests.csproj /t:InstallWorkloadUsingArtifacts

.. which would install a sdk in artifacts/bin/dotnet-workload with all the packs installed.

• Use that dotnet to create console, or browser wasm apps from templates, for example dotnet new wasmconsole, or dotnet new wasmbrowser.

Debugging library tests

runtime$ ./artifacts/bin/dotnet-workload/dotnet run -f net7.0 -r browser-wasm -c $YourRuntimeConfig --project src/libraries/System.Buffers/tests/System.Buffers.Tests.csproj -p:DebuggerSupport=true --debug --host browser

• If the runtime was built in Release config, then you need to add -p:DebuggerSupport=true, so the pdbs would get deployed

• And use --debug to start the debugger

• Opening the url will show a Run tests button, which you can click after connecting with the IDE, to start running the tests

Notes, and TODO

• WasmAppHost, along with the debug proxy are bundled in the WebAssembly.Sdk pack right now.

  • This might be changed in the future to use the dotnet app host pack pattern, and with
    additional support adding in the Sdk.
  • This would also allow using launchSettings.json, similar to blazor

• WasmAppHost depends on host config in runtimeconfig.json, which can be
  controlled by a runtimeconfig.template.json in the project directory.

• Needs more tests, cleanup, --help for command line arguments

• app-support.*js in templates, and test-main.js need more work to share the code

Fixes #67236

[ghost]

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

Issue Details

---

null

Author:	radical
Assignees:	-
Labels:	NO-MERGE, NO-REVIEW, arch-wasm
Milestone:	-

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[radical]

Runtime test failures #69517, and #69518 .

I will re-enable all the other jobs that I had disabled.

[radical]

/azp run runtime-wasm

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[thaystg]

It LGTM, and also I tested and it works :)

[radical]

The failures are known, and have issues filed.