-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove ILCompiler package reference #107583
Conversation
It doesn't look like we need the newest version of the package anymore. This configuration (using the package instead of the SDK version) can be dangerous because it causes a split between the version built against vs. the version AOT'd against.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you!
Tagging subscribers to this area: @hoyosjs |
Fixes #106740? |
@@ -18,11 +18,6 @@ | |||
<SuppressGenerateILCompilerExplicitPackageReferenceWarning>true</SuppressGenerateILCompilerExplicitPackageReferenceWarning> | |||
</PropertyGroup> | |||
|
|||
<ItemGroup Condition="'$(UseNativeAotForComponents)' == 'true'"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We may want to keep this around and condition it on MicrosoftDotNetILCompilerVersion
being set. It is likely that we will need to take newer ILC that what's in SDK at some point in future again to take a critical fix temporarily.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(We are on similar plan with Roslyn: We use Roslyn from SDK in steady state, but we may use a newer one temporarily.)
Is this going to expose us to #105441 in more places until we update the SDK to RC1? (We should not block this PR on this - just making sure that it does not come as a surprise.) |
Co-authored-by: Jan Kotas <jkotas@microsoft.com>
/backport to release/9.0 I think this puts us in a better place for servicing than where we currently are |
Started backporting to release/9.0: https://github.com/dotnet/runtime/actions/runs/10836223086 |
@agocke backporting to release/9.0 failed, the patch most likely resulted in conflicts: $ git am --3way --empty=keep --ignore-whitespace --keep-non-patch changes.patch
Applying: Remove ILCompiler package reference
Using index info to reconstruct a base tree...
M eng/Versions.props
Falling back to patching base and 3-way merge...
Auto-merging eng/Versions.props
Applying: Respond to PR comments
Applying: Move ILCompiler overrides to the top level in liveBuilds
Applying: Update eng/Versions.props
error: sha1 information is lacking or useless (eng/Versions.props).
error: could not build fake ancestor
hint: Use 'git am --show-current-patch=diff' to see the failed patch
hint: When you have resolved this problem, run "git am --continue".
hint: If you prefer to skip this patch, run "git am --skip" instead.
hint: To restore the original branch and stop patching, run "git am --abort".
hint: Disable this message with "git config advice.mergeConflict false"
Patch failed at 0004 Update eng/Versions.props
Error: The process '/usr/bin/git' failed with exit code 128 Please backport manually! |
@agocke an error occurred while backporting to release/9.0, please check the run log for details! Error: git am failed, most likely due to a merge conflict. |
It doesn't look like we need the newest version of the package anymore. This configuration (using the package instead of the SDK version) can be dangerous because it causes a split between the version built against vs. the version AOT'd against.
It doesn't look like we need the newest version of the package anymore. This configuration (using the package instead of the SDK version) can be dangerous because it causes a split between the version built against vs. the version AOT'd against.
It doesn't look like we need the newest version of the package anymore. This configuration (using the package instead of the SDK version) can be dangerous because it causes a split between the version built against vs. the version AOT'd against.