Don't bundle NativeAOT runtime assets in the ILCompiler package

[jkoritzinsky]

With dotnet/sdk#46611, the .NET SDK will now use the "NativeAOT runtime pack" as the "runtime package" when publishing for NativeAOT. It's not as clean as dotnet/sdk#37872, but it has the same effect on our packaging.

Now that the .NET SDK will always look in the "NativeAOT runtime pack" for .NET 10 and newer, we can do two things:

1. Don't bundle the runtime assets in the rid-specific ILCompiler package.
2. Remove support in the ILCompiler MSBuild targets for the old package layout.

We leave the different properties as-is (ie the split between aotsdk and framework) for usage in our tests.
 
Contributes to #87060

[dotnet-policy-service]

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

[jkotas]

Does this break "building packages" https://github.com/dotnet/runtime/blob/main/docs/workflow/building/coreclr/nativeaot.md#building-packages workflow for using local builds?

[jkoritzinsky]

I need to update those docs to match the changes, but using it should still be possible (if slightly more annoying).

[am11]

Don't bundle the runtime assets in the rid-specific ILCompiler package.

Are they bundled today? I don't see it:

microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/Icon.png
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/runtime.json
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/tools
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/tools/netstandard
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/tools/netstandard/ILCompiler.Build.Tasks.dll
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/tools/netstandard/ILCompiler.Build.Tasks.deps.json
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/.nupkg.metadata
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/microsoft.dotnet.ilcompiler.nuspec
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/microsoft.dotnet.ilcompiler.10.0.0-preview.6.25304.106.nupkg
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/THIRD-PARTY-NOTICES.TXT
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/build
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/build/WindowsAPIs.txt
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/build/Microsoft.NETCore.Native.Unix.targets
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/build/NativeAOT.natstepfilter
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/build/Microsoft.NETCore.Native.Publish.targets
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/build/BuildFrameworkNativeObjects.proj
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/build/Microsoft.DotNet.ILCompiler.SingleEntry.targets
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/build/findvcvarsall.bat
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/build/Microsoft.NETCore.Native.targets
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/build/NativeAOT.natvis
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/build/Microsoft.NETCore.Native.Windows.targets
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/build/Microsoft.DotNet.ILCompiler.props
microsoft.dotnet.ilcompiler/10.0.0-preview.6.25304.106/microsoft.dotnet.ilcompiler.10.0.0-preview.6.25304.106.nupkg.sha512

runtime.${RID}.microsoft.dotnet.ilcompile is already a separate package.

[filipnavara]

runtime.${RID}.microsoft.dotnet.ilcompile is already a separate package.

The problem is cross-compiling where the ILCompiler is on the host platform (eg. osx-arm64) and you are targeting a different platform (eg. ios-arm64). Then you'd get runtime.osx-arm64.microsoft.dotnet.ilcompiler with all the SDK assets that are unused because they are taken from the target pack for ios-arm64.

[jkotas]

This will impact number of places outside this repo that reference specific NAOT version via package reference. For example:

https://github.com/dotnet/dotnet/blob/main/src/aspnetcore/eng/tools/GenerateFiles/Directory.Build.targets.in#L60-L62
https://github.com/dotnet/BenchmarkDotNet/blob/master/src/BenchmarkDotNet/Toolchains/NativeAot/Generator.cs#L174-L175
https://github.com/aspnet/Benchmarks/blob/main/build/nativeaot-scenarios.yml#L40-L56

Is there really no way to get SDK to add the matching PackageDownload implicitly so that we do not have to chase down all these places or debug issues caused by mismatched versions between the two lines?

[jkoritzinsky]

The main problem is the ILCompiler targets exist in dotnet/runtime.

I think I can figure out a way to get this working in dotnet/sdk (introducing a new property that will likely work cleaner anyway).

I'll put out a PR to dotnet/sdk after I get back.

[jkoritzinsky]

Came back to look at this again, and it looks like we don't need the separate PackageDownload item. I must have added that when iterating on tests and not realized it's not needed. I'll update this PR.

I expect the failures here to be fixed when dotnet/dotnet#1268 gets in and flows back.