Is it possible to trigger a NuGet v2.x package restore when trying to build a VS2010 solution using CruiseControl.Net?
We've recently set up CCNET and are simply trying to trigger a test build of our main solution. Many projects within the main solution have NuGet package restore enabled. The packages folder is not committed to our VCS. Because of the new "feature" of having to consent to the package restore in Visual Studio, MSBuild is failing when it hits the restore package target in the nuget.targets file.
If it is possible without drastic changes to every project that uses NuGet or to write a custom build script, what is the best way to accomplish the package restore?
from http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages
To enable package restore for build servers without Visual Studio installed, you can also set the environment variable EnableNuGetPackageRestore to "true".
Related
As per the title, I want to know if it's possible to set NuGet Package Manager to install any package updates automatically.
I've looked for and found an answer to this on here but it's not specific enough to my situation, I don't think (Question: Is there a way to automatically update an installed NuGet package in Visual Studio?). My code is for automated tests rather than anything that would be released on a regular basis. The only time we'd change any of the code would be to add or amend existing tests.
I'm quite early on in my automated testing career so any advice would be greatly appreciated.
Thanks,
Sheridan
I want to know if it's possible to set NuGet Package Manager to install any package updates automatically.
There is no such option can be set directly to NuGet Package Manager to install nuget package updates automatically. But you could add a simple command in the pre-build event to achieve it, like:
nuget.exe update "$(ProjectDir)packages.config"
With this pre-build event, VS/MSBuild will update all installed packages in your project when you build your project.
Note:
Since nuget.exe is not a windows internal command, so you should add nuget.exe to the system environment variables, otherwise you should specify the full path of nuget.exe, like:
"C:\Users\<uasername>\nuget.exe" update "$(ProjectDir)packages.config".
I'm training 5 people on using Visual Studio. They've mapped their drives and have "downloaded" the solution from TFS which contains 10 projects. All located at the same depth in TFS folder structure. When the new folks download the solution there's one project that doesn't get the NUGET references even though the Package folder (created by NUGET) is at the same depth of the other 10 projects when viewed in TFS.
We know how to add these manually but is there a way to automatically have VS do it? Why would only one project lose it's reference with the Package Folder right there?
It seems you are still using MSBuild-Integrated package restore approach. If NuGet recognizes that the MSBuild-Integrated package restore approach is enabled for the solution, Automatic Package Restore is skipped.
You need to migrating MSBuild-Integrated solutions to use Automatic Package Restore, then the packages will be restored automatically.
In addition, you need to update you NuGet manager to the latest version in VS Tools--Extensions and Updates. And make sure Visual Studio is configured to 'Allow NuGet to download missing packages' and 'Automatically check for missing packages during build in Visual Studio' in VS Tools--Options--NuGet Package Mnager--General.
To Fix:
Unload all projects first, then right click and select edit project.
Find this line:
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
Comment it out.
Reload all the projects and compile.
This applies to Nuget api version 2.
Note you may configure all projects for Nuget at the solution level.
The package manager for the solution presents a set of check boxes for every project along with the buttons (Install or Uninstall).
We have a solution which contains several projects. Some projects have NuGet packages installed, for example Json.NET. The whole solution is checked in to TFS Version Control, without the packages folder. We have set up Automatic Package Restore according to the "Nuget 2.7+ method" as described in the Nuget documentation (actually we didn't set up that much since all this is enabled by default).
When we build this solution on another computer, all packages are getting restored.
When we build this solution on our TFS 2013 Build server, all packages are also getting restored.
Now here comes the problem:
When we create a build on our TFS 2013 Build Server which should build only one of the projects in the solution (so targeting the .csproj file instead of the .sln file) the nuget packages are NOT getting restored!
Can anyone tell me why this is happening, or tell me if this is by design? I really don't want to build the whole solution, since it is a release build for only a single small project, but i do want the packages getting restored automaticly...
I believe the Automatic Package Restore hooks into the Build Solution event. Since there's no solution, it's not triggering the restore.
To build a single project, you may need to create a new solution that references just that project.
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.
Nuget does not execute scripts when restoring packages in a project.
Here's the scenario: I have a project that has a custom NuGet package installed. This project has NuGet Package Restore enabled for the solution. This all is working flawlessly, which I tested multiple times by getting the project from TFS onto a empty folder.
I've added init.ps1 and install.ps1 to the nuGet package, and the package is still fetched and installed properly, but the scripts do not execute unless the package is installed manually.
To be exact, if I get the project from TFS for the first time, neither init.ps1, nor install.ps1 executes.
However, if I close the solution and reopen it, init.ps1 executes (as expected), but, of course, install.ps1 still doesn't since the package has already been restored/installed.
Both scripts execute normally when the package is installed/uninstalled manually (i.e. it doesn't run if the package is "restored").
My internet searched haven't turned up any references to this behavior. Am I missing something obvious, or is this normal when packages are restored?
The Package Restore feature is used so that not all the packages are checked into source control. As such the only thing that it does is pull down the NuGet packages into your ./solution/packages folder so that the assembly paths and references can be correctly resolved at build. NuGet does not do a re-install as part of restore, meaning that it will not do any xml file transforms or run the PowerShell install/uninstall scripts in restore.