-
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
Error messages for version compatibility during Upgrade-Package are unhelpful #2964
Comments
NuGet verifies that all packages are valid during dependency resolution.
This is from the nuspec of the xunit 2.0.0 package. It requires exactly version 2.0.0 of xunit.assert, which conflicts with your currently installed version of 2.1.0-beta3-build3029. This impacts your upgrade because potentially the correct xunit packages could conflict with the new packages. In general the full closure of packages needs to be correct for an upgrade to succeed. To work around this use dependency behavior: ignore dependencies from the package manager UI. |
@emgarten Thanks, but I didn't really file the issue because I wanted someone to explain the error message to me. I filed the issue because I want the error message to be clearer, so that it does not need so much explaining. Could I improve the issue to make it easier to review/address? PS - I feel a big part of what makes this error message hard to work with is the fact it seems to be complaining about the constraint in a nuspec file, which is not something you authored or can fix, unless you are lucky enough to the package author, instead of really telling you what you've done 'wrong', how it relates to that constraint and how to fix it. |
@TimLovellSmith can you share how were able to get an invalid combination of xunit packages installed to start with? Did you use NuGet Visual Studio extension, or was this done with other manual changes? |
There are error message improvements going into the next release of NuGet. For example starting out with an invalid packages.config as was the case here, an error will be displayed. See: #1373 |
This does seem like a possible dupe of #1373. @emgarten I don't think it's that useful to speculate how I got into this state with invalid combination. Invalid combinations should just be assumed to be something that happens. E.g. this probably happened months ago and could easily have been user error when doing a git merge or selective git resetting lines/files or something of that nature. |
Jeah, I got a similar errors. right now. Sometimes i would like to see the dependency tree, and where it is broken. And git-merge is a problem! |
Thanks for reporting this issue. At this time we suggest moving from packages.config to PackageReference with VS 2017 to resolve your issue. You can find out more about this here: https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html |
Here is an error I encountered. It isn't nearly as helpful as I would like it to be. I'm trying to update FakeItEasy and I can't because...
'Unable to resolve dependencies. 'xunit.assert 2.1.0-beta3-build3029' is not compatible with 'xunit 2.0.0 constraint'
What does that have to do with anything? What I can see is that NuGet thinks this information is highly important for some reason. But what I wish to know but can't yet divine from the message is: what rules NuGet is following (why is it checking compatibility of X vs Y?), and what data (what line, of what files?) caused the rules to be violated? (line:1 char:1 is not the answer, thanks powershell!)
Oh wait... part of the answer is buried above "with respect to project Provisioning\AzureCache.ResourceModel.Tests'. So it must be looking at that packages.config right? Probably...
But... what is this xunit 2.0.0 constraint xunit.assert = 2.0.0 that it is talking about? Does that refer to something in my code? Or something in the package metadatas? There's so much guesswork to be done for someone who is not used to seeing this error every day!
And oh yes - why can xunit dependency issues break my FakeItEasy upgrade at all? I thought these would be orthogonal package families! :p
Cheers,
Tim
The text was updated successfully, but these errors were encountered: