-
Notifications
You must be signed in to change notification settings - Fork 548
[release/10.0.1xx] [dotnet] Fix loading oldest reference assemblies for library projects Fixes #24043. #24194
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
…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>
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
✅ [CI Build #740d53b] Build passed (Build packages) ✅Pipeline on Agent |
✅ [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 |
🚀 [CI Build #740d53b] Test results 🚀Test results✅ All tests passed on VSTS: test results. 🎉 All 115 tests passed 🎉 Tests counts✅ cecil: All 1 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
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.