Host packages should not use runtime.json restore infrastructure

[ViktorHofer]

The host packages still use runtime.json which was the mechanism to define RID based package dependencies in the .NET Core 2.x era. That feature was never publicly exposed by NuGet and is discussed to be removed in NET 6. For more details see NuGet/Home#5862.

There are alternatives to runtime.json, i.e.:

• KnownFrameworkPackage with known RIDs
• A single package with multiple RID based folders (bigger package, but easier to maintain)
• Dead ending the package if it isn't supposed to be used anymore.

dotnet/sdk still consumes the meta package via the runtime.json mechanism which should be considered when switching to a different restore mechanism.

Host packages:

• https://www.nuget.org/packages/Microsoft.NETCore.DotNetHostPolicy/
• https://www.nuget.org/packages/Microsoft.NETCore.DotNetHostResolver/
• https://www.nuget.org/packages/Microsoft.NETCore.DotNetAppHost/
• https://www.nuget.org/packages/Microsoft.NETCore.DotNetHost/

cc @agocke @vitek-karas @ericstj

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke
See info in area-owners.md if you want to be subscribed.

Issue Details

---

The host packages still use runtime.json which was the mechanism to define RID based package dependencies in the .NET Core 2.x era. That feature was never publicly exposed by NuGet and is discussed to be removed in NET 6. For more details see NuGet/Home#5862.

There are alternatives to runtime.json, i.e.:

• KnownFrameworkPackage with known RIDs
• A single package with multiple RID based folders (bigger package, but easier to generate and maintain)
• Dead ending the package if it isn't supposed to be used anymore.

cc @agocke @vitek-karas @ericstj

Author:	ViktorHofer
Assignees:	-
Labels:	area-Host
Milestone:	6.0.0

[jkoritzinsky]

The single-package option will require us to add another “join” job like the CrossOS DAC job to get all the artifacts in one place.

[ericstj]

IMHO we should just deprecate the runtime.json and make the only method of consumption be SDK and have it work the same way as runtime packs.

dotnet/sdk still consumes the meta package via the runtime.json mechanism

Is this just the internal repo transport or does it show up in the actual product?

[ViktorHofer]

Is this just the internal repo transport or does it show up in the actual product?

It's not exposed in the product, it's just on the consumption side: https://github.com/dotnet/sdk/blob/0d50c13812b626999aef1853bf23295f38287807/src/Resolvers/Microsoft.DotNet.MSBuildSdkResolver/Microsoft.DotNet.MSBuildSdkResolver.csproj#L58. Some tests as well in the sdk repo.

[ViktorHofer]

IMHO we should just deprecate the runtime.json and make the only method of consumption be SDK and have it work the same way as runtime packs.

Can you please share some more information on the work necessary for that?

[ericstj]

This stuff: https://github.com/dotnet/installer/blob/944ec2eb293e807d5235439ca0186d9725856beb/src/redist/targets/GenerateBundledVersions.targets#L100-L120
Then the SDK consuming that and generating PackageDownloads, then manually probing the downloaded directory to raise the assets.

Essentially what you said above: KnownFrameworkPackage with known RIDs.

For any internal consumption we might need to see what the usage is to find a suitable replacement. Might be leveraging those targets in the SDK which compute the right RID-specific package. Might be just referencing everything and let nuget choose. The host isn't so big, so referencing everything isn't such a huge burden.

A single package with multiple RID based folders (bigger package, but easier to maintain)

Another alternative to this is meta-package with normal references that apply exclusively (see runtime.native.System.IO.Ports).

[ViktorHofer]

Another alternative to this is meta-package with normal references that apply exclusively (see runtime.native.System.IO.Ports).

I prefer any option that doesn't require a join job (as Jeremy commented above #49137 (comment)).

Essentially what you said above: KnownFrameworkPackage with known RIDs.

Ok that needs closer inspection. If we add Known items to the defaultversions generated file, doesn't that mean, that the packages will always be downloaded? Anyway, someone will need to take a look and make a switch.

[ViktorHofer]

When doing that it would also be good to apply two code clean-ups:

• Change naming from runtime.* to <PackageId>.Runtime.<RID> as other runtime framework packages
• Move off from the four pkgprojs to .proj ones and use the NuGet Pack Task instead.

[ericstj]

I prefer any option that doesn't require a join job

Not suggesting a join. Suggesting meta-package that "knows" the id's and versions of child packages. Essentially same as we do today but put the dependencies in nuspec instead of runtime.json.

[omajid]

cc @tmds

[glopesdev]

Essentially same as we do today but put the dependencies in nuspec instead of runtime.json.

@ericstj Is there a way to specify RID-specific dependencies in nuspec, to get the same download optimizations that are possible with runtime.json?

[ericstj]

No, it's not possible. NuGet/Home#1660 dotnet/sdk#4552

[ViktorHofer]

cc @elinor-fung, @agocke

With f76045c, the remaining host package that still uses the runtime.json infrastructure is Microsoft.NETCore.DotNetAppHost.

Related: #49233, #75966

Unfortunately another package got added into the installer/pkg umbrella which depends on this infra: https://github.com/dotnet/runtime/tree/main/src/installer/pkg/projects/Microsoft.DotNet.ILCompiler.

After both projects got converted to NuGet Pack task based ones, we will finally be able to delete all the ancient infrastructure around supporting runtime.json based packages under src/installer.

[agocke]

Is this done? I think the ILCompiler runtimejson is gone, I don't see one for DotNetAppHost either.

[jkotas]

I still see runtime.json in https://nuget.info/packages/Microsoft.DotNet.ILCompiler/9.0.0-preview.6.24327.7. What's the package you have looked at?

This was recently discussed in #102908 . We have removed runtime.json from bundled source built ILCompiler packages, but kept it for regular ILCompiler package.

[agocke]

I was looking at the source code and misread the change to be the other direction (we only include runtime.json in source build).

OK, I'll keep this around.