[NativeAOT-LLVM] DotnetJS JSExport fails, when function was defined in a Browser class library

[maxkatz6]

Repro:

1. Create browser class library, that is intended to be reused between Mono and NativeAOT-LLVM. Either .NET 8 or .NET 9.
2. (Optional) Distribute it on nuget.
3. Reference this library in NativeAOT-LLVM browser project.
4. Use getAssemblyExports to execute exported method from JS.

Error message

MONO_WASM: Assert failed: Missing wasm export '_ClassLibrary__GeneratedInitializer__Register_' (for JSExport registration function in assembly 'ClassLibrary.dll') Error: Assert failed: Missing wasm export '_ClassLibrary__GeneratedInitializer__Register_' (for JSExport registration function in assembly 'ClassLibrary.dll')

Repro project:
ClassLibrary-2.zip

^ Note, ClassLibrary doesn't use the same runtime nugets, and is compiled with standard JSExport source generator.

[maxkatz6]

Looks like NativeAOT-LLVM implementation relies on source gen to output [UnmanagedCallersOnly] wrapper. And, I suppose, special msbuild targets to make emscripten see these register-methods.

Is it planned to sync this part with upstream? Or maybe add reflection fallback in NativeAOT-LLVM solution. Otherwise, it doesn't seem possible to reuse class libraries with interop between two browser runtimes.

[maxkatz6]

Actually, the problem is a bit deeper that I thought at first.
Even when class library is compiled with latest NativeAOT-LLVM interop source generators (and I can confirm that ClassLibrary__GeneratedInitializer__Register_ is defined), executable project still doesn't see that function in runtime. Could it be some issue with emscripten msbuild targets?

ClassLibrary.zip

[maxkatz6]

Might be related #2045

[SingleAccretion]

The native compiler works by selecting a set of "root" entities as the starting point: the entry point, and UCO methods with an EntryPoint from assemblies marked UnmanagedEntryPointsAssembly. So, the fix here is to add:

<ItemGroup>
  <UnmanagedEntryPointsAssembly Include="YourClassLibraryAssemblyName" />
</ItemGroup>

Either in the application, or, for NuGets, in the package .props. This is documented here.

Ideally, this would of course be unnecessary, but it is not clear to me yet what the solution would look like.