-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Use implicit package reference for ILC build package #28690
Conversation
- With implicit package reference, the bundled SDK is unused - The target-RID package will be downloaded for the implicit package reference
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.
Thanks for doing this!
Its a great start and we should add the test scenarios for major version changes once the repo is ready. There are 4 different scenarios, and we currently only test the 1st one thoroughly.
- Default: User only specifies PublishAot at publish. All package versions (both ILC build and runtime packages and the .NET Core App Runtime) match and there should not be any versioning issues. We have existing test scenarios for this.
- User explicitly overrides the .NET Core App Runtime version. We need to ensure that all 3 package versions match as above. This is a critical version requirement since previously (without this fix), the bundled ILC build package targets and properties will be used causing versioning issues. This fix should address that, and we need a test case once the repo is ready.
- User explicitly specifies an ILC build package version. We discourage this scenario and only allow it for narrow cases (for example, pick a bug fix in the NativeAOT packages) where the version mismatch with the .NET Core App Runtime version is expected to be minor. We do have a test scenario currently for this but do not comprehensively validate the versions.
- User explicitly overrides the .NET Core App Runtime version and also explicitly specifies an ILC build package version. Not sure what the user scenario here is but treating this as scenario 2 seems reasonable to me. We don’t have a test scenario for this currently.
Thanks @LakshanF. I added some validation of the explicit versions for (3). |
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.
Thanks for adding the explicit ilc path check to the test!
This addresses parts of dotnet/runtime#75468 by removing the bundled ILCompiler bits from the SDK, and instead using implicit PackageReference to import targets that correctly match the ILCompiler package version.
This seems to work fine for all of the 7.0 scenarios we are testing in ci and for my manual tests. I can't add tests targeting 8.0 yet because the repo hasn't updated to enable targeting 8.0 (and I think that is blocked on the templates updating to 8.0).