I have a pretty big solution (currently 55 projects) with nearly all of them having NuGet packages installed into them. Every one of them works perfectly with NuGet if I use the Project-based "Manage NuGet Packages" dialog.
Unfortunately, every time I use the Solution-based "Manage NuGet Packages", it displays me a multitude of updatable packages under Updates, even though all of them are already installed in the corresponding projects.
This is the case for months now (maybe upwards of a year) and this problem survived several NuGet updates. Honestly, I don't really have an idea where this could be coming from (didn't see anything obviously wrong with all of the NuGet files like packages.config etc).
What could be reason for this problem?
I had the same issue in the past. For me cleaning the content of the packages folders and erasing the NuGet package cache worked.
Related
I have a strange issue:
While i'm coding, my Visual Studio randomly -out of nowhere- says it cannot find the previously installed Nuget Packages. Then it marks half of my code with errors as the packets for the usings are missings.
I then have to download them again and the issue is instantly fixed. These package deletions happen completely out of the blue and since a week over and over again. I cannot track down the issue why it deletes these packages in the first place (?) (or is unable (?) to find downloaded Packages).
Is there a known fix to this?
These package deletions happen completely out of the blue and since a
week over and over again. I cannot track down the issue why it deletes
these packages in the first place
I wonder if you download the project from any code hosting platforms like TFS before you encouter this issue. And from your description, the nuget references are missing which is not a normal behavior. Also, I want to know exactly what you did to cause this issue.
To troubleshoot your issue, you can try these steps:
1) close the VS Instance, delete NuGet.Config file under C:\Users\xxx(User Name)\AppData\Roaming\NuGet\NuGet.Config, restart VS and then restore nuget packages.
2) Besides, every time you encouter this issue, Right-click on the Solution-->Restore Nuget Packages and this will restore any nuget missing nuget packages.
In addition, please make sure these two options are checked by Tools-->Options-->Nuget Package Manager-->General-->Nuget Restore. And the missing packages will be restored automatically when you execute Build.
Hope this could help you.
I recently successfully switched all of our projects over to automatic NuGet restore. To do this I followed this guide. Everything worked great, I was able to delete my /packages folder and restore to my heart's content.
One of the steps in that guide says to edit your .csproj file and remove the EnsureNuGetPackageBuildImports related element.
The problem I am having now is that, after going in and downgrading one of my projects libraries, NuGet seems to have automatically added the EnsureNuGetPackageBuildImports related element back into my .csproj file.
Is there some other setting I should be changing to prevent NuGet from doing this? I would rather not have to edit my .csproj file every time I make a NuGet related change.
Is there some other setting I should be changing to prevent NuGet from doing this?
I`m afraid the answer is not if you going in and downgrading one of your projects libraries.
The target "EnsureNuGetPackageBuildImports" is used to ensures that the imported .props or .targets files are indeed imported in the old way "Enable Package Restore". NuGet has supported NuGet MSBuild support since NuGet 2.5.
Since Nuget 2.7+, Microsoft has dropped support for the 'Enable NuGet Package Restore' in VS2015 and you need to do some manual changes to either migrate old solutions or add the feature to new solutions. Nuget Automatic Package Restore has changed in Nuget 2.7+. Unfortunately, it looks like a non-backward compatible change. We have some developers on 2.7 and before who will now need to upgrade to 2.7+. In this case, NuGet will automatically added the EnsureNuGetPackageBuildImports related element back into your .csproj file when you going in and downgrading one of your projects libraries.
To resolve this, we advice that do not mix 'old' and new methods for automatic package restoration(Remove that files when you use automatic package restoration).
Besides, if going in and downgrading one of your projects libraries is unavoidable, there is a PS script can help you remove it more convenient:
DisableNuGetPackageRestore.ps1
Our VS2013 solutions contain a solution folder called .nuget, containing the files NuGet.config, NuGet.exe, NuGet.targets. What is the significance of this folder and what uses the files? Is it related to the "enable package restore" feature?
If I install or update a package (via the "Manage NuGet Packages" UI or package manager console), does this involve running the above NuGet.exe, or something else? VS is telling me that the NuGet Package Manager is up to date (via the Extensions and Updates dialog), however the above NuGet.exe is quite old. I've also found a very old NuGet.exe file in C:\Program Files (x86)\NuGet\. What uses the latter, and what are the implications of these exes being out of date?
The reason I ask is that we've been having problems with a couple of solutions over recent weeks. We can't update NuGet packages - the operation fails with the message "Error: An item with the same key has already been added". I'm trying to track down the cause, and wondering if these out of date NuGet.exe files might have something to do with it.
As far as I remember this folder is useless now with the latest nuget extension to Visual Studio. It was used before and was nothing but pain in the ass. I am not 100% sure about 2013, but in 2015 all works fine without it, so my suggestion is to update to the latest available nuget extension version and try to delete the folder, most likely everything will work.
Now packages go to current user folder, and use the config from %AppData%\NuGet\NuGet.config. For NuGet 2.6 or earlier, this setting was available in a project-specific .nuget\nuget.config file.
You can read more about it here.
So nuget is gradually getting better and easy to use without too much thinking of all this "magic" folders and stuff.
I want to know how I can debug a NuGet package not properly showing as updated. In my specific case the package for jQuery.Validation is (the only one left) in the "Update" list, but hitting the update button does nothing. Here's the dialog for Managing NuGet Packages for my solution:
Hitting the "Update" button will give an additional popup:
As you can see everything seems slightly grayed out (what does that mean?). Hitting "Ok" just brings me back to the other dialog.
The main problem is that I don't know how to debug this sort of problem. I've tried doing the following:
Opening the Package Manager Console to see if it logs any trouble. No dice.
Checking the jquery.validate.min.js file, which mentions version 1.13.1, which is in fact the one mentioned in the dialog as the newest version.
Checking the packages.config file, which also mentions my solution includes version 1.13.1.
Restarting Visual Studio. No dice.
Remove the package. Re-add the package. No dice (not even after restarting Visual Studio again).
Is this just a bug in the Package Manager or the package? How can I further debug the root cause of this problem?
I'm using Visual Studio 2012, have updated the product as well as all extensions (including the NuGet package manager). The solution was originally based on an MVC 2 template, and has been updated for each major MVC release (currently up to MVC 5). Only this particular package is giving trouble, I've succesfully updated 10+ other packages just before this one.
This can happen if you have an old NuGet package left in the packages directory.
When managing packages for the solution the NuGet dialog will show updates for all packages that are in the packages directory even if they are not installed into any projects. If you manage the packages for the project on its own the NuGet dialog would not show any package updates as being available.
So the workaround is to remove the unwanted NuGet package from the packages directory.
I'm working on a TFS project with a small team. This project has a bunch of nuget packages installed, but it's for a 4.0 project, and the nuget package manager GUI doesn't even offer the older versions of the packages any longer since their 4.5 equivalents are now being used. In order to allow other team members to compile the project, they need to have the exact versions of the packages. I'd like to check in the entire "packages" folder used by nuget. Is this a good idea? If so, how does one check in the "packages" folder and all its contents since it exists at the solution level? There is no "Include in Solution" option in Visual Studio as there is when you right-click an assembly.
in the past I have also checked in the NuGet packages into version control. With this some problems appeared:
Some packages where not checked into version control when committing from Visual Studio into TFS.
Updating packages became a real problem.
For the first problem I had used the TFS Power Tools. The problem with this solution is that every developer needed to install the Power Tools.
A better solution came up with NuGet 2.7. It introduced package restore. With package restore there's no need to check-in the packages folder. They will be restored during build.
We use an on-prem TFS install with no internet access so we have to check in our package folders or our builds fail. The biggest issue is that VS does not behave consistently when it comes to adding the pending changes for new package files, often times it will ignore the .dll files in the pending changes window, sometimes it adds everything fine.