[wasm][wasi] No main function should be required when building a library

[silesmo]

Description

Currently mono requires a main function when building for wasi. This shouldn't be required.

Related: #96419

@AaronRobinsonMSFT @lewing @yowl @jsturtevant

Reproduction Steps

Try to build example with main removed.
Example: https://github.com/silesmo/wasm-unmanaged-callers-bug/blob/main/mono-example/MonoEntrypoint.cs

Expected behavior

No main function should be required for a library.

Actual behavior

Main function is required.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[ghost]

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

Issue Details

---

Description

Currently mono requires a main function when building for wasi. This shouldn't be required.

Related: #96419

@AaronRobinsonMSFT @lewing @yowl @jsturtevant

Reproduction Steps

Try to build example with main removed.
Example: https://github.com/silesmo/wasm-unmanaged-callers-bug/blob/main/mono-example/MonoEntrypoint.cs

Expected behavior

No main function should be required for a library.

Actual behavior

Main function is required.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

Author:	silesmo
Assignees:	-
Labels:	arch-wasm, untriaged, area-Build-mono, os-wasi
Milestone:	-

[maraf]

Similar requirement tracked for browser in #77191

[lewing]

See the notes https://github.com/dotnet/runtimelab/blob/feature/NativeAOT-LLVM/src/coreclr/nativeaot/Bootstrap/main.cpp#L179-L229
and some background here https://dylibso.com/blog/wasi-command-reactor/
cc @pavelsavara

[pavelsavara]

This should be triggered by <OuputType>library</OutputType>

[maraf]

One problem I encountered last year was IL trimmer complaining about missing root

Implementation has two parts

• Support OutputType=Library
  • Set roots for IL trimmer
  • NativeAOT does it only for the app project + explicitly marked assemblies. The problem is that we don't want to export too much, because that could cause dead code not to get trimmed
  • This part should be shared with browser
• Initialize runtime
  • At first, take the same approach as NativeAOT, we could possibly improve/change it later
  • Dig into how _initialize should work. Naot is calling it in case it wasn't called by the host from static struct ctor
  • Should the initialization happen in _initialize? So that well-behaving hosts can manage when the "app" is initialized?
    • https://github.com/bytecodealliance/wit-bindgen/blob/9b50b8e78940af080ed3b7c0238e11b04a4bd17b/crates/csharp/src/lib.rs#L587-L594
    • https://github.com/WebAssembly/wasi-libc/blob/main/libc-bottom-half/crt/crt1-command.c#L11
    • https://github.com/WebAssembly/wasi-libc/blob/main/libc-bottom-half/crt/crt1-reactor.c#L8
  • Should the initialization happen on first UCO (wasm export) call?
    • NativeAOT implementation https://github.com/dotnet/runtimelab/blob/feature/NativeAOT-LLVM/src/coreclr/nativeaot/Bootstrap/main.cpp#L193-L259
    • Update ManagedToNativeGenerator to generate initialization call when OutputType=Library
  • Mono implementation https://github.com/dotnet/runtime/blob/main/src/mono/wasi/runtime/main.c#L15

[maraf]

We probably might need a different mechanism to compile library as wasm library. Currently we need RuntimeIdentifier=*-wasm + OutputType=exe.

• RuntimeIndentifier defines API surface that we can use (like JS interop)
• OutputType=exe ensures that wasm build happen.

In typicaly solution user would have several library projects and (one or some) exe projects that are applications. Those library projects might have RID set to *-wasm to enable wasm API. Currenly only the application projects would do the wasm build. Which is correct IMO. If we support wasm build on OutputType=library, it would a lot of additional steps in such solution.

Other parts of .NETE SDK include special steps in build by including a special SDKs in project definition (like Microsoft.NET.Sdk.Razor). We should do the same and do wasm library only when the project references Microsoft.NET.Sdk.WebAssembly.

The Microsoft.NET.Sdk.WebAssembly lives in SDK and wasi build lives in workload, but we can use UsingMicrosoftNETSdkWebAssembly to check it the wasm SDK being used

Currently Wasm SDK always imports web related SDKs https://github.com/dotnet/sdk/blob/main/src/WasmSdk/Sdk/Sdk.props#L32. We need to add a guard to do it only for browser-wasm. In the meantime we can workaround it by explicitly setting UsingMicrosoftNETSdkStaticWebAssets=true in the csproj.