You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A dev attempts to upgrade CLI to the next version, e.g. 2.1.300-rc1 to 2.1.300.
init-tools detects the runtime the new SDK is using, 2.1.0.
Before the upgrade, it would have detected, say, 2.1.0-rc1-12345.
init-tools restores Microsoft.NETCore.App 2.1.0 from the NuGet Gallery.
Core-Setup builds Microsoft.NETCore.App 2.1.0.
CLI restores Microsoft.NETCore.App 2.1.0. It finds the NuGet Gallery one because the id + version already exists in packages/.
CLI is unable to get the source-built package. The important difference in this case is that the source-built package has the RID being source-built, e.g. centos.
An error occurs in CLI because the NuGet Gallery package doesn't have the runtime being source-built.
The CLI error is difficult to investigate, since the cause is so far from the real problem. We can catch it after the Core-Setup build by looking at all the new packages in the blob feed and checking to see if any exist in packages/.
This kind of error isn't limited to tooling restore vs. a repo build--it could also happen between two source-built repos.
The text was updated successfully, but these errors were encountered:
We hit this again when trying to move from 2.1.300 => 2.1.301. (#623) The workaround is to make sure the tooling SDK contains a different runtime version than the one that Core-Setup is producing. (E.g. it's fine to upgrade to the N-1 version, but upgrading to N causes this issue.)
Making this assert as written would be good for diagnosing, but it's not compatible with the idea of the bootstrap flow where we expect some "circular" dependencies. E.g. Microsoft.NETCore.Platforms being required to build Platforms (#653 (comment)).
If the bootstrap flow is far enough away, this assert still seems worthwhile to me because it catches a pretty common issue and it wouldn't take much to implement. A basic idea is to verify after every build that all new source-built nupkgs aren't in the packages/ dir. (Or they match the nupkg in packages/ exactly, if there's a dependency within a single repo that gets resolved through packages.)
However, it might not be difficult to set up the bootstrap flow, either, and maybe we should just do that.
Catch this scenario and exit early:
2.1.0
.2.1.0-rc1-12345
.Microsoft.NETCore.App 2.1.0
from the NuGet Gallery.Microsoft.NETCore.App 2.1.0
.Microsoft.NETCore.App 2.1.0
. It finds the NuGet Gallery one because the id + version already exists inpackages/
.The CLI error is difficult to investigate, since the cause is so far from the real problem. We can catch it after the Core-Setup build by looking at all the new packages in the blob feed and checking to see if any exist in
packages/
.This kind of error isn't limited to tooling restore vs. a repo build--it could also happen between two source-built repos.
The text was updated successfully, but these errors were encountered: