-
Notifications
You must be signed in to change notification settings - Fork 252
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
[Bug]: NuGet 6.2 incompatible with lock file from NuGet 6.1 - NU1101: Unable to find package #11851
Comments
The error message is a little different in build pipeline:
Full log (from a slightly more complicated sln/project):
|
Thank you for filing this issue. I can confirm that the restore fails and does not regenerate the lock file. I've added this bug to our backlog to be investigated. |
We've determined this is by design due to a bug fix #5957. Multiple people have reported issues which we're tracking here: #11564 The problem is that your project targets The workaround for this is to add
|
It may be designed to encourage package authors to improve their packages, but in reality it's hurting the multitude higher number of package consumers that have no to limited influence. Such a breaking change should have a lock file version bump/marker, at the very least. Even if an author does fix their package, each consumer still has a broken build untill they can upgrade. Every servicing branch has to consider extra package upgrades. Additionally because this is in a minor update/not tied to a VS major release, one can't even "just" recommend side by side install eg. VS 2019. Consider the number of first party packages affected and how most users won't even consider finding this issue on GitHub based on the error messages, and there's nothing obviously related in the release notes/known issues. If the package authoring problem is so serious, perhaps start with warnings and errors at packaging time (not consumption), and maybe follow up with warnings on package pages or even direct outreach. |
Note that I'm all for the problems being detected at build rather than runtime. Staticly analyse all the things! (but not crying wolf :) |
Hey @fowl2, In this case, the package is authored correctly, but a bug caused a bad resolution. Please follow #11564, where we will consider adding a switch to revert to the old behavior. Please note that the recommendation is that you migrate to the new tooling as the new behavior is the correct one. |
NuGet Product Used
MSBuild.exe, NuGet.exe
Product Version
NuGet 6.2
Worked before?
NuGet 6.1
Impact
It's more difficult to complete my work
Repro Steps & Context
Consider this csproj:
nuget.exe restore repro.csproj
. The lock file is:Workaround - delete the lock file. The new lock file is:
Note the additional dependency on
Microsoft.CrmSdk.CoreAssemblies
.The lock file generated by 6.2 is compatible with 6.1.
Verbose Logs
The text was updated successfully, but these errors were encountered: