I have seen this same problem brought up by numerous people online, and have tried just about everything under the sun to resolve this issue but nothing is working. I copied my visual studio solution to another location on my computer, and now when I try to build it I get the infamous...
This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105.
Of course, I've enabled package restoration, tried restoring them manually (in which case I get a message saying "All packages are already installed and there is nothing to restore."), I've tried deleting all packages and then having the project restore them, I've read a lot about maybe the issue being the .csproj file, could that be it? If so, how do I access this file? Seems very rudimentary but for some reason I can't find it in my solution.
Missing NuGet Packages, But “Packages Already Installed”
NuGet will check the packages directory for the solution when it restores.
It checks that this packages directory contains the .nupkg and manifest file for the NuGet package and if so it believes the NuGet package is already installed locally.
So, to resolve the issue "Missing NuGet Packages, But Packages Already Installed", you can try the following troubleshootings:
Make sure you are not add the \packages folder in to source control, like TFS. If yes, please try to remove it out of source control.
Make sure you are not change the .csproj file to another location. If yes, please edit the .csproj file and correcting the relative path to the solution folder.
Remove the package folders and their contents from the packages directory, then try again.
If above not help, please try to share the restore log to us, I will check it and update my answer.
Hope this helps.
The thread is quite old but for someone coming back.
Make sure to delete the bin and object folder and rebuild the project.
Related
I am having a strange (new) issue with Nuget in Visual Studio 2019 (v.16.9.0).
The Solutions are all ASP.NET Web Apps (MVC). I run on a local LAN. In the Nuget Package Manager 'Allow Nuget to download packages' and 'Automatically check for missing packages during build are both selected. I am using Packages.Config for management and the source is https://api.nuget.org/v3/index.json. VS is able to communicate via the Windows Defender Firewall. The target framework is .Net 4.7.2
The first issue is when I do a package restore after deleting the packages in the folder, it shows this error: The requested operation cannot be performed on a file with a user-mapped section open.
After I do the build, the files are being created correctly, including the new/existing DLLs. These replenished/refreshed DLLs work perfectly and the program runs. The strange part, however, is that the relevant NUPKG file has zero content (which is obviously triggering the error). The message eventually disappears after completion of the DLL downloads I assume. All good so far but with zero content in the NUPKG file.
When I now try to update a package things go awry, the Error List shows:
An error occurred while trying to restore packages. The file is not a valid nupkg. File path...
Then after a full restart of VS, I get this:
An error occurred while retrieving package metadata for 'ABC.3.5.0.2' from source 'I:....\packages'. 'ABC' being the first file in the package list. It therefore appears to be failing because the relevant NUPKG has no content.
I am able to paste any file freely to the packages folder and its sub-folders, indicating that there is no lock on the files. Also VS is able to write the rest of the package structure to the folder without issue.
IMHO this must mean that something is specifically locking/blocking the NUPKG files (or deleting their content during creation perhaps?). A search reveals nothing that I can see.
I even tried creating a brand new solution. During creation, the identical error message above popped up a warning. I also tried a few other of my existing solutions and got the same result. I updated VS and then I even did a full VS reinstall to the latest version, all to no avail.
I first noticed the issue after defining dependencies during an Azure Web App deployment (the Azure deployment tool optionally allows for updates to Nuget packages). After the Nuget update failed I set the option to blank and deployed anyway, the idea being to manually update the packages later. I cannot be certain, but I think this is when I discovered the issue. Could this process have changed a VS config setting somewhere perhaps?
Before the reinstall I opened the devenv.exe.config from inside VS and changed the IPV6 setting to false. No luck, so I have changed it back. I also did a test on one of the packages, downloading the package from the Nuget site directly and replacing the VS downloaded version, but I get the same errors.
Install failed. Rolling back... Package 'System.Buffers 4.5.1' does not exist in project 'ClickAuth_Graph' Package 'System.Buffers 4.4.0' already exists in folder 'I:\My Drive\Backups\ClickAuth_Graph (01_03_21)\packages' Added package 'System.Buffers 4.4.0' to 'packages.config' Removing package 'System.Buffers 4.5.1' from folder 'I:\My Drive\Backups\ClickAuth_Graph (01_03_21)\packages' This file is not a valid nupkg. File path...\packages\System.Buffers.4.5.1.nupkg Central Directory Corrupt An attempt was made to move the file pointer before the beginning of the file. At line:1 char 1 • Update-Package System.Buffers +CategoryInfo NotSpecified: (:) [Update-Package], Exception o FullyQualifiedErrorId : NuGetCmdletUnhandledException,NuGet.PackageManagement.PowerShellCmdlets.UpdatePackageCommand
For the record I have one stale Nuget package in the portfolio. I don't use Github, but a repository was set upfront. I have not recently committed anything to Github.
Is there an expert out there that can help?
What you described is in a mess. And please try the following suggestions:
1) first clean all nuget caches or delete all cache files under C:\Users\xxx\.nuget\packages and I:\My Drive\Backups\ClickAuth_Graph (01_03_21)\packages.
I think that you have download the valid nuget packages on it and if your local exists the same name,version nuget package, it will always use the local wrong nuget package. So you have to delete them and then download the right package from the nuget package source.
2) enter Tools-->Options-->Nuget Package Manager-->Package Sources and make sure that you have enabled nuget.org package source, and if you have other own feed which you want to use, also enable it.
If not, please try to close VS, delete nuget.config under C:\Users\xxx\AppData\Roaming\NuGet. And then restart VS to re-generate it. Then, re-add your own feed if you have it.
3) run update-package -reinstall under Tools-->Nuget Package Manager--> Package Manager Console and then also delete bin and obj folder of your project.
4) you could also try to disable Azure deployment tool
Besides, if you have other solution level nuget.config, please check whether its content is suitable for your project. And if it is useless, you could remove them.
Trying to tidy up my file structure, I moved packages.config to a subfolder. Only to discover it was not being picked up by Nuget any more.
Is it possible to move the file or is it hard-coded into VS that it must be in the same directory as the project file?
Googling doesn't give me an obvious answer, I just get general information on packages.config's purpose.
Does packages.config have to be in the project folder?
You cannot move that packages.config file into any other sub folder except the project's root folder.
Also, I agree with thatguy.
Packages.config nuget management format allows packages.config file be in the root directory of the project and nuget and msbuild will be able to recognize this file and manage the nuget packages in your project. That's its mechanism.
So my suggestion is that you should move it back to the project's root directory. And so far, this is the only way to ensure that you successfully manage packages using packages.config.
Besides, if you still want your request to come true, I suggest you could suggest a feature request on our User Voice Forum(click suggest a feature). And The Team will consider your request carefully and I hope they will give you a satisfactory reply.
If used, packages.config is typically located in a project root. It's automatically created when the first NuGet operation is run, but can also be created manually before running any commands such as nuget restore.
This is from the packages.config reference. Although it states that the configuration file is typically located in the project root, there is no indication on any requirements for moving it. Therefore, it might be a limitation of the Visual Studio Nuget package manager that expects the packages.config file in the project root. I have never seen any official documentation or a working example of moving this file without breaking the package manager.
I am trying to move my solution to utilize NuGet Package Restore so that I can keep the packages folder out of source control. I have some confusion as to how to properly implement it however.
I currently have the packages folder in TFS, should I delete it before committing the changes for NuGet Package Restore?
Do I need to commit the .nuget folder to source control? This article is telling me to remove .NuGet.exe and NuGet.targets as well.
Will using NuGet Package Restore break build in TFS? (say for gated check-ins)
Yes.
The better option is to use the Package Restore Migration script. I've used it several times and it works beautifully. It will remove NuGet.exe, NuGet.targets, and also (very importantly) clean up your project files to remove references to the NuGet.targets file. If you just delete NuGet.targets, it will break your builds.
NuGet package restore shouldn't break any builds if you follow the steps outlined in the article you linked very closely. Of course, your build server will need access to the internet so it can get to nuget.org. If your build server is locked down and has no internet access, package restore will definitely not work.
Make sure that you close down Visual Studio before running the package restore migration script... I've found that if you run the script with the solution open, it won't work properly.
If you're using Git, add the packages folder to your .gitignore.
If you're using TFVC, make sure that your NuGet.config file has the disableSourceControlIntegration key set to true.
From Visual Studio 2013 update 3 Nuget package restore is the default and does not need enabled.
If you delete the /packages folder and check in it should just populate automatically with no additional work required.
Yes: Remove nuget.targets and .nuget folder.
When other developers get the vs.net 2013 solution from TFS, Nuget doesn't seem to work as expected and many of the individual projects in the solution do not have the required dll's downloaded (although they are defined in the packages.config file).
If I go to view the installed packages, it shows up as they are installed and the correct projects are selected.
I went into console and ran:
Update-Package -Reinstall
After doing this, my packages.config file was truncated for whatever reason and 80% of my packages were removed from the config file!
What should I be looking into as it is either I have setup the solution incorrectly or nuget just isn't reliable.
Thoughts?
First of all make sure that NuGet Packages Restore is turned ON.
This forces to restore missing binaries directly from NuGet server. You can right click on Solution and enable this option as follow:
Make sure that .nuget folder that contains nuget.exe is created under your Solution.
You'll want to make sure that you have automatic package restore turned on in VS 2013. You can do this in the options.
Then, when you build, VS should grab the packages for you. If you want to manually restore the packages or do it from powershell, you'll want to use the command nuget.exe restore in the folder your solution lives in.
If you're using custom package sources, you'll want to make sure you specified them in your nuget.config file.
With newer versions of NuGet it is possible to configure a project to automatically restore NuGet packages so that the packages folder doesn't need to be included in the source code repository. Good.
However, this command adds a new .nuget folder and there is a binary there, NuGet.exe. This can also be re-created automatically by Visual Studio and so it doesn't feel correct to add that to version control. However, without this folder Visual Studio won't even load the solution properly.
How do you people deal with this? Add .nuget to source control? Run some command line script before opening the solution?
This post is old, you should not be using solution level NuGet package restore anymore. As of version 2.7+ there is an option in the NuGet setup to automatically restore packages on build.
So the .nuget folder can be deleted and the option removed from your projects.
http://docs.nuget.org/docs/reference/package-restore
UPDATE: With the release of NuGet 4.x and .NET Standard 2.0, when you use the new csproj format you can now use package references, ironically reintroducing the dependency on msbuild to restore packages, but now packages are a first class citizen of msbuild. The link above also makes mention of the PackageReference, but the following announcement details it better:
https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html
And the NuGet 4.x RTM announcement, which ironically isn't as useful:
https://blog.nuget.org/20170308/Announcing-NuGet-4.0-RTM.html
UPDATE 2: Apparently with VS2017 you can even use package references with classic csproj projects, but they aren't backwards compatible anymore, and there have been some problems with restoring package sub-dependencies. I'm sure that will all be resolved.
#Richard Szalay's answer is right - you don't need to commit nuget.exe. If for some reasons Visual Studio does not automatically download the nuget.exe, make sure you have the following set to true in the nuget.targets file:
<!-- Download NuGet.exe if it does not already exist -->
<DownloadNuGetExe Condition=" '$(DownloadNuGetExe)' == '' ">true</DownloadNuGetExe>
Close the VS solution, reopen it and build it. Visual Studio should download nuget.exe automatically now.
According to this thread, the .nuget folder should be version controlled.
You need to commit .nuget\nuget.targets, but not nuget.exe. The targets will download the exe if it doesn't exist, as long as you change DownloadNuGetExe to true in nuget.targets
Although I usually don't like the idea of adding exe's to source control, I would suggest that source control should contain anything that is required in order to open, build and execute the project.
In this case it sounds like the .nuget folder is a required dependency. Therefore it ought to be under source control.
The only question left, that you need to research, is how NuGet is going to react if that folder is marked read-only, which TFS will do once it has been checked in.
Update:
I did a little more research on this as I've never used NuGet before. http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html
I would suggest that probably what you want to do is make NuGet a requirement that has to be installed on every developers workstation.
Further, you should place in source control the batch file required to get a workstation ready to start editing the project. The batch file is going to run the commands necessary to get and install the dependency packages.
Beyond that I'd say you might want to contact NuGet directly to ask them how, exactly, this is supposed to work.
Now that nuget supports package restoration we're looking at it more closely.
We use Subversion for source control, and my initial thoughts are that .nuget should be added to our repository, but added using svn:externals so that it points to a single location.
That way we can automatically push out new versions to all developers and projects. For projects on release branches, rather than HEAD, we can specify the revision of svn:externals reference if we want to leave nuget alone.
We have a lot of projects, so it also means not duplicating nuget.exe multiple times in the repo.
We have the nuget.config file in the folder, as it has the references to our internal Nuget server, using the Package Sources area:
https://docs.nuget.org/consume/nuget-config-settings
Apart from this reason, you should let Visual Studio handle the downloading of packages.