Smooth out support for running .NET from JS via WebAssembly

[danroth27]

A common scenario for running .NET on WebAssembly is when you want to reuse a .NET library from an existing JS app. In this scenario, the user isn't creating an app from scratch. Instead they are integrating a .NET library into an existing JS based app, like an Angular/React/Vue app that will run in a browser or in a Node.js based app.

Since the app is preexisting, it already has a defined dev workflow. For example, many frontend JS frameworks use an NPM and WebPack based build system and the WebPack dev server for hosting the app locally. Any .NET code needs to be integrated into existing HTML and JS files and hosted as static web assets along with the rest of the JS app.

Some issues that could be addressed to make this experience better:

• The WasmMainJSPath property is currently required even though a main.js file might not be needed. The user may be importing dotnet.js directly into their existing app. It seems like this property should be optional.
• An HTML file is currently always generated for the app, even though in existing JS apps the host HTML files likely already exist. Generating this file should probably be optional.
• The project must currently be <OutputType>Exe</OutputType> and a main entry point is currently required. For calling into a .NET library from JS it seems like a library project should be allowed. [browser] Suport for OutputType Library #89577
• We should consider making dotnet.js available from NPM. We've had similar requests for the Blazor scripts: Publish blazor.*.js files to npm aspnetcore#10124.

[dotnet-issue-labeler]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

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

Issue Details

---

A common scenario for running .NET on WebAssembly is when you want to reuse a .NET library from an existing JS app. In this scenario, the user isn't creating an app from scratch. Instead they are integrating a .NET library into an existing JS based app, like an Angular/React/Vue app that will run in a browser or in a Node.js based app.

Since the app is preexisting, it already has a defined dev workflow. For example, many frontend JS frameworks use an NPM and WebPack based build system and the WebPack dev server for hosting the app locally. Any .NET code needs to be integrated into existing HTML and JS files and hosted as static web assets along with the rest of the JS app.

Some issues that could be addressed to make this experience better:

• The WasmMainJSPath property is currently required even though a main.js file might not be needed. The user may be importing dotnet.js directly into their existing app. It seems like this property should be optional.
• An HTML file is currently always generated for the app, even though in existing JS apps the host HTML files likely already exist. Generating this file should probably be optional.
• The project must currently be <OutputType>Exe</OutputType> and a main entry point is currently required. For calling into a .NET library from JS it seems like a library project should be allowed.
• We should consider making dotnet.js available from NPM. We've had similar requests for the Blazor scripts: Publish blazor.*.js files to npm aspnetcore#10124.

Author:	danroth27
Assignees:	-
Labels:	arch-wasm, untriaged, area-Build-mono
Milestone:	-

[radical]

The project must currently be Exe and a main entry point is currently required. For calling into a .NET library from JS it seems like a library project should be allowed.

We could use either OutputType=Library, or some new property to indicate the case where the output bundle doesn't need to have a main js, or index.html .

[maraf]

I'm working on a sample of integrating a .NET library into a react component wrapped as npm package and installed into a target react application.

https://github.com/maraf/dotnet-wasm-react

[maraf]

Moving the rest of items to .NET 9