I'm using TFS for the first time and attempting a build. I'm getting the error:
This project references NuGet package(s) that are missing on this computer. use NuGet Package Restore to download them.
I realize that there are many similar posts on StackOverflow and I've searched through quite a few of them. What I've gathered is that the two boxes under Package Restore in Package Manager Settings should be checked (but that this is also irrelevant now because they're checked by default). I verified that mine were both checked anyway.
The next piece of advice I considered is deleting the /packages folder from the Source Control version of my application. There is no packages folder there OR in my local (pre migration to TFS) version of the application. Instead, there's a ../packages/ folder (up one level) from the application folder. It seems that, at some point, I've opted to store the packages for all of my applications in the same folder? If so, where is this setting and what do I need to change it to either in my local version or in Source Control Explorer?
Thanks!
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.
Our team works on a project with TFS as source control. Sometimes that I want to check-in some errors happen.
D:\CustomManager.1.0.7184.35750\lib\net461\CustomManager.dll: Could not find a part of the path 'D:\CustomManager.1.0.7184.35750\lib\net461\CustomManager.dll'.
I gotta go to the Packages folder and make a new folder. after that, I have to copy the previous version of the package in that and then rename it to solve the case. This way is a little annoying because sometimes after that, new errors will show with different versions.
Additional information: This error will only be shown when I update the NuGet packages.
Is there a simple way to fix this?
Seems you directly checked libraries(dlls) in to TFS and manage version control of them.
It's not a recommend way, there are multiple downsides such as it's never exactly clear which projects are using which versions of which assemblies. It's a maintenance nightmare.
Suggest you use Nuget to handle these libraries in TFS. You should compile your code, package it in Nuget and publish it. For multiple projects you can upgrade their nuget references when appropriate, or stick with the older versions if they need to. If you need to reference a known-good, stable version, you just make sure your project is configured to pull a specific version from NuGet.
TFS use Package Management that hosts NuGet, npm, and Maven packages alongside all your other TFS assets: source code, builds, releases, etc, also be able to handle the external packages.
You could add external packages to a TFS Package Management feed. When you restore the packages, select the feed. All need packages will be restored entirely. To achieve this, just use Push NuGet packages to specify the packages you want to publish and the target feed location.
More details please refer Get started with NuGet Package Management in TFS
Update:
Keep looking for old packages, this will not happen if you already referred the latest dll in project. Please double check this part.
In your situation, if you want to check the dll in source control, you should add dlls in the solution/project and use relative path. Otherwise, tfs server may not find path.
For cache issue, suggest you to clear TFS cache then restart VS, and check in again, this may do the trick.
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.
In my projects folder root, I have a packages folder that is utilized by various web applications at C:/Projects/packages. All application references that point to this folder work fine.
However, with a new application, when I pulled the latest code, all references expect the packages folder to live at the solution level - C:/Projects/CompanyName/Apps/SolutionFolder/packages.
When I pull latest, this folder is not included (it's never checked in to subversion) so I have missing references when I first open a project up. However, when I try to build, it doesn't pull the latest for these packages and of course, doesn't compile. When I run Update-Package -reinstall, it will update the packages IN C:/Projects/packages, and it WILL NOT create the packages folder at the solution level.
I've confirmed that I have the packages.config in each project in the solution and that each project expects that the assemblies will be housed in the packages folder at that level. What's weird is that after I run the -reinstall, these hintpaths in the project files will actually point to the C:/Projects/packages folder and the assembly references will resolve...but only for 3rd party packages and NOT for our in-house built packages.
Does anyone know why this occurs? The solution has been to get a copy of the packages folder that a coworker is using and paste that into the solution folder but that doesn't solve the problem if it occurs again.
Per #MattWards link I checked the nuget.config file in appdata, which specified this C:/project.packages path. After removing this setting and building my solution, the packages folder was added to the solution level and everything worked.
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.