[browser][coreCLR] node and v8 CLI support for default browser runtime

[pavelsavara]

This PR allows to use dotnet.js directly from runtime pack similar way as dotnet.exe run

Motivation: V8 is a "naked" JS engine. We use it to run microbenchmarks.

The challenge with V8 is that doesn't give us the directory listing feature of the OS.
So we have to first create file dotnet.assets.txt that the V8 could read list of DLLs.

PS D:\> node dotnet.js
usage: v8 --module dotnet.js -- hello.dll arg1 arg2
usage: node dotnet.js HelloWorld.dll arg1 arg2

PS D:\> node dotnet.js HelloWorld.dll a b c d
Hello, World!

PS D:\> v8 --module dotnet.js
usage: v8 --module dotnet.js -- hello.dll arg1 arg2
usage: node dotnet.js HelloWorld.dll arg1 arg2

PS D:\> v8 --module dotnet.js -- HelloWorld.dll a b c d
Shell/V8 can't list files in the current directory.
Please generate an 'dotnet.assets.txt' file with the list of files to load.
Depending on your shell, you can use one of the following commands:
  Get-ChildItem -Name > dotnet.assets.txt
  dir /b > dotnet.assets.txt
  ls > dotnet.assets.txt

PS D:\> Get-ChildItem -Name > dotnet.assets.txt
PS D:\> v8 --module dotnet.js -- HelloWorld.dll a b c d
Hello, World!

Alternatively you can always use our WASM SDK, to create full application manifest (with all the DLLs and other config) and embed it directly into dotnet.js.

Or alternatively import { dotnet } from './_framework/dotnet.js' as a library and use it's host builder API.

Or alternatively even more stripped corerun, that works only with NodeJS

PS D:\> node .\corerun.js /HelloWorld.dll a b c
Hello, World!

Fixes #120208
Both A1) and A2)

[dotnet-policy-service]

Tagging subscribers to this area: @agocke, @jeffschwMSFT, @elinor-fung
See info in area-owners.md if you want to be subscribed.

[AaronRobinsonMSFT]

Love the idea. Thanks!

[pavelsavara]

In short discussion with Maraf yesterday, he expressed that self-configuration V8 (and maybe NodeJS) use-case is moot.
And that we are always better off with WASM-SDK putting together the application folder and application manifest.

That's the methods isNodeHosted, isShellHosted, shellFindResources, nodeFindResources, findResources.
I'm happy to delete that self-configuration code, so that we don't have to maintain it.
On the other hand, it's just 100 lines.
The rest of this PR is enabling V8 in WASM-SDK scenario and I want to merge it.

It's fair to say that for R2R or linking any native C library we actually need WASM-SDK.
We will be using WASM-SDK even for microbenchmarks.
This idea only works for full MSIL interpreter, in very default configuration.

My use-cases for that self-configuration from current directory are mostly about lowering the bar of exploration and adoption.

• For (coreCLR VM) people, who don't want to use that MsBuild/WASM-SDK to be able to quickly try to run some app.
• maybe for someone who wants to package the wasm dotnet runtime as NPM package (without shipping dotnet SDKs).

What do you think @maraf @radekdoulik @lewing @AaronRobinsonMSFT

[pavelsavara]

I introduced browserVirtualAppBase constant(s) to unify in which directory of the VFS the application runs.

I made it to be /managed folder consistently.
In NodeJS this allows us to mount current directory of the host into it.

For Mono it was / until now, unless someone specified virtualWorkingDirectory in the manifest.
I changed that to /managed too, to see what would happen/break.

I also changed the default TargetPath of <WasmFilesToIncludeInFileSystem> to be relative to that, when not specified.

@maraf please let's talk about this

[pavelsavara]

In short discussion with Maraf yesterday, he expressed that self-configuration V8 (and maybe NodeJS) use-case is moot.

We had chance to discuss at length with @maraf this morning.

TL;DR: the self-configuring CLI experience doesn't make much sense outside of simplest demo. Use WASM SDK!

• to create NPM package out of runtime pack would work, but
• it's only useful with pure IL assembly that has some Main()
• mostly only with NodeJS, not with V8, because console app without FS is not very useful.
• in most environments, as a customer, you can use OS-native dotnet run instead
• the use-case of using the npm package + our JS host API would work
• but you can't really call into managed code without JSExport.
• Module.ccall into UnmanagedCallerOnly is possible, but quite low-level experience
• you are better off with WASM SDK, and so, you don't need the self-configuration

I will close this PR, take the V8 polyfill and other useful bits of this PR and create another PR.