[Blazor] Have a way to configure dotnet runtime for blazor apps

[maraf]

Current JavaScript runtime API allows to configure various parameters. We should have a way to allow Blazor users to leverage them.

Some of the features are currently configurable through MSBuild (and boot config).

Should we allow Blazor users to interact with JavaScript runtime API directly? aka make dotnet builder visible on Blazor JavaScript api?
Should we have MSBuild (and boot config) alternative for every configuration that is possible in JavaScript api?

[maraf]

cc @MackinnonBuck @javiercn @pavelsavara

[pavelsavara]

I prefer JS API

[javiercn]

@maraf do we have a list?

[pavelsavara]

We have the API, I don't want to duplicate that API as msbuild properties.

[maraf]

@maraf do we have a list?

It's not a complete list, but it includes. For some of them we already have MSBuild properties/items.

• startupMemoryCache (MSBuild property)
• workingDirectory (VFS)
• environmentVariables
• diagnosticTracing
• debugLevel (MSBuild property for Blazor case)
• applicationArguments
• runtimeOptions (MSBuild items)
  • mostly jiterpreter https://github.com/dotnet/runtime/blob/main/src/mono/mono/utils/options-def.h
• browserProfilerOptions
  • enable browser profiler
• aotProfilerOptions
  • where to store AOT profile data
• pthreadPoolSize

We have the API, I don't want to duplicate that API as msbuild properties.

I think that for vanilla wasm app, it's okay to configure the runtime in JS, because you have to deal with the runtime JS anyway. In Blazor, users typically don't have deal with the platform startup. In general I would say that having an MSBuild way to define "everything" that is in the MonoConfig/MonoConfigInternal is benefitial.

[pavelsavara]

In Blazor, users typically don't have deal with the platform startup.

Fair point

[javiercn]

@maraf what would entail to expose whatever is needed to configure the underlying runtime.

Would that be a callback users can register in BlazorWebAssemblyStartOptions? (for example).

[maraf]

@javiercn Yes, to modifying runtime options

export interface WebAssemblyStartOptions {
  loadBootResource(type: WebAssemblyBootResourceType, name: string, defaultUri: string, integrity: string): string | Promise<Response> | null | undefined;
  environment?: string;
  applicationCulture?: string;
+  configureRuntime(builder: DotnetHostBuilder): void;
}

Second part to that is exposing running instance API, so that users can call setModuleImports, getAssemblyExports, etc

export const Blazor: IBlazor = {
  navigateTo,
  registerCustomEventType,
  rootComponents: RootComponentsFunctions,
+  runtime: RuntimeAPI,

  _internal: {
    navigationManager: navigationManagerInternalFunctions,
    domWrapper: domFunctions,
    Virtualize,
    PageTitle,
    InputFile,
    NavigationLock,
    getJSDataStreamChunk: getNextChunk,
    attachWebRendererInterop,
  },
};

@pavelsavara Blazor users can't use JSImport/JSExport currently, because there is not way to set imports or get exports, right?

[pavelsavara]

they could use JSImport with ES6 module.

They could also obtain the runtime by globalThis.getDotnetRuntime(0) for both export/import, that's what we documented.

Adding runtime to IBlazor is better. 👍

Note: globalThis.Blazor is singleton. Meaning you can't have multiple runtimes/blazors right now.

[mkArtakMSFT]

@maraf is this resolved by #49385 ?

[maraf]

No, I'll file a separate PR