I keep migrating my build scripts into CakeBuild system. And I keep running them on VSTS. Because mostly VSTS build system is awesome, it is free for small teams and has a lot of good stuff in it.
But working with NuGet on VSTS is for some reason a complete PITA. This time I had trouble with restoring NuGet packages:
'AutoMapper' already has a dependency defined for 'NETStandard.Library'.
An error occurred when executing task 'Restore-NuGet-Packages'.
Error: NuGet: Process returned an error (exit code 1).
System.Exception: Unexpected exit code 1 returned from tool Cake.exe
This is because Automapper is way ahead of times and VSTS uses older version of nuget.exe. If I run the same code locally, I don’t get this error. So I need to provide my own
nuget.exe file and rely on that. This is how it is done in Cake script:
var settings = new NuGetRestoreSettings()
// VSTS has old version of Nuget.exe and Automapper restore fails because of that
ToolPath = "./lib/nuget.exe",
Verbosity = NuGetVerbosity.Detailed,
Note the overriding
ToolPath – this is how you can tell Cake to use the specific .exe file for the operation.
Cake Build system has an integration point with most build systems like Team City, AppVeyor, Bamboo, etc. But there is not much for Visual Studio Team Services (VSTS). There is a Cake Build Task that facilitates execution of Cake script on VSTS build agent, basically a wrapper around
But if you need to reach into any of the VSTS build process variables or call any of their API – you are on your own. And we are migrating our grand-project to be built on Cake and with VSTS.
And one of the pain points were NuGet feeds. We are consuming private nuget feed from VSTS and we are pushing a NuGet package into a private VSTS feed. Both of these actions require feed authentication. And VSTS authentication is painful.
First time I have tried TFS Build feature a few years ago and that was on hosted TFS 2010 version. And I hated it. It all was confusing XML, to change a build template I had to create a Visual Studio Project. I barely managed to get NUnit tests to run, but could not do any other steps I needed. So I abandoned it. Overall I have spent about 3 days on TFS. Then I installed Team City and got the same result in about 3 hours. That is how good TeamCity was and how poor was TFS Build.
These days I’m looking for ways to remove all on-prem servers, including Source Control and Build server. (Yep, it is 2016 and some companies still host version control in house)
Visual Studio Team Services Build – now with NuGet feed
Recently I’ve been playing with Visual Studio Team Services Build (used to be Visual Studio Online). This is a hosted TFS server, provided by Microsoft. Good thing about it – it is free for teams under 5 people. At the end of 2015 Microsoft announced a new Package Management service. So I decided to take it for a spin. So today I’ll be talking about my experience with VSTS build, combined with Package Management.
I’m not associated with Microsoft, nor paid for this post (that’s a shame!). All opinions are mine.
VSTS is moving fast with new features popping up every other week. So information in this post might become out-of date. Please leave a comment if things don’t work for you as expected here.
C# package in private NuGet feed
Today I actually need to create a C# library for internal use and publish it to a private NuGet feed. So I’ll write down my steps for future generations.
For the purposes of this guide, I presume you already have VSTS project and have some code in it. You also know what CI is and why you need a build server.