I have a project that i have been developing on my machine that is checked into source control (tfs).
I would now like another developer to work on the project with me. They have connected to the tfs server and configured the local workspace. However when they say "get latest version", it downloads the project as expected, NUGET restores the packages as expected. But pretty much all of the references to the packages show up as missing and thus the project will not compile.
Here is a screenshot of the issue.
Here is my NuGet.Config
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
and here is my .tfignore file
\packages
!\packages\repositories.config
I'm not quite sure what the issue could be. We are both using Visual Studio 2015 Enterprise Update 2 with TFS Express 2015 Update 2.
Any help is appreciated.
Check whether the Nuget Package Manager has updated to the latest version
Check the Nuget Package Manager setting in VS, make sure the items below are selected:
Allow NuGet to download missing packages
Automatically check for missing packages during build in Visual Studio
The problem in the end was that although i had created the .tfignore file, i had already checked in the packages folder into source control so this was having no effect.
Deleting the packages folder from the code section in the tfs webpage resolved this issue and packages now restore as expected on new target machines.
Thanks for all the help!
Related
I tried to build a project from downloaded source code using VS2017 community edition. Got following error
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. The missing file is ..\..\packages\Xamarin.Forms.3.2.0.637442-pre1\build\netstandard2.0\Xamarin.Forms.props.
not sure whats the issue. I tried
Delete packages folder and restore packages.
Delete obj and bin folder. Tried to clean rebuild.
First, restart Visual Studio, cleaning and building the solution most times is not enough.
Try unloading the project in Visual Studio and edit the csproj file.
Search for that props file reference in the file. Sometimes it gets duplicatedthe current version and one outdated version as well. Remove the old one and reload the project.
Check in your Forms, Android/iOS if the csproj is referencing the same Xamarin.Forms version,and are no strange lines/characters.
<PackageReference Include="Xamarin.Forms" Version="x.x.x.xxxxx" />
In the last resort, try to downgrade the XamarinForms version and check if it helps.
I have a few projects using numerous NuGet packages and these projects are source controlled on TFS. Whenever the packages are restored, they are automatically readded to source control.
I am using Visual Studio 2013 Update 3 and TFS 2013 with local workspaces and my NuGet version is 2.8.50313.46.
I am apparently not the only one to have this issue. Quite an amount of people have been asking this on StackOverflow but none of them were able to solve this issue or at least not with new implementation of package restore in NuGet. I tried the .tfignore in solution folder with '/packages' exclusion but it did not work either. So I am now asking for help here because sooner or later, someone is gonna checkin those files!
Thanks.
Note: There is about 20 users using this TFS, so applying an individual fix on each machine is not something I am looking into.
You can add to your solution new folder called ".nuget", under the folder put file called "NuGet.config", inside the file add the nuget configuration:
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
</configuration>
For more information: http://docs.nuget.org/docs/reference/package-restore
Right click on the solution folder -> enable nuget package restore on build.
That will create the required configuration, and also enable other team members to build the project automatically.
then you should commit the project. make sure to delete all packages. and then if possible try a new checkout on each machine.
I have a solution with 6 R&D projects in it. Recently we upgraded to Visual Studio 2013 and after upgrading the solution I added a 7th project (ASP.net MVC) which added a packages folder to my solution folder.
I recently added my solution and projects to our production share which is shared across 3 other developers. We have a libraries subfolder that our production solution references. Discussing my newly added solution and project folders to our production environment with our build developer, he would like to see the packages folder moved as a subfolder of the Libraries subfolder and all the team reference the single packages folder at that location. We do not use Team Foundation.
Since I did not tell nugget where to create the packages (they were just placed in the solution folder) is there a way to tell it where to look for the packages after I move the folder to its new location? How will the other developers configure their Visual Studio instance to look at the shared folder instead of their local machine? Assuming, once they build the solution locally it will also add a local packages folder and we don't want that.
Seems like this is pretty straight forward. In fact, NuGet site says you can share packages folder but it says you have to modify nuget.config and I don't have that in my solution. Any thoughts/suggestions are appreciated.
Nuget, in and of itself, is a package management repository. It's entire purpose is to allow you to centrally pull down packages (libraries, configurations, whatever) that you need to a place locally on your system (whether it's dev, production, whatever) without having to actually commit those libraries to your source control. Instead, any developer will just be committing a file that says the equivalent of, "Get me a package by this ID (name) and version."
This process creates a file called packages.config at the top level of every project within your solution. The file would look something like this:
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="EntityFramework" version="6.1.1" targetFramework="net45" />
<package id="jQuery" version="2.1.1" targetFramework="net45" />
</packages>
The files themselves are placed in the projects where they need to be (in the case of projects like jQuery) or, library binaries are stored at the top-level of your solution in a folder called packages and should not be checked into source control.
You can also enable "auto-restore" packages for Nuget so that when anybody checks out your project, they will automatically get the libraries and things they need in order for your project to run/build correctly.
This means that everybody gets what they need, you do not need to manage your own "library repository" (please...no shared folders!), and, at any point, you can look at the packages.conf folder to see what your project depends on.
Here are some more links on how to enable and work with Nuget for development and build systems. There are scores of other resources on the web as well.
Introduction to Nuget
Using NuGet Without Committing Packages
Package Restore
I am attempting to migrate to nuget's new Automatic Package Restore. Whilst it works fine on my own machine (packages are restored), builds performed as a TFS Build on the build server do not build, complaining that they cannot find the various dlls (that should have been downloaded as part of the restore).
I have created a nuget.config in my solution folder, as specified here:
http://blog.davidebbo.com/2014/01/the-right-way-to-restore-nuget-packages.html
I have also tried putting this nuget.config file next to the nuget.exe file in TFS, in the hope that it would be used, but to no avail.
The nuget reference here:
http://docs.nuget.org/docs/reference/nuget-config-file
states that the nuget.config in my solution folder should be picked up. But it appears that it isn't.
I'm at the end of my tether. According to nuget, the Package Restore feature is designed specifically so that packages don't need to be checked in. However, there's scant information about how to get TFS to actually restore the packages, and what I've found does not work.
Any help would be gratefully received.
My nuget.config looks like this:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<solution>
<add key="disableSourceControlIntegration" value="true" />
</solution>
<packageSources>
<add key="nuget.org" value="https://www.nuget.org/api/v2/" />
<add key="ads" value="<address to local repository>" />
</packageSources>
</configuration>
As it so often turns out, the answer is the answer to a question I didn't actually ask:
"How does TFS even know how to call nuget?"
After sitting and thinking about this for a while (and as #Matt Ward correctly points out) it occurred to me that the TFS Build has no way of knowing nuget is even involved, since the new "Automatic" package restore removes the need for it to be part of the build itself.
This question has actually been asked here:
How does TFS know about nuget?
Although the accepted answer is NOT actually the correct one. Scroll down to probackpacker's answer, which is essentially that:
"If you are using automatic package restore, you must have a build process that calls it before building your solution"
This is actually well documented at nuget:
http://docs.nuget.org/docs/reference/package-restore-with-team-build
However, I had disregarded it since a) the entire point of Automatic Package Restore is to move away from an MSBuild based process (although I do now understand why this is different), and b) it seemed more complicated than I needed. It's not. That said, a clarifying statement such as "If you are using Automatic Package Restore with TFS Team Build, you MUST create a an MSBuild project in order to call Package Restore" would have been helpful. It's obvious once you understand what's happening - confusing when you don't. But we live and learn.
depending on the version of visual studio, it should just be a matter of right clicking on the solution and selecting Enable NuGet Package restore. this will create a Nuget folder that contains, NuGet.exe, a NuGet.Targets file and NuGet.config.
you can update the targets file with a local NuGet Feed if you have one.
to test locally, delete the contents of your packages folder, and ReBuild the solution, this will download the files from NuGet and your solution should build correctly. check in the NuGet folder and files to source control, your packages should not be added to source control.
your TFS build should now be able to restore the packages
Now if this is how you are set up and it still doesn't work on TFS, log onto the build server with the build account and load the solution locally, make sure the package restore works as the build account on the build machine, you may have a firewall / proxy issue, where the build server / build account can't access the Nuget.org internet site
I have a Visual Studio project which I have committed to VisualSVN (via the VisualSVN => Commit menu in Visual Studio). I have added a number of libraries to this project via NuGet.
My colleague has downloaded the project I have uploaded to SVN (via VisualSVN => Get solution from Subversion...) and has found that these libraries are missing, and he is having to re-download them.
A few questions:
Is this by design? Or have I not committed my Solution properly? Or has my colleague not download the solution to his machine properly?
If this is by design, what is the correct way to re-add references to a solution downloaded from an SVN server? I am worried that I may have added a reference and worked with it, and that it may have been updated since so whenever my colleague re-adds the same reference via NuGet he will get a more up to date version that will be different, and this will break my program. Is this a valid concern?
Yes, this is by design. The whole concept of using Nuget is that you will not have to keep libraries in your version control system.
You need to Right Click on your solution in Visual Studio and select Enable NuGet Package Restore.
This will configure the solution to restore the NuGet packages (if any missing, or in case of none) whenever you'll do a build. Also, all the libraries that you've added for a particular project will have an entry in the packages.config created in the project's source drectory; for eg:
<packages>
<package id="jQuery" version="1.8.3" />
</packages>
This way NuGet makes sure everybody gets the same version.
Just enable "Nuget package restore" in your solution and packages will be automatically downloaded during the build:
http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages