[dotnet] Work around an expectation mismatch between ILLink and library projects. Fixes #19037. #19049
Conversation
…ry projects. Fixes xamarin#19037. ILLink doesn't handle library projects the way we need: the library is automatically treated as a root assembly, with the entry point as the root. This doesn't work, because library projects don't have an entry point. In earlier versions of .NET (and Xamarin), we'd solved this by a custom linker step that would manually root everything that needed to be rooted, but that doesn't work anymore because we hit this sanity check in ILLink: > ILLink : error IL1034: Root assembly 'MyExtension, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' does not have entry point. Technically this happens because the library project is configured as a root assembly, where the entry point is the root point (and in that regards the sanity check is rather sane). The best solution would be if we could just treat the library assembly as any other assembly, and manually root it in our custom linker steps - but the custom linker step we have for this kind of rooting will only iterate over types in assemblies that are already marked somehow, and that's not necessarily the case for app extension projects - the end result is that the entire app extension assembly is linked away. A close runner-up as the second best solution is to provide the API that needs to be rooted as an xml file to the linker. This works, but we currently don't have the infrastructure in the code to generate this xml file before running the linker (it would be a rather major undertaking). This work is tentatively scheduled for .NET 9 (xamarin#17693). So I went for the third option: set RootMode="Library" for the library assembly. I'm not sure exactly what that means ILLink will mark, but as long as _anything_ is marked, our custom linker step will run. This seems like an acceptable workaround until we can implement the previous solution. Fixes xamarin#19037.
💻 [CI Build] Windows Integration Tests passed 💻✅ All Windows Integration Tests passed. Pipeline on Agent |
💻 [PR Build] Tests on macOS M1 - Mac Big Sur (11.5) passed 💻✅ All tests on macOS M1 - Mac Big Sur (11.5) passed. Pipeline on Agent |
💻 [PR Build] Tests on macOS M1 - Mac Ventura (13.0) passed 💻✅ All tests on macOS M1 - Mac Ventura (13.0) passed. Pipeline on Agent |
✅ API diff for current PR / commitLegacy Xamarin (No breaking changes)
NET (empty diffs)
✅ API diff vs stableLegacy Xamarin (No breaking changes).NET (No breaking changes)ℹ️ Generator diffGenerator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes) Pipeline on Agent |
📚 [PR Build] Artifacts 📚Packages generatedView packagesPipeline on Agent |
This comment has been minimized.
This comment has been minimized.
🔥 [CI Build] Test results 🔥Test results❌ Tests failed on VSTS: simulator tests 0 tests crashed, 7 tests failed, 225 tests passed. Failures❌ monotouch tests [attempt 2]
Html Report (VSDrops) Download Successes✅ bcl: All 69 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
|
Test failures are unrelated (https://github.com/xamarin/maccore/issues/2630). |
ILLink doesn't handle library projects the way we need: the library is
automatically treated as a root assembly, with the entry point as the root.
This doesn't work, because library projects don't have an entry point.
In earlier versions of .NET (and Xamarin), we'd solved this by a custom linker
step that would manually root everything that needed to be rooted, but that
doesn't work anymore because we hit this sanity check in ILLink:
Technically this happens because the library project is configured as a root
assembly, where the entry point is the root point (and in that regards the
sanity check is rather sane).
The best solution would be if we could just treat the library assembly as any
other assembly, and manually root it in our custom linker steps - but the
custom linker step we have for this kind of rooting will only iterate over
types in assemblies that are already marked somehow, and that's not
necessarily the case for app extension projects - the end result is that the
entire app extension assembly is linked away.
A close runner-up as the second best solution is to provide the API that needs
to be rooted as an xml file to the linker. This works, but we currently don't
have the infrastructure in the code to generate this xml file before running
the linker (it would be a rather major undertaking). This work is tentatively
scheduled for .NET 9 (#17693).
So I went for the third option: set RootMode="Library" for the library
assembly. I'm not sure exactly what that means ILLink will mark, but as long
as anything is marked, our custom linker step will run. This seems like an
acceptable workaround until we can implement the previous solution.
Fixes #19037.