Suddenly my TFS 2018 private feed has (apparently) started inaccurately reporting the existence of my internal NuGet packages.
VS 2017 is able to read the listing ok, but it complains when I try to install the package:
Package '<PackageName>' is not found in the following primary source(s): 'https://api.nuget.org/v3/index.json,http://server3:8080/tfs/InteXX/_packaging/Packages/nuget/v3/index.json,C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\'. Please verify all your online package sources are available (OR) package id, version are specified correctly.
But it shows as present in the VS list, as well as the Packages page in TFS. If I knew the folder that TFS uses to store them I could verify, but alas I don't.
This also affects the Updates tab on the VS NuGet dialog; no updates are present there, even though I know I've published them.
How can I fix this?
Yikes! A solution cleaning was all it took.
Who'da thunk it?
Related
We have an ASP.Net MVC Core project solution in TFS.
And there is an error icon at the top of the solution explorer that says "Package restore failed".
And if I open up the project.json I see the red sqigglies:
"The dependency ... could not be resolved" for several dependencies.
The developer who created this error has since fixed it. And all the other developers on the team get latest and the error goes away.
But it won't go away for me.
I get latest and the error icon at the top of the solution explorer and the errors within the project.json are still there.
I blew away the folder, got latest from Team Explorer, and the errors are still there while gone for the other errors.
Anyone know why this is happening?
I'm stumped. I don't understand what is happening.
First, you could try to do a force update for the specific error fixed changeset.
To force a update, use the "Get Specific Version" command with the
"Overwrite all... " option checked.
You could also clear TFS and VS cache, delete old workspace(back up changes first), create a new one, then do a fresh getting latest files from TFS source control. Which should do the trick.
If the issue still exist, you will have to check your local environment if you are missing some thing. Do a simply compare of the environment with other developers on the team.
It turns out this was a combination of the way .Net Core stores nugget packages and of being in a government environment.
We log into our computer with one account that does not have admin priveledges and this is the one I develop with in order to connect to TFS. But there seems to be a lock on the users folder for this account. So when I start up the solution and project.json tries to resolve all the packages, if one is missing it can't download it and put it in that folder. I then have to start Visual Studio as an Admin and open the project. Then the missing package is downloaded to the nugget package folder under my Admin user's folder. Then I read the resolution failure output at the top of the solution explorer next the the red circle with the X in it to see which package is missing and copy it over. It may be more than one so you have to close VS open back up as the non admin account and look for the next one that fails.
I have a small solution containing three Visual Studio projects. I'm working in Visual Studio 2015 using TFS 2015.
I have implemented a gated check in, but for some reason the solution will not build on the TFS server. I'm referencing only 1 nuget package - Entity Framework. I am not checking my package folder into TFS, but my packages.config files are being included.
I have previously set up a different project on the same server using the same build definition and it works fine.
In order to restore packages prior to build, you will need to run the following command as part of your build process.
nuget.exe restore path\to\solution.sln
One way to do that is to add another project that is responsible for building your solutions and making sure that the packages get restored prior to your solutions being built.
Following write-up walks you through getting that set up: nuget docs
I managed to get it working, but I tripped into the fix and don't know what exactly solved the problem. This is the first time I've really had to handle TFS builds.
I know I only had one build definition defined and it was intended for a different solution - of which this code was also a part. I think when I was checking in this solution it was actually trying to build the other.
Apparently, I can't have my nuget packages set up different ways for code that is in two different solutions. Anyway, that's my best guess.
I recently upgraded an old ASP.Net MVC3 project that was storing all our COTS (commercial off-the-shelf) .DLL files in source control to use NuGet Restore Packages instead.
Now whenever someone gets the source afresh from TFS (Team Foundation Server), the references I updated to NuGet Packages all have the warning icon on them. Neither building nor cleaning and rebuilding fix the references.
If I click any NuGet reference in a project, the references all appear to update. The warning icons disappear and the references seem to be fine. The project builds without sissue.
This has to be done for each project in the solution, though once done once it is fine and doesn't reoccur. But this is slowing down new employees and is cumbersome.
Does anyone know of something I might have missed?
The .ddl files are for packages like MVC, StructureMap, Log4Net ect
I have searched (via Google) and the only related question is one showing NuGet packages having a different icon.
You can use the Restore Nuget Packages option from the Solution Explorer by right clicking on the solution:
You can also configure Nuget Restore to run on build from the Nuget Manager Settings windows:
I have set up a TeamCity partly. Now it downloads the code from TFS and try to build it using MSBuild which was not successful. I know that I am doing something wrong. I have some library added to my code(An ASP.NET website). I know that it is not a good idea to add dll files to Version Control(TFS), but if I don't check them in, when TeamCity downloads the code, it does not have that libraries so MSBuild cannot successfully build it. I was wondering what would be the best practice to solve that issue?
For dependency management in .net I would recommend that you take a look at the TeamCity built in nuget feeds. You have a possibility to utilize a feed directly from within TeamCity, acting as a server. As you state, commiting dependencies in (any) VCS should really be avoided...
It depends on what type of dlls you're dealing with.
If they are available on NuGet.org, use NuGet and the Package Manager Console to add the references to your solution. Then just put NuGet.exe on your Build Server, and run
NuGet.exe restore YourSolution.sln
As your first build step.
If they are in-house dlls, then you have a few options. The first being, as TeNGiL mentioned, setting up a private NuGet repository, and publishing the in-house dlls, to that feed, and pulling from it within your build server.
The other option is just to create a 'References' directory in source control, which holds dlls, reference them in your solution from the source controlled directory, and then pull them down as part of your Build Configuration. This really isn't as bad as it sounds, within reason, and is a perfectly acceptable interim solution to incorporate until everyone is on board with using a private NuGet feed, or something of that nature.
Open the code in the checkoutdirectory of TeamCIty in visual studio and try and build.I am pretty sure that visual studio will give you the exact error message of what's going wrong.
Missing packages have to be restores. Use a Nuget Installer build step to restore your packages as given in image below.
I am getting the following error when running my build on Visual Studio Online (using the built-in Build Controller):
C:\Program Files
(x86)\MSBuild\14.0\bin\amd64\Microsoft.Common.CurrentVersion.targets
(3962): Could not copy
"d:\a\src\MySolution\MyProject\Trunk\packages\Microsoft.Data.Edm.5.6.4\lib\net40\Microsoft.Data.Edm.xml"
to "..\Build\bin\Release\Microsoft.Data.Edm.xml". Beginning retry 1 in
1000ms. The process cannot access the file
'..\Build\bin\Release\Microsoft.Data.Edm.xml' because it is being used
by another process.
It is never the same file either but it seems to always be either an xml or dll from the packages folder.
EDIT: I'm not sure if it is worth mentioning, but I do have multiple workspaces and multiple build definitions using this repository.
I found the problem. Completely unrelated to the error above.
I went into the msbuild log files and found this:
Failed to produce diagnostics extension's config for
MyRole\diagnostics.wadcfgx. Error : Could not find a part of the path
'd:\a\src...\MyRole\diagnostics.wadcfgx'. Done Building Project
"d:\a\src...\MyCloudProject.Cloud.ccproj" (Publish target(s)) --
FAILED.
I was missing a file in source control.
I do wonder why this error did not bubble up into my build summary. And where did that initial error come from?
I am using TFS with Using Visual Studio 2013 and have been able to work around this issue by closing all open documents that I want to check-in (seems VS locked itself out) and/or resolving conflicts. The error message is sufficiently vague so as to be useless as to the actual cause of the check-in failure.
Update 02 November 2016:
I'm not sure why VS 2013 and TFS don't play nice together via the Team Explorer Check-in Pending Changes button, but it consistently fails to launch the conflict resolver, a key piece of the check-in process.
The following works for me on VS 2013 and TFS hosted on a SQLServer Express 2014 database:
1. Launch the Source Explorer: Team Explorer tab -> Source Explorer
2. Navigate to your solution repository
3. Then proceed to do the following for each project that you want to check in:
a. Right click project
b. Check in pending changes
c. Resolve conflicts and repeat steps 3a and 3b until no pending changes remain for the project