[release/10.0.1xx] [dotnet] Fix loading oldest reference assemblies for library projects Fixes #24043.#24194
Conversation
…Fixes #24043. (#24181) Since this may result in unintuitive behavior (library projects are built differently than executable projects, so code that works in an executable project may not compile when moved to a library project), an escape hatch was implemented as well. One unintuitive behavior was when building an executable project with a library project from Windows: if the library project needs the remote connection, it would use a different workload, and different remote connection, than the executable project, which just wouldn't work. So we don't enable this new behavior when library projects need the remote connection (which is when bundle resources are precompiled for the library project; aka when `BundleOriginalResources=false` - note that it's enabled by default in .NET 10, so developers must opt in to run into this problem and thus not getting this new behavior). Fixes #24043. --------- Co-authored-by: GitHub Copilot <copilot@github.com> Co-authored-by: GitHub Actions Autoformatter <github-actions-autoformatter@xamarin.com>
dalexsoto
changed the title
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ [PR Build #740d53b] Build passed (Detect API changes) ✅Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ API diff for current PR / commitNET (empty diffs)✅ API diff vs stableNET (empty diffs)ℹ️ Generator diffGenerator Diff: vsdrops (html) vsdrops (raw diff) gist (raw diff) - Please review changes) Pipeline on Agent |
✅ [CI Build #740d53b] Build passed (Build macOS tests) ✅Pipeline on Agent |
💻 [CI Build #740d53b] Tests on macOS X64 - Mac Sonoma (14) passed 💻✅ All tests on macOS X64 - Mac Sonoma (14) passed. Pipeline on Agent |
This comment has been minimized.
This comment has been minimized.
💻 [CI Build #740d53b] Tests on macOS M1 - Mac Ventura (13) passed 💻✅ All tests on macOS M1 - Mac Ventura (13) passed. Pipeline on Agent |
💻 [CI Build #740d53b] Tests on macOS arm64 - Mac Tahoe (26) passed 💻✅ All tests on macOS arm64 - Mac Tahoe (26) passed. Pipeline on Agent |
💻 [CI Build #740d53b] Tests on macOS arm64 - Mac Sequoia (15) passed 💻✅ All tests on macOS arm64 - Mac Sequoia (15) passed. Pipeline on Agent |
💻 [CI Build #740d53b] Tests on macOS M1 - Mac Monterey (12) passed 💻✅ All tests on macOS M1 - Mac Monterey (12) passed. Pipeline on Agent |
3 participants
Since this may result in unintuitive behavior (library projects are built differently than executable projects, so code that works in an executable project may not compile when moved to a library project), an escape hatch was implemented as well.
One unintuitive behavior was when building an executable project with a library project from Windows: if the library project needs the remote connection, it would use a different workload, and different remote connection, than the executable project, which just wouldn't work. So we don't enable this new behavior when library projects need the remote connection (which is when bundle resources are precompiled for the library project; aka when
BundleOriginalResources=false- note that it's enabled by default in .NET 10, so developers must opt in to run into this problem and thus not getting this new behavior).Fixes #24043.