Only list supported RIDs for ILCompiler#16545
Conversation
| <ILCompilerSupportedRids Include="@(Net60Crossgen2SupportedRids)" /> | ||
| <Net70ILCompilerSupportedRids Include=" | ||
| linux-arm64; | ||
| linux-musl-x64; |
There was a problem hiding this comment.
Should linux-musl-arm64 be in this list instead?
We are publishing a package for it in .NET 7: https://www.nuget.org/packages/runtime.linux-musl-arm64.Microsoft.DotNet.ILCompiler/7.0.5
There was a problem hiding this comment.
That makes sense to me, assuming we considered it supported. Fixed.
- linux-arm is not supported - linux-musl-arm64 was supported in .NET 7
| win-x64; | ||
| " /> | ||
|
|
||
| <!-- The subset of ILCompiler target RIDs that are officially supported. Should be a subset of |
There was a problem hiding this comment.
Just pointing out - nothing to fix in this PR: These hardcoded lists cause problems for community supported RIDs. You are not introducing this problem and just extending what is here.
There was a problem hiding this comment.
Agreed. I was thinking about what a better long-term solution might look like, especially if the community starts producing RID-specific tools other than ILC. I think to really solve this we will want some extensible mechanism that is as simple as a single PackageReference, but that can automatically pull in dependencies based on the host/target RID.
|
|
||
| <ILCompilerSupportedRids Remove="win-arm" /> | ||
| <!-- The subset of ILCompiler target RIDs that are officially supported. Should be a subset of | ||
| https://github.com/dotnet/runtime/blob/main/src/installer/pkg/projects/Microsoft.DotNet.ILCompiler/ILCompilerRIDs.props --> |
There was a problem hiding this comment.
Would it make sense to add a similar comment to ILCompilerRIDs.props? It might save someone time in the future if we add a new supported config.
This improves the errors when there's no `KnownILCompilerPack` to include more detailed information. There are now separate errors for an unsupported host RID, unsupported target RID, and unsupported TFM (the existing warning). Partial fix for dotnet/runtime#84583. The other piece is in dotnet/installer#16545.
To make this easier to keep in sync (see dotnet/installer#16545).
* Add comment about NativeAot RIDs To make this easier to keep in sync (see dotnet/installer#16545). Co-authored-by: Jan Kotas <[email protected]> --------- Co-authored-by: Jan Kotas <[email protected]>
3 participants
Attempting to publish AOT on an unsupported host, or with an unsupported target RID, will produce an error in the SDK before trying to restore the ILCompiler packages. I think we should use the RID list in
KnownILCompilerPackas the source of truth for what is considered supported. Then with improved error reporting (dotnet/sdk#32943), this will give enough info to the user about why a scenario isn't supported for aot.Failing before restore does mean that advanced users who want to test with unsupported ILC packages need to use a different workaround. Instead of adding a
PackageReference, they'll need something like this: