[wasm] Design application startup, template, configuration

[pavelsavara]

TODO

• Adopt blazor.boot.json like format, instead of mono-config.json
• Separate assets/manifest from application config from current run arguments
• Unify the templates and it's runArgs.json
• PATH-like DLL resolution for nodeJS, (and WASI?)
• runtimeconfig.json/.bin and launchsettings
• remove features like proxyConsoleMethod from template, or integrate them with runtime
• Incremental updates
• Try to load assemblies to VFS (instead of WASM memory) and let runtime load them from there
• [wasm][nodejs] implement synchronous DLL loading #79981 - on NodeJS/V8 let runtime load assemblies on the fly from local filesystem without extra boot config
• Experiment with serializing initial wasm memory instead of loading dlls
• Experiment with inlined mono-config (faster startup, in-place URLs of all assets)
• [browser] Split dotnet.js and introduce loader + emscripten modules #85045

[ghost]

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

Issue Details

---

TODO

• Adopt blazor.boot.json like format, instead of mono-config.json
• Separate assets/manifest from application config from current run arguments
• Unify the templates and it's runArgs.json
• PATH-like DLL resolution for nodeJS, (and WASI?)
• runtimeconfig.json/.bin and launchsettings
• remove features like proxyConsoleMethod from template, or integrate them with runtime

Author:	pavelsavara
Assignees:	pavelsavara
Labels:	arch-wasm, area-System.Runtime.InteropServices.JavaScript
Milestone:	7.0.0

[pavelsavara]

If we package dotnet.js as npm module, we should probably include the runtime DLLs in the package.
I experimentally did it at npm package and demo

Current problem is that it uses mono-config.json with "assembly_root": "managed", which is relatetive to dotnet.js.
That is trying to load C:\Dev\runtime-npm\demo\node_modules\@pavelsavara\dotnet-runtime/managed/Microsoft.CSharp.dll

But I don't have managed subfolder there. I'm not sure I like the managed subfolder.
Anyway, the location doesn't contain Demo.dll and mono-config.json probably can't handle multiple folders either.

[radical]

I believe we have completed some of the items, and others will have to be in 8.0 .

[pavelsavara]

the dotnet run host has host arguments before -- and application arguments after.
the same is valid for node.exe it also has --.

If we want to be able to pass host arguments to the mono runtime, we should do it by other means than mixing into the application arguments of NodeJS app.

Maybe we could do it by setting environment variables for the NodeJS process.

In case of the browser, we have withApplicationArgumentsFromQuery which are also application arguments, same as if they were after -- and so we should probably pass anything from dotnet run after -- to query string.
But for the mono runtime arguments, we need to find another means of doing that than withApplicationArgumentsFromQuery or change it to understand --.

runArgs.json was an attempt. But I don't want to make download of it part of each production application, especially if that is blocking the rest of the startup (as those args need to be applied early).

[pavelsavara]

I mean node --enable-source-maps main.js -- hello.dll --setenv=XXX=1 -- -fromCity=Prague to Ilona where
--enable-source-maps is nodeJS engine flag
--setenv=XXX=1 is mono engine flag
-fromCity=Prague is application argument
to is application arg
Ilona is application arg

The main.js would have to add call to new withRuntimeOptionsFromArguments

[pavelsavara]

we could do the same for the browser and the --setenv=XXX=1 -- -fromCity=Prague to Ilona part would be URLencoded query string.

The main.js -- hello.dll is part of index.html

For that we would have to modify the BrowserHost to produce -- before application arguments and the withApplicationArgumentsFromQuery to start parsing only after --

The main.js would have to add call to new withRuntimeOptionsFromQuery()

[pavelsavara]

cc @ilonatommy

[pavelsavara]

@maraf said that

1. main.js is application code and it should be able to decide how to process all params
2. envs and runtime options could be also in mono-config.json, which is changed at build time

[pavelsavara]

@radical

IF 1) is correct THEN
we don't have to provide any tools to produce or consume env and runtime options outside build

we could provide convenience methods to be able to parse the mono options from args in the dotnet.js and deal with --. But I do not feel too strongly about that.

parsing user's version of runArgs.json is very easy with JSON.parse already and pass it to APIs we already provide.

If the use-case is to change something like runArgs.json at execution time, I don't want to provide tools for that in the host.
It would be application business.

Finally, the test-main.js is an application like any other. It could load and parse runArgs.json on it's own.
We could create runArgs.json in WBT directly, we don't need host to do it for WBT.
We could drop support for it from BrowserHost and runArgs.json

BUT I would be missing ability to pass mono options on node commandline to ANY wasm app. On the other hand, that's true for any .NET executable file. You can't use application's arguments to configure CLR either.

[radical]

If the use-case is to change something like runArgs.json at execution time, I don't want to provide tools for that in the host. It would be application business.

runArgs.json is strictly for use with dotnet run which needs the project. So, this is for the developer for their end-users.
dotnet run can trigger a build, but it can also be run with --no-build but with different parameters. I would imagine running it with maybe different configuration for the web server, or different arguments passed to the engine.

Finally, the test-main.js is an application like any other. It could load and parse runArgs.json on its own. We could create runArgs.json in WBT directly, we don't need host to do it for WBT. We could drop support for it from BrowserHost and runArgs.json

It's not for WBT, it's for users:)

BUT I would be missing ability to pass mono options on node commandline to ANY wasm app. On the other hand, that's true for any .NET executable file. You can't use application's arguments to configure CLR either.

dotnet run/exec do allow you to configure the host, or the running environment for the app. That's what I see runArgs.json doing here. It's independent of the build and simply letting you alter the host/environment for the app.

My plan was to move runArgs.json to a launchSettings.json, which is more in line with what other .net apps have.

Maybe we can:

1. move the command line args, and mono args completely to query parameters
2. And I'll move the engine, host environment part of the configuration to launchSettings.json, which will get processed in the same way as runArgs.json.

[radical]

My plan was to move runArgs.json to a launchSettings.json, which is more in line with what other .net apps have.
Maybe we can:

1. move the command line args, and mono args completely to query parameters
2. And I'll move the engine, host environment part of the configuration to launchSettings.json, which will get processed in the same way as runArgs.json.

Sorry, I misspoke, and confused two things here. I meant:

• the run profiles that we have in runtimeconfig.json right now, will be moved to launchsettings.json. And that is independent of runArgs.json.

So, updated:

1. move the command line args, and mono args completely to query parameters
   2. And I'll move the engine, host environment part of the configuration to launchSettings.json, which will get processed in the same way as runArgs.json.

2. For the rest, I will try this out again, and see what we can do.

[maraf]

runArgs.json are meant to be applied only when running using dotnet run, is that correct?
Do we want to deal with params passed by invoking node directly?

If they are stored as file, what should happen when user does something like this?

dotnet run ... --arg 1
...
dotnet run ... --arg 2
...
node main.js

On the browser, what about injecting params dynamicly into the served html as browserLink does?

[pavelsavara]

On the browser, what about injecting params dynamicly into the served html as browserLink does?

I like that a lot ^^

And for node we could use environment variables as side channel for mono options.
Something like MONO_OPTIONS probably already exists?
dotnet.exe could set environment variables before executing nodeJS.
And we could read it in the startup.ts when running nodejs.

[pavelsavara]

For WASI we will have the same issue. And there is no JS and env variables do not flow into inside the VM automatically.
I guess we could do explicit wasmtime run --env MONO_OPTIONS="values" dotnet.wasm

[pavelsavara]

Closing this in favor of #88760 and #70762