Investigate if the Mono specific verticals for which a non Mono specific vertical with the same RID exists can be removed

[ViktorHofer]

Examples:

• https://github.com/dotnet/dotnet/blob/96c9d4a0e3a67edfb5a2a8653488dbe0b64f1b70/src/installer/eng/pipelines/templates/stages/vmr-build.yml#L792-L803
• https://github.com/dotnet/dotnet/blob/96c9d4a0e3a67edfb5a2a8653488dbe0b64f1b70/src/installer/eng/pipelines/templates/stages/vmr-build.yml#L768-L778
• https://github.com/dotnet/dotnet/blob/96c9d4a0e3a67edfb5a2a8653488dbe0b64f1b70/src/installer/eng/pipelines/templates/stages/vmr-build.yml#L817-L828
• https://github.com/dotnet/dotnet/blob/96c9d4a0e3a67edfb5a2a8653488dbe0b64f1b70/src/installer/eng/pipelines/templates/stages/vmr-build.yml#L700-L710

Ideally runtime packs for all runtimes (coreclr, mono and nativeaot) are produced in a single vertical.

cc @directhex @akoeplinger

[ViktorHofer]

@jkoritzinsky do you know if we already produce runtime packs for all runtimes by default? I assume runtime's official build currently also has separate Mono legs?

[jkoritzinsky]

We need separate legs for targets where we have more than one of CoreCLR, NativeAOT, and Mono as we use the same sfxproj project files to define Microsoft.NETCore.App and we use the same code in many places to put the runtime files where expected for various layout (and testing) scenarios. We'd need to duplicate quite a bit of our infrastructure to handle building CoreCLR and Mono packs in the same build for the same RID.

[ViktorHofer]

We already build the Mono runtime, including repo tasks for it by default. I think it's just the sfxprojs that currently don't get produced, right?

The plan is to not have separate verticals for NativeAOT which makes me wonder if we need to change the sfxproj infrastructure anyway to allow different runtime builds in one build.

from @agocke

NativeAOT uses the same runtime bits as CoreCLR, and the libraries are almost identical minus a few special cases (like CoreLib). We could probably reduce the special cases to almost zero, so it's basically 12 managed binaries, and that's going to be really, really fast to build

[jkoritzinsky]

In terms of shipping code, it's just sfxproj projects and how they pick up runtime bits. We can duplicate the sfxproj projects to allow us to build both CoreCLR and Mono for the sfxproj projects, but I'd want to make sure we consider the local dev experience (where we'd never build them twice) and also how we flow the assets. Maybe we can build the same projects twice (one for each RuntimeFlavor) and avoid duplicating too much.

[ViktorHofer]

I see that NativeAOT builds a bit differently and uses the pkgproj infra instead of the sfxproj one.

Maybe we can build the same projects twice (one for each RuntimeFlavor) and avoid duplicating too much.

Yes, I think that would the preferred option. We would need to make sure that the (base)intermediateoutputpath and baseoutputpath encode the runtimeflavor so that we don't cause restore or incremental build issues.

I'd want to make sure we consider the local dev experience (where we'd never build them twice)

Locally when invoking build.cmd or build.sh, both runtimes already get built by default. If only sfxprojs packages for runtime get created today then that sounds to me more like an infrastructure issues than an intentional design point. As an example, other nuget packages for coreclr and mono already get created, it's just the sfxproj nuget packages that don't get created for both runtimes.

[akoeplinger]

Yeah I think the issue is mostly the packaging projects. We already need to make hacky workarounds to build the runtime packs correctly (search for BuildNativeAotRuntimePack in the runtime repo), it'd be nice to clean all of that up so that we build to distinct paths for all runtime flavors.