[dotnet] Ensure any trimmer components are restored properly. #17227
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
.NET 8 will load the ILLink component based on the target framework of the project file - so if .NET 8 is building a net7.0-ios app, the build will restore and use the ILLink component from .NET 7. There is a problem however: * The inclusion of the ILLink component is dpendent on the PublishTrimmed property - if PublishTrimmed is true, then the ILLink component is restored (which makes sense, why restore it if it's not going to be used?). * We always PublishTrimmed, because the linker must always be executed for our projects. So far so good - we can just always enable PublishTrimmed, right? * Nope, when building on Windows, we only enable PublishTrimmed when connected to a Mac, because that's where the ILLink target must be executed (and if we're not connected to a Mac, we can't run the ILLink target, and things fall apart - so just disable PublishTrimmed in that, since it won't work anyway). * Early on in the build we have no idea if we're connected to a Mac or not, which means we can only enable PublishTrimmed in a target, and not as an early-on default value. This is *way* to late for the ILLink component, which needs PublishTrimmed set quite early in the build process. * Fortunately, the ILLink inclusion is actually gated on a different variable (_IsTrimmingEnabled) - which is initialized from PublishTrimmed if it's not set. So the way out here is to set _IsTrimmingEnabled early enough, and now the ILLink component is included and restored. * The additional hurdle is that we need to set _IsTrimmingEnabled in our .NET 6 and .NET 7 workloads as well, it's not enough to set it in our .NET 8 workload (which isn't even loaded when building an earlier TFM).
Member
Author
|
CC @jonathanpeppers you might need this for Android as well. |
sbomer
approved these changes
Jan 13, 2023
Collaborator
💻 [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 |
Collaborator
Collaborator
✅ 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 is empty Pipeline on Agent |
haritha-mohan
approved these changes
Jan 14, 2023
Collaborator
🔥 [CI Build] Test results 🔥Test results❌ Tests failed on VSTS: simulator tests 0 tests crashed, 1 tests failed, 222 tests passed. Failures❌ framework testsDetails
Html Report (VSDrops) Download Successes✅ bcl: All 69 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
Member
I'll keep an eye on this, this sounds like we would restore this ILLink package for Release and not Debug. Android does not use the trimmer for Debug builds. I'm not sure if this will cause an issue or not, we do set |
Member
Author
|
Test failure is unrelated (https://github.com/xamarin/maccore/issues/2450). |
Member
Author
|
/sudo backport release/6.0.4xx |
Member
Author
|
/sudo backport release/6.0.4xx-xcode14.2 |
Member
Author
|
/sudo backport release/6.0.4xx-xcode14.1 |
Member
Author
|
/sudo backport release/7.0.1xx |
Member
Author
|
/sudo backport release/7.0.1xx-xcode14.2 |
Collaborator
|
Backport Job to branch release/6.0.4xx Created! The magic is happening here |
Collaborator
|
Backport Job to branch release/6.0.4xx-xcode14.2 Created! The magic is happening here |
Collaborator
|
Backport Job to branch release/7.0.1xx Created! The magic is happening here |
Collaborator
|
Backport Job to branch release/6.0.4xx-xcode14.1 Created! The magic is happening here |
Collaborator
|
Backport Job to branch release/7.0.1xx-xcode14.2 Created! The magic is happening here |
Member
Author
|
/sudo backport release/7.0.2xx |
Collaborator
|
Backport Job to branch release/7.0.2xx Created! The magic is happening here |
This was referenced Jan 16, 2023
Collaborator
|
Hooray! Backport succeeded! Please see https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=7199082 for more details. |
This was referenced Jan 16, 2023
Merged
Collaborator
|
Hooray! Backport succeeded! Please see https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=7199084 for more details. |
Collaborator
|
Hooray! Backport succeeded! Please see https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=7199085 for more details. |
Collaborator
|
Hooray! Backport succeeded! Please see https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=7199086 for more details. |
Collaborator
|
Hooray! Backport succeeded! Please see https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=7199083 for more details. |
Collaborator
|
Hooray! Backport succeeded! Please see https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=7199088 for more details. |
rolfbjarne
added a commit
that referenced
this pull request
Jan 17, 2023
… properly. (#17255) .NET 8 will load the ILLink component based on the target framework of the project file - so if .NET 8 is building a net7.0-ios app, the build will restore and use the ILLink component from .NET 7. There is a problem however: * The inclusion of the ILLink component is dpendent on the PublishTrimmed property - if PublishTrimmed is true, then the ILLink component is restored (which makes sense, why restore it if it's not going to be used?). * We always PublishTrimmed, because the linker must always be executed for our projects. So far so good - we can just always enable PublishTrimmed, right? * Nope, when building on Windows, we only enable PublishTrimmed when connected to a Mac, because that's where the ILLink target must be executed (and if we're not connected to a Mac, we can't run the ILLink target, and things fall apart - so just disable PublishTrimmed in that, since it won't work anyway). * Early on in the build we have no idea if we're connected to a Mac or not, which means we can only enable PublishTrimmed in a target, and not as an early-on default value. This is *way* to late for the ILLink component, which needs PublishTrimmed set quite early in the build process. * Fortunately, the ILLink inclusion is actually gated on a different variable (_IsTrimmingEnabled) - which is initialized from PublishTrimmed if it's not set. So the way out here is to set _IsTrimmingEnabled early enough, and now the ILLink component is included and restored. * The additional hurdle is that we need to set _IsTrimmingEnabled in our .NET 6 and .NET 7 workloads as well, it's not enough to set it in our .NET 8 workload (which isn't even loaded when building an earlier TFM). Backport of #17227 Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
rolfbjarne
added a commit
that referenced
this pull request
Jan 17, 2023
…e restored properly. (#17254) .NET 8 will load the ILLink component based on the target framework of the project file - so if .NET 8 is building a net7.0-ios app, the build will restore and use the ILLink component from .NET 7. There is a problem however: * The inclusion of the ILLink component is dpendent on the PublishTrimmed property - if PublishTrimmed is true, then the ILLink component is restored (which makes sense, why restore it if it's not going to be used?). * We always PublishTrimmed, because the linker must always be executed for our projects. So far so good - we can just always enable PublishTrimmed, right? * Nope, when building on Windows, we only enable PublishTrimmed when connected to a Mac, because that's where the ILLink target must be executed (and if we're not connected to a Mac, we can't run the ILLink target, and things fall apart - so just disable PublishTrimmed in that, since it won't work anyway). * Early on in the build we have no idea if we're connected to a Mac or not, which means we can only enable PublishTrimmed in a target, and not as an early-on default value. This is *way* to late for the ILLink component, which needs PublishTrimmed set quite early in the build process. * Fortunately, the ILLink inclusion is actually gated on a different variable (_IsTrimmingEnabled) - which is initialized from PublishTrimmed if it's not set. So the way out here is to set _IsTrimmingEnabled early enough, and now the ILLink component is included and restored. * The additional hurdle is that we need to set _IsTrimmingEnabled in our .NET 6 and .NET 7 workloads as well, it's not enough to set it in our .NET 8 workload (which isn't even loaded when building an earlier TFM). Backport of #17227 Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
rolfbjarne
added a commit
that referenced
this pull request
Jan 17, 2023
…e restored properly. (#17253) .NET 8 will load the ILLink component based on the target framework of the project file - so if .NET 8 is building a net7.0-ios app, the build will restore and use the ILLink component from .NET 7. There is a problem however: * The inclusion of the ILLink component is dpendent on the PublishTrimmed property - if PublishTrimmed is true, then the ILLink component is restored (which makes sense, why restore it if it's not going to be used?). * We always PublishTrimmed, because the linker must always be executed for our projects. So far so good - we can just always enable PublishTrimmed, right? * Nope, when building on Windows, we only enable PublishTrimmed when connected to a Mac, because that's where the ILLink target must be executed (and if we're not connected to a Mac, we can't run the ILLink target, and things fall apart - so just disable PublishTrimmed in that, since it won't work anyway). * Early on in the build we have no idea if we're connected to a Mac or not, which means we can only enable PublishTrimmed in a target, and not as an early-on default value. This is *way* to late for the ILLink component, which needs PublishTrimmed set quite early in the build process. * Fortunately, the ILLink inclusion is actually gated on a different variable (_IsTrimmingEnabled) - which is initialized from PublishTrimmed if it's not set. So the way out here is to set _IsTrimmingEnabled early enough, and now the ILLink component is included and restored. * The additional hurdle is that we need to set _IsTrimmingEnabled in our .NET 6 and .NET 7 workloads as well, it's not enough to set it in our .NET 8 workload (which isn't even loaded when building an earlier TFM). Backport of #17227 Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
rolfbjarne
added a commit
that referenced
this pull request
Jan 17, 2023
… properly. (#17250) .NET 8 will load the ILLink component based on the target framework of the project file - so if .NET 8 is building a net7.0-ios app, the build will restore and use the ILLink component from .NET 7. There is a problem however: * The inclusion of the ILLink component is dpendent on the PublishTrimmed property - if PublishTrimmed is true, then the ILLink component is restored (which makes sense, why restore it if it's not going to be used?). * We always PublishTrimmed, because the linker must always be executed for our projects. So far so good - we can just always enable PublishTrimmed, right? * Nope, when building on Windows, we only enable PublishTrimmed when connected to a Mac, because that's where the ILLink target must be executed (and if we're not connected to a Mac, we can't run the ILLink target, and things fall apart - so just disable PublishTrimmed in that, since it won't work anyway). * Early on in the build we have no idea if we're connected to a Mac or not, which means we can only enable PublishTrimmed in a target, and not as an early-on default value. This is *way* to late for the ILLink component, which needs PublishTrimmed set quite early in the build process. * Fortunately, the ILLink inclusion is actually gated on a different variable (_IsTrimmingEnabled) - which is initialized from PublishTrimmed if it's not set. So the way out here is to set _IsTrimmingEnabled early enough, and now the ILLink component is included and restored. * The additional hurdle is that we need to set _IsTrimmingEnabled in our .NET 6 and .NET 7 workloads as well, it's not enough to set it in our .NET 8 workload (which isn't even loaded when building an earlier TFM). Backport of #17227 Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
rolfbjarne
added a commit
that referenced
this pull request
Jan 17, 2023
… properly. (#17251) .NET 8 will load the ILLink component based on the target framework of the project file - so if .NET 8 is building a net7.0-ios app, the build will restore and use the ILLink component from .NET 7. There is a problem however: * The inclusion of the ILLink component is dpendent on the PublishTrimmed property - if PublishTrimmed is true, then the ILLink component is restored (which makes sense, why restore it if it's not going to be used?). * We always PublishTrimmed, because the linker must always be executed for our projects. So far so good - we can just always enable PublishTrimmed, right? * Nope, when building on Windows, we only enable PublishTrimmed when connected to a Mac, because that's where the ILLink target must be executed (and if we're not connected to a Mac, we can't run the ILLink target, and things fall apart - so just disable PublishTrimmed in that, since it won't work anyway). * Early on in the build we have no idea if we're connected to a Mac or not, which means we can only enable PublishTrimmed in a target, and not as an early-on default value. This is *way* to late for the ILLink component, which needs PublishTrimmed set quite early in the build process. * Fortunately, the ILLink inclusion is actually gated on a different variable (_IsTrimmingEnabled) - which is initialized from PublishTrimmed if it's not set. So the way out here is to set _IsTrimmingEnabled early enough, and now the ILLink component is included and restored. * The additional hurdle is that we need to set _IsTrimmingEnabled in our .NET 6 and .NET 7 workloads as well, it's not enough to set it in our .NET 8 workload (which isn't even loaded when building an earlier TFM). Backport of #17227 Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
rolfbjarne
added a commit
that referenced
this pull request
Jan 17, 2023
…e restored properly. (#17252) .NET 8 will load the ILLink component based on the target framework of the project file - so if .NET 8 is building a net7.0-ios app, the build will restore and use the ILLink component from .NET 7. There is a problem however: * The inclusion of the ILLink component is dpendent on the PublishTrimmed property - if PublishTrimmed is true, then the ILLink component is restored (which makes sense, why restore it if it's not going to be used?). * We always PublishTrimmed, because the linker must always be executed for our projects. So far so good - we can just always enable PublishTrimmed, right? * Nope, when building on Windows, we only enable PublishTrimmed when connected to a Mac, because that's where the ILLink target must be executed (and if we're not connected to a Mac, we can't run the ILLink target, and things fall apart - so just disable PublishTrimmed in that, since it won't work anyway). * Early on in the build we have no idea if we're connected to a Mac or not, which means we can only enable PublishTrimmed in a target, and not as an early-on default value. This is *way* to late for the ILLink component, which needs PublishTrimmed set quite early in the build process. * Fortunately, the ILLink inclusion is actually gated on a different variable (_IsTrimmingEnabled) - which is initialized from PublishTrimmed if it's not set. So the way out here is to set _IsTrimmingEnabled early enough, and now the ILLink component is included and restored. * The additional hurdle is that we need to set _IsTrimmingEnabled in our .NET 6 and .NET 7 workloads as well, it's not enough to set it in our .NET 8 workload (which isn't even loaded when building an earlier TFM). Backport of #17227 Co-authored-by: Rolf Bjarne Kvinge <rolf@xamarin.com>
dustin-wojciechowski
pushed a commit
to dustin-wojciechowski/xamarin-macios
that referenced
this pull request
Jan 19, 2023
…#17227) .NET 8 will load the ILLink component based on the target framework of the project file - so if .NET 8 is building a net7.0-ios app, the build will restore and use the ILLink component from .NET 7. There is a problem however: * The inclusion of the ILLink component is dpendent on the PublishTrimmed property - if PublishTrimmed is true, then the ILLink component is restored (which makes sense, why restore it if it's not going to be used?). * We always PublishTrimmed, because the linker must always be executed for our projects. So far so good - we can just always enable PublishTrimmed, right? * Nope, when building on Windows, we only enable PublishTrimmed when connected to a Mac, because that's where the ILLink target must be executed (and if we're not connected to a Mac, we can't run the ILLink target, and things fall apart - so just disable PublishTrimmed in that, since it won't work anyway). * Early on in the build we have no idea if we're connected to a Mac or not, which means we can only enable PublishTrimmed in a target, and not as an early-on default value. This is *way* to late for the ILLink component, which needs PublishTrimmed set quite early in the build process. * Fortunately, the ILLink inclusion is actually gated on a different variable (_IsTrimmingEnabled) - which is initialized from PublishTrimmed if it's not set. So the way out here is to set _IsTrimmingEnabled early enough, and now the ILLink component is included and restored. * The additional hurdle is that we need to set _IsTrimmingEnabled in our .NET 6 and .NET 7 workloads as well, it's not enough to set it in our .NET 8 workload (which isn't even loaded when building an earlier TFM).
sbomer
added a commit
to dotnet/sdk
that referenced
this pull request
Aug 4, 2023
bdce224 removed the ability to download the ILLink pack by setting `_RequiresILLinkPack`. This is needed for macios scenarios where the ILLink pack should be restored, but it's not known ahead-of-time whether trimming will be enabled. See dotnet/macios#17227 for more context. This adds back the ability to set `_RequiresILLinkPack` to download the ILLink pack even if none of the other relevant settings are enabled.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
6 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
.NET 8 will load the ILLink component based on the target framework of the
project file - so if .NET 8 is building a net7.0-ios app, the build will
restore and use the ILLink component from .NET 7.
There is a problem however:
property - if PublishTrimmed is true, then the ILLink component is restored
(which makes sense, why restore it if it's not going to be used?).
projects. So far so good - we can just always enable PublishTrimmed, right?
to a Mac, because that's where the ILLink target must be executed (and if
we're not connected to a Mac, we can't run the ILLink target, and things
fall apart - so just disable PublishTrimmed in that, since it won't work
anyway).
which means we can only enable PublishTrimmed in a target, and not as an
early-on default value. This is way to late for the ILLink component,
which needs PublishTrimmed set quite early in the build process.
(_IsTrimmingEnabled) - which is initialized from PublishTrimmed if it's not
set. So the way out here is to set _IsTrimmingEnabled early enough, and now
the ILLink component is included and restored.
6 and .NET 7 workloads as well, it's not enough to set it in our .NET 8
workload (which isn't even loaded when building an earlier TFM).