NativeAOT publish should respect updating FrameworkReference RuntimeFrameworkVersion

[eerhardt]

In Microsoft.Crank and the ASP.NET Benchmarks, we specify a specific .NET runtime version to use using the following code:

https://github.com/dotnet/crank/blob/5e7a8b90f56129d8c23dfa4693bd41deeddc9fc3/src/Microsoft.Crank.Agent/Startup.cs#L3551-L3584

                    if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
                    {
                        project.Root.Add(
                            new XElement("ItemGroup",
                                new XElement("FrameworkReference",
                                    new XAttribute("Update", "Microsoft.AspNetCore.App"),
                                    new XAttribute("RuntimeFrameworkVersion", "$(MicrosoftAspNetCoreAppPackageVersion)")
                                    ),
                                new XElement("FrameworkReference",
                                    new XAttribute("Update", "Microsoft.NETCore.App"),
                                    new XAttribute("RuntimeFrameworkVersion", "$(MicrosoftNETCoreAppPackageVersion)")
                                )
                            )
                        );
                    }
                    else
                    {
                        project.Root.Add(
                            new XElement("ItemGroup",
                                new XElement("FrameworkReference",
                                    new XAttribute("Update", "Microsoft.AspNetCore.App"),
                                    new XAttribute("RuntimeFrameworkVersion", "$(MicrosoftAspNetCoreAppPackageVersion)")
                                    ),
                                new XElement("FrameworkReference",
                                    new XAttribute("Update", "Microsoft.NETCore.App"),
                                    new XAttribute("RuntimeFrameworkVersion", "$(MicrosoftNETCoreAppPackageVersion)")
                                    ),
                                new XElement("FrameworkReference",
                                    new XAttribute("Update", "Microsoft.WindowsDesktop.App"),
                                    new XAttribute("RuntimeFrameworkVersion", "$(MicrosoftWindowsDesktopAppPackageVersion)")
                                    )
                            )
                        );
                    }

For "normal" CoreCLR apps, this is all that is needed to specify which version of the runtime to use.

However, this doesn't work with -p:PublishAot=true. If I add:

  <ItemGroup>
    <FrameworkReference Update="Microsoft.NETCore.App"
                        RuntimeFrameworkVersion="8.0.0-alpha.1.23080.1" />
  </ItemGroup>

To my .csproj, and then inspect the ilc.rsp file that says which version of the runtime is being used, I see:

-r:C:\Users\eerhardt\.nuget\packages\runtime.win-x64.microsoft.dotnet.ilcompiler\8.0.0-alpha.1.23074.4\sdk\System.Private.CoreLib.dll

The PublishAot tooling should respect updating the FrameworkReference, just like other .NET apps do.

Because of this, we don't pick up the latest runtime changes in the ASP.NET AOT benchmarks until the runtime has flown all the way to dotnet/installer. We want to support the same workflow as the rest of the benchmarks, and pick up the latest runtime version as the official build is built.

cc @agocke @MichalStrehovsky @vitek-karas @sebastienros

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

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

Issue Details

---

In Microsoft.Crank and the ASP.NET Benchmarks, we specify a specific .NET runtime version to use using the following code:

https://github.com/dotnet/crank/blob/5e7a8b90f56129d8c23dfa4693bd41deeddc9fc3/src/Microsoft.Crank.Agent/Startup.cs#L3551-L3584

                    if (RuntimeInformation.IsOSPlatform(OSPlatform.Linux))
                    {
                        project.Root.Add(
                            new XElement("ItemGroup",
                                new XElement("FrameworkReference",
                                    new XAttribute("Update", "Microsoft.AspNetCore.App"),
                                    new XAttribute("RuntimeFrameworkVersion", "$(MicrosoftAspNetCoreAppPackageVersion)")
                                    ),
                                new XElement("FrameworkReference",
                                    new XAttribute("Update", "Microsoft.NETCore.App"),
                                    new XAttribute("RuntimeFrameworkVersion", "$(MicrosoftNETCoreAppPackageVersion)")
                                )
                            )
                        );
                    }
                    else
                    {
                        project.Root.Add(
                            new XElement("ItemGroup",
                                new XElement("FrameworkReference",
                                    new XAttribute("Update", "Microsoft.AspNetCore.App"),
                                    new XAttribute("RuntimeFrameworkVersion", "$(MicrosoftAspNetCoreAppPackageVersion)")
                                    ),
                                new XElement("FrameworkReference",
                                    new XAttribute("Update", "Microsoft.NETCore.App"),
                                    new XAttribute("RuntimeFrameworkVersion", "$(MicrosoftNETCoreAppPackageVersion)")
                                    ),
                                new XElement("FrameworkReference",
                                    new XAttribute("Update", "Microsoft.WindowsDesktop.App"),
                                    new XAttribute("RuntimeFrameworkVersion", "$(MicrosoftWindowsDesktopAppPackageVersion)")
                                    )
                            )
                        );
                    }

For "normal" CoreCLR apps, this is all that is needed to specify which version of the runtime to use.

However, this doesn't work with -p:PublishAot=true. If I add:

  <ItemGroup>
    <FrameworkReference Update="Microsoft.NETCore.App"
                        RuntimeFrameworkVersion="8.0.0-alpha.1.23080.1" />
  </ItemGroup>

To my .csproj, and then inspect the ilc.rsp file that says which version of the runtime is being used, I see:

-r:C:\Users\eerhardt\.nuget\packages\runtime.win-x64.microsoft.dotnet.ilcompiler\8.0.0-alpha.1.23074.4\sdk\System.Private.CoreLib.dll

The PublishAot tooling should respect updating the FrameworkReference, just like other .NET apps do.

Because of this, we don't pick up the latest runtime changes in the ASP.NET AOT benchmarks until the runtime has flown all the way to dotnet/installer. We want to support the same workflow as the rest of the benchmarks, and pick up the latest runtime version as the official build is built.

cc @agocke @MichalStrehovsky @vitek-karas @sebastienros

Author:	eerhardt
Assignees:	-
Labels:	untriaged, area-NativeAOT-coreclr
Milestone:	-

[vitek-karas]

@sbomer and @LakshanF as this looks like the package version problem. We will probably have to pick the appropriate version of the ILC package based on the framework version (for Microsoft.NETCore.App). I would hope that SDK will get us the right higher-level framework bits based on the specified versions for them.

[sbomer]

Setting RuntimeFrameworkVersion as an MSBuild property should work - it will apply to ILCompiler (and also R2R), and is the documented way to specify the runtime version: https://learn.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props#runtimeframeworkversion.

I looked a bit at how the metadata on FrameworkReference works. A single FrameworkReference can be associated with multiple KnownRuntimePack, based on the RuntimePackLabels. (More details at dotnet/sdk#11824). Then the runtime pack version is selected according to this logic:
https://github.com/dotnet/sdk/blob/77cb43cab0a8d7ce648c9ce3d9f191b2411a00ac/src/Tasks/Microsoft.NET.Build.Tasks/ProcessFrameworkReferences.cs#L708-L715

However, ILCompiler (and R2R/ILLink) aren't implemented as runtime packs. So to make this get the same version semantics from FrameworkReference, we would need to add some kind of explicit or implicit association between the FrameworkReference and the KnownILCompilerPack, or move the ILCompiler acquisition to something closer to KnownRuntimePack.

[eerhardt]

@sebastienros - is there a reason Crank doesn't use the RuntimeFrameworkVersion MSBuild property?

(Note that Crank also needs to specify the ASP.NET version that is used, which is different than RuntimeFrameworkVersion.)

[sebastienros]

I don't recall but I don't see why it couldn't use RuntimeFrameworkVersion then for the runtime.

[sebastienros]

I tried to set the <RuntimeFrameworkVersion> property to 8.0.0-alpha.1.23076.9 which is a runtime that had a bug in nativeaot (logging, DI related). This bug is now fixed in the latest SDK so I wanted to see if it could use another version of the runtime for the compilation tools.

The issue I am seeing is that it then tries to find a package for Microsoft.NET.ILLink.Tasks with this specific version, but the versioning of this package doesn't seem to match the runtime framework one.

C:\Users\sebros\AppData\Local\Temp\benchmarks-agent\benchmarks-server-54508\xifq2zkg.qg3\benchmarks\src\Goldilocks\Goldilocks.csproj : warning NU1603: Goldilocks depends on Microsoft.NET.ILLink.Tasks (>= 8.0.0-alpha.1.23076.9) but Microsoft.NET.ILLink.Tasks 8.0.0-alpha.1.23076.9 was not found. An approximate best match of Microsoft.NET.ILLink.Tasks 8.0.100-1.22608.1 was resolved.

Available versions for Microsoft.NET.ILLink.Tasks: https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet8/nuget/v3/flat2/Microsoft.NET.ILLink.Tasks/index.json

Available runtime framework versions, including the one specified in the property:
https://pkgs.dev.azure.com/dnceng/public/_packaging/dotnet8/nuget/v3/flat2/Microsoft.NetCore.App.Runtime.win-x64/index.json

[sbomer]

Ah, that is a known issue with the ILLink.Tasks package and will be fixed soon for 8.0 (7.0 will continue to have a similar issue). Until then, @eerhardt's workaround is a fine way to do it.