ILCompiler.pkgproj: remove 'runtime.json' when DotNetBuildSourceOnly.

[tmds]

Contributes to dotnet/source-build#1215

@dsplaisted @baronfel @ViktorHofer @jkotas ptal

cc @omajid

[tmds]

This depends on dotnet/arcade#14805.

[ViktorHofer]

@ericstj can you please take a look? (This is about pkgproj infra)

[ericstj]

Can we just remove this completely? We shouldn't be relying on runtime.json anywhere anymore. We removed that from the product in 2.0. Anything that needs support like this should have an SDK doing the package selection.

[dsplaisted]

Can we just remove this completely? We shouldn't be relying on runtime.json anywhere anymore. We removed that from the product in 2.0. Anything that needs support like this should have an SDK doing the package selection.

Per conversation in dotnet/source-build#1215, it sounds like using a PackageReference to Microsoft.DotNet.ILCompiler is still supported, and for that scenario to work the runtime.json needs to be there to acquire the RID-specific ILCompiler package.

[dotnet-policy-service]

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

[jkotas]

Can we just remove this completely? We shouldn't be relying on runtime.json anywhere anymore. We removed that from the product in 2.0. Anything that needs support like this should have an SDK doing the package selection.

Per conversation in dotnet/source-build#1215, it sounds like using a PackageReference to Microsoft.DotNet.ILCompiler is still supported, and for that scenario to work the runtime.json needs to be there to acquire the RID-specific ILCompiler package.

We need a simple way to override the default version of Microsoft.DotNet.ILCompiler. It is frequently used to trouble shoot issues and to provide workarounds for customers. Microsoft.DotNet.ILCompiler package reference works perfectly for this purpose today.

Can we make it work equally well without runtime.json?

[dsplaisted]

We need a simple way to override the default version of Microsoft.DotNet.ILCompiler. It is frequently used to trouble shoot issues and to provide workarounds for customers. Microsoft.DotNet.ILCompiler package reference works perfectly for this purpose today.

Can we make it work equally well without runtime.json?

Rather than a PackageReference, I think you could do this:

<ItemGroup>
    <KnownILCompilerPack Update="Microsoft.DotNet.ILCompiler" ILCompilerPackVersion="8.0.5"/>
</ItemGroup>

I think this would work with an ILCompiler package without the runtime.json and the logic we already have in the SDK today.

[jkotas]

I dislike that we would be moving from PackageReference to SDK magic. I think PackageReferences are much cleaner and easier to understand from user point of view.

If we agree that the SDK magic is right way to go, I guess it can work. @agocke @MichalStrehovsky Do you see any problems with it? We would have to update the docs and chase down all places that depend on the current behavior. It may be best to do it separately from enabling source build for native AOT toolchain.

We shouldn't be relying on runtime.json anywhere anymore. We removed that from the product in 2.0. Anything that needs support like this should have an SDK doing the package selection.

runtime.json may not be officially documented, but it is the only way we have to provide good user experience for nuget packages with (large) platform-specific binaries. Both our and 3rd party packages depend on it for this reason.

[MichalStrehovsky]

If we agree that the SDK magic is right way to go, I guess it can work. @agocke @MichalStrehovsky Do you see any problems with it? We would have to update the docs and chase down all places that depend on the current behavior. It may be best to do it separately from enabling source build for native AOT toolchain.

I don't see an issue other than what Jan already wrote. If we do this change, we'll need to consider KnownILCompilerPack and ILCompilerPackVersion basically a "public API" so that we don't have to redo chasing down all places that depend on this or mention this next time it changes. If we're doing a break, it would be ideal if this mechanism is standardized with other tools that ship in NuGets - ILLink and crossgen off the top of my head, so that we know what we have is going to last.

@sbomer is there an existing mechanism when a user needs to pick up a new/specific version of ILLink if they need a different one from the one that ships with the SDK?

[jkotas]

it would be ideal if this mechanism is standardized with other tools that ship in NuGets - ILLink and crossgen off the top of my head

There are number of other tools. For example, you can reference a specific Roslyn version too - via a package reference. I think the only meaningful standard are package references. Everything else are bespoke solutions that won't ever be consistent across the ecosystem.

[sbomer]

<ItemGroup>
    <KnownILCompilerPack Update="Microsoft.DotNet.ILCompiler" ILCompilerPackVersion="8.0.5"/>
</ItemGroup>

We should be careful with this - it updates the ILC version used for all TFMs. To update it for just one TFM you'd have to do something like this:

<ItemGroup>
    <KnownILCompilerPack
        Update="@(KnownILCompilerPack->WithMetadataValue('TargetFramework', 'net8.0'))"
        ILCompilerPackVersion="8.0.5" />
</ItemGroup>

@sbomer is there an existing mechanism when a user needs to pick up a new/specific version of ILLink if they need a different one from the one that ships with the SDK?

It's the same as for ILCompiler: the user can add a PackageReference, which works but produces a warning:

warning : Delete explicit 'Microsoft.NET.ILLink.Tasks' package reference in your project file to avoid versioning problems.

The same trick (updating KnownILLinkPack) works as well.

I don't think updating the Known*Packs is a good user experience. It works in a pinch, but if we care about the user experience in this scenario I would not recommend relying on this mechanism.

[dsplaisted]

It may be best to do it separately from enabling source build for native AOT toolchain.

I also think it would be best to treat these two things as separate - ie enabling native AOT on source-built SDKs, and removing the runtime.json from Microsoft.DotNet.ILCompiler (and other similar packages, if there are any).