I'd like to have my TFS 2103 build update some of the NuGet packages in the project to their latest versions before the build.
I've written a pre-build script to do this by invoking the nugget.exe update command:
& .\.nuget\nuget update ".\XXX.Main.Web\XXX.Main.Web.csproj" -Source Initial -Safe -Id XXX.Feature.Test -Verbosity detailed
The log file contains:
Looking for installed packages in 'packages'. Updating
'XXX.Main.Web'... NuGet.CommandLineException: Unable to find
'XXX.Feature.Test'. Make sure they are specified in packages.config.
I've tried running the command manually on the build server from the command prompt and it works as I would expect. I've also checked that script is being run from the correct folder.
The package certainly exists in Packages.config.
Has anyone managed to get nugget.exe update working successfully within a TFS powershell script?
After much head scratching I've found that the pre-build script is run pre fetching the packages from NuGet. Running the powershell script manually after the build had completed was fine as the packages has subsequently downloaded.
The NuGet message is somewhat misleading.
My solution is to run a NuGet.exe restore command prior to runing the update command and everything now works.
Related
I attempted in building the .NET Standard Library Project using .NET Framework 4.6.1 from Command prompt using MSBuild Commmand. I manage to succeed building the project from command prompt.
I tried the same MSBuild command to build the project from Teamcity Command line build step, but ended up getting the following error:
C:\Program Files (x86)\MSBuild\Microsoft\NuGet\Microsoft.NuGet.targets(140,5): error : The package Microsoft.NETCore.Portable.Compatibility
with version 1.0.1 could not be found in C:\Windows\system32\config\systemprofile\.nuget\packages\. Run a NuGet package restore to download the package.
I tried Restoring nuget.exe restore mysolution.sln but noting works.
Please help me to compile the solution from Teamcity command line step. Its strange to get compiled from command prompt but not from teamcity command line.
Looks like there is a known issue in NuGet when restoring packages using the LocalSystem account wherein the packages cannot be accessed under the C:\Windows\system32\config\systemprofile\.nuget\packages folder, even though account permissions should allow it (see this GH issue). The current recommended workaround is to use the NUGET_PACKAGES environment variable to specify another location for the packages (e.g. C:\NuGet\packages).
Title pretty much says it all. I have a project which uses some nuget packages. All are downloaded but two of them (HTMLAgilityPack and Newtonsoft) are never installed i.e. the .nupkg file is not extracted, thus, the required .dlls cannot be found and the build fails. Here's the part of the build log file showing when the packages are restored on the build server:
Target "RestorePackages: (TargetId:587)" in file "##\nuget.targets" from
project "##.csproj" (target "ResolveReferences" depends on it):
Task "Exec" skipped, due to false condition;
Task "Exec" (TaskId:360) Task Parameter:Command="##\nuget.exe" install
"##\packages.config"
-source "https://nuget.org/api/v2/" -RequireConsent -solutionDir
"##\Sources\" (TaskId:360) Task
Parameter:LogStandardErrorAsError=True (TaskId:360) "##\nuget.exe" install
"##\packages.config"
-source "https://nuget.org/api/v2/" -RequireConsent -solutionDir
"##\Sources\ " (TaskId:360)
Successfully installed '###.Utilities.Excel 1.0.0.0'. (TaskId:360)
Successfully installed '###.Utilities.FileIO 1.0.0.1'. (TaskId:360)
Successfully installed '###.Utilities.String 1.0.0.0'. (TaskId:360)
All packages listed in packages.config are already installed.
(TaskId:360) Done executing
task "Exec". (TaskId:360) Done building target "RestorePackages" in
project "##.csproj".: (TargetId:587)
As you can see, HTMLAgilityPack and Newtonsoft are not installed as part of the RestorePackages task. Why would TFS build download but not install these packages?
As you wrote, an old nuget.exe will do this.
What I do is take the "..nuget\nuget.exe" out of the equation.
I put nuget.exe on the build server.
I store them like this:
C:\MyProgFiles\NuGet\2.8.6\nuget.exe
C:\MyProgFiles\NuGet\3.3.0\nuget.exe
You might ask why I keep the olders. There are occasionally issues with the newest build.
Then on my builds, I setup the build server, I essentially run this:
"C:\MyProgFiles\NuGet\3.3.0\nuget.exe" restore c:\builds\1\SomeDirectory\MySolution.sln -NoCache
Obviously, you'll use macros instead of hard coded paths.
This will (obviously) restore the packages.
I use "NoCache" because occasionally our private nuget cache has things removed......which are cached on the build server. The nocache arg will find this issue sooner than later.
If anyone else comes across this it could be that the nuget.exe you're using to restore the packages is outdated. In my case the project I was working on was started by someone else 2 years ago, I added a relatively new nuget package and the old nuget.exe wasn't compatible with it. You can download the latest version of the nuget.exe here
.
I had problems with VS Online and nuget-restore. It would report that it couldn't find packages, which Visual Studio 2015 found and installed. So I specified in nuget's targets file to use APIv3 and APIv2. Since than, all nuget packages are always found, but I'm starting to experience different, rather random, errors with npm.
I've a pre-build script (configured in my project file) which installs all necessary npm and bower packages, and afterwards runs gulp. This works fine locally, and most of the times also online. But every ~4th time on average, I get an exception similar to this:
EPERM, open 'C:\NPM\Cache\fedb6d47-PM-Cache-clone-1-0-2-package-tgz.lock'
or this:
EPERM, open 'C:\NPM\Cache\ca5822dc-sh-isarguments-3-0-4-package-tgz.lock'
I was working on the gulpfile in the beginning, so I thought some of those changes caused it, but now, I'm not even touching that project anymore, and it compiled fine until suddenly I got this error again.
In the meanwhile, I've added a tiny change to commit and push it, and it compiles fine again. Any idea what can cause this and how I can at least reduce the risk of getting that error?
Here is my pre-build powershell script:
param($build_config)
$webProjectName = "WEB_PROJECT"
$scriptpath = $MyInvocation.MyCommand.Path
$dir = Split-Path $scriptpath
cd $dir
cd ..\src\$webProjectName
echo "npm install"
npm install
echo "bower install"
bower install
echo "gulp $build_config"
gulp $build_config
Update:
I used to execute that powershell script via
PowerShell -File script.ps1
and after switching to
PowerShell -NonInteractive -NoProfile -Command script.ps1
it seemed to have fixed the error, however after ~20 successful builds, I got again a similar problem (although much less often now)
Further investigation shows, there might be some problem with the network connection or a proxy, which is weird, because bower install always succeeds. Anyhow, the solution which is working quite well for me is the following:
use the native npm install build step from visual studio online as a first step
add an environment variable to the build service in order to identify in your script, that it's running on the build server (I called it VSO and assigned it the value 1)
check in your script if it's running on the build server or not, in powershell you can do it like this:
If ($env:VSO -ne 1)
{
echo "npm install"
npm install
}
I installed paket from nuget in Nuget Package Manager Console with:
Install-Package paket
I then tried to run paket convert-from-nuget. It stalled out on a user prompt (it wouldn't let me type into the package manager console). My next thought was to run it from command line, but how to do so is not documented.
Just putting paket convert-from-nuget into a standard dev command prompt results in an error saying "paket" is not recognized.
How do I run paket from the command line or powershell, and how do you specify which solution to work against?
The way to setup paket in your repository is as follow:
1 Download a release of paket.bootstrapper.exe
This is a lightweight utility which obtains and updates paket.exe, pick stable release from official release page:
https://github.com/fsprojects/Paket/releases
2 create a .paket folder
md .paket
3 put the downloaded bootstrapper in this folder and invoke it
cd .paket
paket.bootstrapper
now you have an up-to-date paket.exe ready to ease your handling of dependencies.
4 convert from nuget
cd ..
.paket\paket convert-from-nuget
Please checkout the https://github.com/fsprojects/Paket.VisualStudio also for Visual Studio plugin to help you authoring paket.dependencies and paket.references file
Please also join https://gitter.im/fsprojects/Paket if you have any questions.
The Chocolatey package modifies the PSModulePath envivornment variable. I've observed that sometimes that modification isn't picked up until the system is restarted (or at least not until the user logs out and back in again). In the meantime, you can import the module using:
Import-Module <path-to-packages>\Paket.PowerShell\Paket.PowerShell.psd1
The packages path is usually something like C:\Chocolatey\lib. OTOH, re-reading your question, are you referring to the Nuget inside of Visual Studio? If so, that downloads from NuGet.org and that pkg puts paket.exe in $(SolutionDir)\packages\Pakget.1.18.5\tools\paket.exe. Your version number may varying.
Unfortunately the fact that PowerShell V5 introduces Install-Package (which downloads from Chocolatey by default) is going to get a little confusing vis-a-vie the NuGet Package Manager Console's Install-Package in Visual Studio.
I was trying to use Nuget as a software deployment system (repository, versioning and delivery) - idea from Octopus. Previously I was packaging ASP.NET sites into a self-extracting RAR archives with a .CMD startup scripts embeded. Now I'm trying to use Nuget creating puckages during automated build. The issue is that the package installation scripts (tools\Install.ps1 or tools\Init.ps1) do not execute if the package is being installed using command line:
nuget.exe install <package_id> -OutputDirectory <install_folder> -source <local_repo>
Same scripts are able to execute when package installed from Visual Studio Package Manager or Console.
I do not see why this shouldn't be possible given omnipresence of PowerShell.
Am I missing something or this is behaviour by design? Will appreciate you help.
Yes, we did consider MSDeploy but we already have install scripts that do the same thing and give more control and we need some strong package management and repository for build artifacts (something that Java folks do with Maven).
As of today, the powershell scripts are not invoked from doing installations from command line.
One reason for this is that, in general, most of the install/init actions are tied to dte and the visual studio project and doesn't add much value to be able to run it from outside VS.
We have a backlog item for enabling support for exe based scripts too in addition to powershell.