-
Notifications
You must be signed in to change notification settings - Fork 554
[net6] Fix ILStrip'ed apps to actually work again #13098
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
Conversation
- In a late minute change to the ILStrip PR (dotnet#12563) a change to support XVS support broke execution of Apps that were stripped - Applications were broken because none of the stripped assemblies were actually copied into the bundle - However, the tests still passed, because all assemblies that were there had no IL (zero assemblies total) Now why did this happen? - The stripped assemblies were changed to return via an msbuild Output Element - Output Element can return an Property or ItemGroup, depending if you use the PropertyName or ItemName attributes - Unfortunately I used PropertyName, when I expected an ItemGroup. So I silently had a property created instead. - Thus zero items were added to the list of files to copy into the bundle - Which was undetected as the test did not confirm files were copied in, and manual tests were not run so late into the PR (3 weeks after PR was opened) How was it fixed? - Correctly using ItemName on Output created a valid item group to reference - However, that still failed with an absurdly confusing error: PATH/Microsoft.NET.Publish.targets(277,5): error MSB3024: Could not copy the file FILE to the destination file PATH, because the destination is a folder instead of a file. To copy the source file into a folder, consider using the DestinationFolder parameter instead of DestinationFiles. - After a splunking through netcore targets, I found the metadata on these assemblies references really matters. Without it, they are not processed correctly at all. - Thus, I updated ILStripBase to clone the existing metadata when changing the original assembly reference to the stripped path - Finally, I corrected the test to assert that required files are copied in. I also manually ran our device test.
❌ [PR Build] Tests failed on Build ❌Tests failed on Build. API diff✅ API Diff from stable View API diffView dotnet API diffView dotnet legacy API diffGitHub pagesResults can be found in the following github pages (it might take some time to publish): Test results1 tests failed, 131 tests passed.Failed tests
Pipeline on Agent XAMBOT-1100.BigSur' |
Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
spouliot
left a comment
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.
👍
|
Test failure was good old https://github.com/xamarin/maccore/issues/2443 |
|
/sudo backport release/6.0.1xx-preview10 |
|
Backport Job to branch release/6.0.1xx-preview10 Created! The magic is happening here |
|
Hooray! Backport succeeded! Please see https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=5367047 for more details. |
Fixes: #13094
Now why did this happen?
How was it fixed?