-
Notifications
You must be signed in to change notification settings - Fork 507
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
[dotnet] Accept invalid runtime identifiers for Restore. #15357
[dotnet] Accept invalid runtime identifiers for Restore. #15357
Conversation
Validating that projects are only restored using valid runtime identifiers have turned out to be an interesting rabbit hole. Nobody seems to dispute the fact that it's a correct validation, the problem is that it apparently turns out quite complicated to not do the wrong thing for projects with multiple target frameworks. In some scenarios apparently the Restore target might want to restore all target frameworks, which breaks down if whatever the user wants to do requires setting a runtime identifier, because then that runtime identifier is set for all target frameworks. So for the sake of simplicity, we're going to try removing this validation for the Restore target (we're keeping it for the Build target). There are thus two potential scenarios: 1. The Restore succeeds using invalid runtime identifiers. This shouldn't affect valid builds (since those should be completely separate due to using different runtime identifiers). 2. Something else breaks. At worst the user will be given a less comprehensible error message. Time will tell if this is better or worse than the current experience. Ref: NuGet/Home#11653 Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1558247
This comment has been minimized.
This comment has been minimized.
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.
Not a fan but 👍
This comment has been minimized.
This comment has been minimized.
3 similar comments
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.
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.
🔥 [PR Build] Build failed 🔥Build failed for the job 'Detect API changes' Pipeline on Agent |
🔥 Unable to find the contents for the comment: D:\a\1\s\change-detection\results\gh-comment.md does not exist :fire Pipeline on Agent |
💻 [PR Build] Tests on macOS Mac Catalina (10.15) passed 💻✅ All tests on macOS Mac Catalina (10.15) passed. Pipeline on Agent |
❌ [PR Build] Tests on macOS M1 - Mac Big Sur (11.5) failed ❌Failed tests are:
Pipeline on Agent |
🚀 [CI Build] Test results 🚀Test results✅ All tests passed on VSTS: simulator tests. 🎉 All 223 tests passed 🎉 Tests counts✅ bcl: All 69 tests passed. Html Report (VSDrops) Download Pipeline on Agent |
/sudo backport release/6.0.3xx |
/sudo backport release/6.0.4xx |
Backport Job to branch release/6.0.3xx Created! The magic is happening here |
Backport Job to branch release/6.0.4xx Created! The magic is happening here |
Hooray! Backport succeeded! Please see https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6410051 for more details. |
Hooray! Backport succeeded! Please see https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=6410053 for more details. |
…tore. (#15491) Validating that projects are only restored using valid runtime identifiers have turned out to be an interesting rabbit hole. Nobody seems to dispute the fact that it's a correct validation, the problem is that it apparently turns out quite complicated to not do the wrong thing for projects with multiple target frameworks. In some scenarios apparently the Restore target might want to restore all target frameworks, which breaks down if whatever the user wants to do requires setting a runtime identifier, because then that runtime identifier is set for all target frameworks. So for the sake of simplicity, we're going to try removing this validation for the Restore target (we're keeping it for the Build target). There are thus two potential scenarios: 1. The Restore succeeds using invalid runtime identifiers. This shouldn't affect valid builds (since those should be completely separate due to using different runtime identifiers). 2. Something else breaks. At worst the user will be given a less comprehensible error message. Time will tell if this is better or worse than the current experience. Ref: NuGet/Home#11653 Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1558247 Backport of #15357 Co-authored-by: Rolf Bjarne Kvinge <[email protected]>
…tore. (#15490) Validating that projects are only restored using valid runtime identifiers have turned out to be an interesting rabbit hole. Nobody seems to dispute the fact that it's a correct validation, the problem is that it apparently turns out quite complicated to not do the wrong thing for projects with multiple target frameworks. In some scenarios apparently the Restore target might want to restore all target frameworks, which breaks down if whatever the user wants to do requires setting a runtime identifier, because then that runtime identifier is set for all target frameworks. So for the sake of simplicity, we're going to try removing this validation for the Restore target (we're keeping it for the Build target). There are thus two potential scenarios: 1. The Restore succeeds using invalid runtime identifiers. This shouldn't affect valid builds (since those should be completely separate due to using different runtime identifiers). 2. Something else breaks. At worst the user will be given a less comprehensible error message. Time will tell if this is better or worse than the current experience. Ref: NuGet/Home#11653 Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1558247 Backport of #15357 Co-authored-by: Rolf Bjarne Kvinge <[email protected]>
Validating that projects are only restored using valid runtime identifiers
have turned out to be an interesting rabbit hole.
Nobody seems to dispute the fact that it's a correct validation, the problem
is that it apparently turns out quite complicated to not do the wrong thing
for projects with multiple target frameworks.
In some scenarios apparently the Restore target might want to restore all
target frameworks, which breaks down if whatever the user wants to do requires
setting a runtime identifier, because then that runtime identifier is set for
all target frameworks.
So for the sake of simplicity, we're going to try removing this validation for
the Restore target (we're keeping it for the Build target).
There are thus two potential scenarios:
affect valid builds (since those should be completely separate due to using
different runtime identifiers).
comprehensible error message. Time will tell if this is better or worse
than the current experience.
Ref: NuGet/Home#11653
Ref: https://devdiv.visualstudio.com/DevDiv/_workitems/edit/1558247