Mono + dotnet/runtime Migration

[steveisok]

These are the high level sets of tasks / priorities leading up to and after parts of mono are migrated into dotnet/runtime.

Before Migration

• Determine steps needed to enable dotnet/runtime testing for mono
• Enable PR Sync Bot and test

Migration

• Execute mono consolidation script (requires mono merge freeze)
• Merge PR into dotnet/runtime: Add Mono to the repository #1912
• Enable PR Sync Bot

Post Migration

Priority I (Near completion)

• Build MonoVM at the same time as CoreCLR
• Enable LLVM support + binary packages: Add conditional dependency on LLVM packages for Mono #2140
• Adjust, if necessary, helper targets like run-sample run-benchmark: Add RunSample target to mono.proj #2393
• Migrate ios build targets: Add iOS build configurations #33292
• Enable CI for ios: Enable iOS builds on CI  #33688
• Migrate android build targets: Enable android build targets in dotnet/runtime #33687 and Add Android build configurations for Mono/Libraries #33881
• Enable CI for android: Enable android builds on CI #33689
• Runtime packs for ios and android: Ensure correct packaging for iOS and Android #33690

Priority II

• Migrate tvOS build targets: Enable tvOS Build Targets #34461
• Default to LLVM + AOT for device release build: Enable LLVM + AOT for the release build for devices #34693
• Migrate ios test targets : Enable running iOS tests  #33753
• Get ios test targets running on devices / simulators
• Migrate android test targets
• Get android test targets running on devices / simulators
• Migrate wasm build targets: Enable Wasm build targets  #33818
• Migrate wasm test targets
• Meta-package for LLVM dependencies
• Run mono/tests tests and mono/mini tests on MonoVM on CI
• Run MonoVM's soft debugger tests on CI (this will need some coordination with https://github.com/mono/debugger-libs)

[jkotas]

What is PR Sync Bot?

[danmoseley]

Are these worth calling out specifically

• Add build configurations for iOS and Android
• Porting of code into System.Native
• Porting of code into libraries, changing #ifdef to partial classes in many cases
• Add build configuration for Windows desktop (?) and CI (?)

Post migration

• Size measurements, trimming as necessary, infrastructure to protect size.

[marek-safar]

@danmosemsft The goal is to get the build going first. Any implementation changes will come once the infrastructure is in place and working.

[lambdageek]

A few more post migration tasks:

• run mono/tests tests and mono/mini tests on MonoVM on CI
• run MonoVM's soft debugger tests on CI (this will some coordination with https://github.com/mono/debugger-libs)

[akoeplinger]

I just opened the PR that adds Mono to the repo: #1912 :)

[borgdylan]

What will the story be for those running mono on Linux? Would there still be a way to build it and install it via makefiles? Will there be a similar story for .NET 5 as a replacement?

[akoeplinger]

@borgdylan Mono as you know it will stay around as an option, but for .NET 5 the packaging/distribution is a bit different.

[shahid-pk]

is this just port of monovm and aot , which will use .net core's gc . Or is the entire mono runtime along with mono's gc is getting ported here ?
Interested because mono vm and JIT runs in many places where .net core does not and .net core's gc is way better than mono's gc. (my opinion)

[akoeplinger]

It is the entire Mono runtime including Mono's GC (sgen).

[tibel]

Is there a plan to port Mono to use the .NET Core GC?
I would prefer having one garbage collector for only in terms of testing and maintenance.

[jkotas]

Is there a plan to port Mono to use the .NET Core GC?

Xamarin and Blazor are the primary workloads for Mono. CoreCLR GC (as is) is likely a worse option for these workloads than the current Mono GC. We may experiment with it, but the Mono GC is here to stay until we have a data that confirm the .NET Core GC would be a better choice for the primary Mono workloads.

[richlander]

I don't see anything in that list for publishing runtime packs. Is that missing? If so, it seems like it should be added. W/o that, there isn't a user experience.

[jaredpar]

When doing the planning for migrating the mono runtime into the repository there was no cleanly defined user experience. Given that we decided to cut the runtime packs and publishing because there wasn't a clear goal for us to plan around. Instead we decided to separate migrating mono into the runtime and then work on publishing, official builds and packaging once we had a defined scenario to plan that around.

Is that available now for us to look at?

[ghost]

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

[steveisok]

For the most part, I think we're migrated. I think what's left is for 6.0 and beyond.