A svn commit failed within TeamCity (Enterprise 9.1.7 (build 37573)).
The VS 2013 project can be rebuild locally.
Step 4/9: Restore packages (NuGet Installer) (5m:07s)
[Step 4/9] Step Restore packages (NuGet Installer) failed
Nothing was changed by me concerning TeamCity. Have done already many commits (which resulted into NuGet packages). This error is unclear for me.
EDIT:
Error messages can be seen in the build log below of
Step 4/9: Restore packages (NuGet Installer) (5m:07s)
For instance:
[restore] Unable to find version '1.0.0.0' of package
'Gnu.Getopt'.
... and a few other entries with 'Unable to find' ...
So I deleted locally the packages folder within my trunk directory. Subsequently Visual Studio rebuild was invoked. The packages were automatically downloaded and can be used locally. (So to avoid a wrong guess --- they were not deleted at the deployment server)
EDIT 2: Have done another commit. Now this issue does not occur anymore. Worth to mention, I did not any kind of rollback conercerning the old commit, which resulted into the error messages stated above. And the source code of that commit was kept by the way. So the old commit was not the reason for a problem concerning restoring of packages. TeamCity settings are still equal in comparison to last week. For me, that's a solution (because I am hired as software developer and paid for that). (By the way - a TeamCity admin was informed about this issue.) For Stackoverflow, it's not the answer concerning the faulty behaviour that occured last week as described. Thus I did not state my solution as an answer (because this is still open). In another SO thread, I saw a discussion about a mismatch concerning the versions of NuGet.exe and the restore mode but that was not the case for my issue.
Related
Environment
Visual Studio 2019 (latest SP upto Dec 2020)
.NET Core 3.1 with latest SP up to Dec 2020
WebAPI project with lots of child DLLs being loaded at runtime
Problem Context
When the solution is build, a "GenerateDepsFile:" error is given by MS Build for a particular project in the solution. It tries to add an item to a dictionary when it already exists, but not which dictionary it is trying or what duplicate key is being attempted.
Exploration Performed
There are no compilation errors (apart from Deps file)
All referenced projects are building fine with no errors in themselves
All NuGet references are available with no errors
Clean and Rebuild all solutions involved
Manually delete the objand bin folders across codebase
The "GenerateDepsFile" task failed unexpectedly is too large and you should check its detailed build log to judge what is the real problem.
Under Tools-->Options-->Projects and Solutions-->Build and Run--> set MSBuild project build output verbosity to Detailed and then build again to get its detailed log.
Also, you can share the detailed error build log here with us.
Maybe you could check these suggestions:
1) clean nuget caches or just delete all cache file under C:\Users\xxx\.nuget\packages.
2) do not forget to delete .vs hidden folder under the solution folder, bin, obj folder of the project, and then use dotnet restore command or msbuild -t:restore command to restore these files.
3) update VS2019 to the latest 16.8.4 and your Net Core 3.1 Sdk to the latest 3.1.11.
After lots of exploration, it looked like a multi version NuGet package scenario (cleaned the NuGet cache already)
Finally I went to all child projects and validated if the same version of all NuGet package is being used across. It turned out that the version of some assemblies ( esp Microsoft.Data.SqlClient) were different in child projects and the calling project.
Since the projects themselves were building all fine, this was not reported on project level, but when those DLLs were getting consumed in parent one, it start giving the error.
It turned out the child projects were built a while back with the latest version available at that time. The parent project was just referencing the DLLs from the output folder and was not aware of previous version and got its own version updated..
So, do ensure that when a particular version of NuGet is approved at one place, that gets updated across the whole eco-system!
However MS should update the error to at least point what dictionary is failing with what specific key in the main message as its very hard to debug with the verbose log.
The "GenerateDepsFile" task failed unexpectedly.
I believe You just need to delete the bin and obj folder and then Clean and Rebuild solution.
this should work, It work for me after going through many approaches.
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.
We're just in the process of transitioning from VS2013&15/TFS2013 to VS2017/TFS2017 (on-site TFS, not VSTS) and the first test solution is a dotNet Core 1.1 based one (a multi-project web service).
The solution builds fine on the original developer's box and I've got it out of TFS and it builds fine on mine too. In keeping with our previous methodology the contents of the packages folder are checked in with the projects as this makes the packages locally available on the build box (no internet).
Building the solution on the build server is a different story, however, as I get multiple errors of the form...
..\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
This whole project.assets.json not found issue seems to be causing headaches all over. In my case the issue is that I'm trying to resolve it on our TFS 2017 Build Server, which does not and never will have internet access ('cos it's a server!).
All the solutions I've seen thus far seem to suggest running the Nuget Restore command but that can't work since the server cannot get to nuget.
This is nothing fancy yet, just a simple TFS 2017 Build definition with a Get sources and a Build solution step. I can't understand how something so simple has become so difficult.
Changing the Nuget Package Restore options makes no difference.
Since the project.assets.json files are generated on the fly in the obj folder, I can't even check them in to reuse. Can anyone please suggest a workaround, at the moment the test project is dead in the water.
Edit: trying the same process with a 4.6.1 web project created with VS2015 had similar results of unresolved references (e.g. System.Web) but didn't raise the same error, probably due to being an older, non-Core project.
According to I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
The issue seems not related to TFS build side since it also not work with local build through VS in the build agent machine.
Since this is a dotnet project. So, you could try to use “dotnet restore” and not “nuget restore”. Try using the dotnet core template (which uses dotnet restore).
If you are using authenticated nuget feeds, then you can use nuget restore but you also need to use nuget installer task. See https://github.com/Microsoft/vsts-tasks/issues/3762 for a discussion on that.
The Nuget version should be higher than 4.0.
Without dotnet restore and Nuget restore and only use get source/Visual Studio Build will not be able to build the dotnet core project. If your server do not have internet access, as a workaround you should use Local feeds.
I am using TFS 2013 with Visual Studio online. Last day, I finished all my work and checked-in. There were some conflicts. I merged the conflicts and checked-in again. But when I open the app today, I found some methods missing. Is it possible to grab my local version just before the yesterday check-in?
This happens to me and my colleagues as well. After you merged the conflict, merged files are your latest local files. If you have decided remove your changes during merging, your changes are gone for ever.
You must pay special attention next time you merge files. This also give you another hint: Don't rely on tools. You're responsible for files you checked in.
We're using an internal feed for a number of packages. Today we noticed that Package Restore was no longer working. Every package failed with an error along the lines of this:
Unable to find version '...' of package '...'.
The project with issues had its first commit on 2013-10-04, at the time NuGet had version 2.7
Multiple people successfully cloned the source control repo, which had no binaries at all, and nobody recalls any problems with package restore. So either all of us are going insane, or this was working fine.
When I try to do a new clone today and update to that very first commit, I get the error above. Same thing with the most recent commit. This is with NuGet 2.8
These are the docs concerning Package Restore changes in 2.7:
Before any of the above steps are taken however, NuGet verifies that
consent is given on two levels:
Visual Studio is configured to 'Allow NuGet to download missing packages'
Visual Studio is configured to 'Automatically check for missing packages during build in Visual Studio'
Both items are checked in the VS options.
This approach to package restore offers several advantages:
No need to enable it for your project or solution. Visual Studio will automatically download missing packages before your projects are
built and team members don't need to understand NuGet Package Restore.
Yet this is exactly how we managed to solve the problem today: right clicking the solution and enabling Package Restore. This resulted in changes on multiple levels.
.csproj level
+ <SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
+ <RestorePackages>true</RestorePackages>
.sln level
+Project("{2150E333-8FDC-42A3-9474-1A3956D46DE8}") = ".nuget", ".nuget", "{6FE1C500-523A-4E05-B72E-28F14DEDB055}"
+ ProjectSection(SolutionItems) = preProject
+ .nuget\NuGet.Config = .nuget\NuGet.Config
+ .nuget\NuGet.exe = .nuget\NuGet.exe
+ .nuget\NuGet.targets = .nuget\NuGet.targets
+ EndProjectSection
+EndProject
And lastly, the creation of .nuget\NuGet.Config, .nuget\nuget.exe and .nuget\NuGet.targets.
As a test I've also created a new solution and project. Now I
add one of the internal packages
build
close the solution
delete the packages, bin and obj directories (like our ignore file does)
open the solution
rebuild, and get the error mentioned in the beginning of the question
When I repeat these steps with a package from the official repo, everything works fine. No errors at all.
I've went over the release notes for 2.7.1, 2.7.2 and 2.8.0 but I don't see anything related to this. What's going on?
It's a confirmed bug in the current release of NuGet, but it's fixed in the nightly builds.
Workaround for now is to set Package source to All in the Package Manager Console.
This may be caused by the following issue: https://nuget.codeplex.com/workitem/4000
Related to this issue, the nuget.exe client would not follow redirects, so if your internal NuGet server is returning a 302 when attempting to download a package, the client would not follow it and result in nothing happening. It's worth double-checking with a Fiddler trace to see if the VS extension has the same behavior.