How to handle Runtime Pack naming when targeting > 1 VM

[steveisok]

I'm moving the question I had in dotnet/designs here as this might be a better place.

With the introduction of the mono vm in .net 5, there is a need to uniquely differentiate the runtime packs. To be clear, this would apply to scenarios where there are > 1 vm's being used (Xamarin.Mac targeting OSX).

To me, it would make sense to just add the vm to the name of the runtime pack. Something like Microsoft.NETCore.App.Runtime.{vm}.{rid}.{version}.nukpg. I'm sure the vm name clash will apply to other scenarios as well.

What's the best way to proceed?

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. Please help me learn by adding exactly one area label.

[ericstj]

@terrajobst @mhutch @dsplaisted @ViktorHofer @jkotas

So the name of the runtime packages is an implementation detail. We should first think about the customer experience.

Do we want to allow independent selection of {vm} or is it something that is just implicit based on the TFM + RID? If the latter, maybe we can just bring TFM into the naming convention, or have the SDK choose a different FrameworkReference based on the TFM. We need not make all TFMs use/build on top of the Microsoft.NETCore.App shared framework. The only place we need the Microsoft.NETCore.App shared framework to be represented is for apps which use hosts that actually leverage that shared framework.

[jkotas]

We have similar problem for CoreCLR single-file: The current plan for single-file CoreCLR runtime pack is to include it in the default CoreCLR runtime pack, but it is wasteful. It results into downloading 10+ MBs of stuff with the runtime pack that you do not need.

Also, we are exploring CoreCLR+framework build optimized for containers where we want to apply different AOT policies that work better for containers. Again, it would be nice to have a option to pack it into a separate runtime pack.

I would make the name Microsoft.NETCore.App.Runtime{.custom}.{rid}.{version}.nukpg where custom can be any identifier that identifies non-default runtime for the given TFM.

User experience:

• The workload-specific SDKs (e.g. Xamarin.Mac SDK) can override default to something else.
• The user .csproj file and the command line can override the default to something else.

[jkotas]

Also, filled #34202 that is somewhat related to this.

[jzabroski]

@ericstj said:

We should first think about the customer experience.

@jkotas said:

I would make the name Microsoft.NETCore.App.Runtime{.custom}.{rid}.{version}.nukpg where custom can be any identifier that identifies non-default runtime for the given TFM.

So, as an open source author, if I want to support users who want to use the Mono runtime, what XML am I going to stick in my .NET SDK csproj? How will my downstream tools like xUnit.net run tests? Or is customer experience here optimizing for the default case and letting people build complex csproj's to support complex requirements?

[terrajobst]

It's not clear to me yet that customers need to chose a specific runtime pack in their project file. As @ericstj said, I would generally expect this to be driven by the TFM. Maybe there are other factors that control that (DEBUG vs RELEASE, AOT vs JIT) but I would generally expect these to be either exposed as settings in the project file or passed as arguments to build/publish and not result in the user having to pick the runtime pack.

The container scenario is an interesting one. For example, let's say we support three different policies A, B, and C. I would expect the project file to look something like this:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <AotPolicy>A</AotPolicy>
  </PropertyGroup>

</Project>

The reason is that we generally want to avoid customers having to pick the full thing with version number because it becomes hard when they upgrade to a later TFM. We learned this with ASP.NET Core where folks used weird combinations of the .NET platform with lower/higher versions of ASP.NET Core packages. That's why we invented things like FrameworkReference which doesn't include a version in the project file.

Implementation wise, I'm fine with the naming convention that @jkotas proposed so long the SDK constructs them by default. Having a global hammer to be able to specify the runtime pack as an escape hatch is also fine, but we should strive hard to avoid this for general experiences. If folks put these names all over the place upgrading will become hard and we'll be looking at weird bug reports where folks combined artifacts across different versions of the platform that were never meant to be used together.

[jzabroski]

Yes, that's what I want to hear. All set.

[dsplaisted]

Folks,

I've got a PR out which adds the mechanism we can use to allow projects to opt into Mono runtime packs. Take a look and let me know what you think.

Once it's merged, we'll need to:

• Add KnownRuntimePack items to describe the available Mono runtime packs
• Add support for a user-facing property to opt into Mono runtime packs, such as UseMonoRuntime

[rolfbjarne]

So from what I understand what's left before the SDK can consume this, is for Mono to add KnownRuntimePack items to describe the available Mono runtime packs?

[dsplaisted]

So from what I understand what's left before the SDK can consume this, is for Mono to add KnownRuntimePack items to describe the available Mono runtime packs?

@rolfbjarne Yes, the KnownRuntimePack items need to be declared somewhere. Additionally, there needs to be a way to opt in to them. You can do this by setting the RuntimePackLabels metadata on the appropriate FrameworkReference item, but we probably want something like a UseMonoRuntime property that's more user-friendly.

Also, here's an explicit link to the PR that added the capability: dotnet/sdk#11824

[akoeplinger]

This is done now. The Mono-based runtime packs use .Mono in the package ID (e.g. Microsoft.NETCore.App.Runtime.Mono.osx-x64) and there's a UseMonoRuntime property you can set in the .csproj that will opt into them by using the RuntimePackLabels metadata.