Runtime: [mono] Unify bundling support in the runtime

[lambdageek]

The MonoVM runtime's loader has a notion of bundles. It is used by mkbundle on desktops in mono/mono, and by our WebAssembly target in dotnet/runtime. Additionally Xamarin.Android uses our embedding API to hook into the loader and to support loading assemblies from the APK without extracting them to separate files essentially introducing a third form of bundling.

It would be nice to refactor the bundling support to separate the loading logic from the code responsible for managing the physical storage of the resources in the bundle. The logic of loading (of managed assemblies, resources, native libraries, etc) could be unified across desktop/wasm/andrioid. The physical storage used to package the resources would be specific to the target.

One of the main benefits would be a unified loading algorithm. Which means that for users their WASM and XA and desktop apps will behave the same. For us it would make it easier to test the loader - we could test WASM and XA behavior with desktop bundles, for example.

[msftbot[bot]]

Tagging subscribers to this area: @CoffeeFlux
See info in area-owners.md if you want to be subscribed.

[jkotas]

CoreCLR also supports bundling with /p:PublishSingleFile=true. It would be nice to consider it in the unification. For example, can the bundler tool/logic be shared between CoreCLR and Mono?

[jkotas]

cc @agocke @vitek-karas

[CoffeeFlux]

There are some fundamental differences in how our single-file currently operates, but long-term unification for the bundler tool would be nice since there's little desire on our end to perpetually maintain two separate tools.

I believe our bundler works by loading assemblies into memory from the executable and registering the resulting images, and then unpacking native libraries to disk when appropriate and registering that location with the runtime. As I understand it, this is similar to one of the possible modes of operation for the CoreCLR bundler.

A couple differences I know offhand: currently we register bundled assemblies into a flat namespace rather than a hierarchical one, and then separately register satellite assemblies in the same manner but with the culture specified. We support extending the list of bundled assemblies we register with the runtime, as we use this to enable delayed loading in the browser. I don't believe this is relevant for desktop single-file, and there are other ways to solve that problem in the browser, but it has to be addressed somehow.