Honestly, VSTS private NuGet feeds will be a most blogged topic in this blog! I’ve already mentioned them at least twice. Here goes another post:

This time I’m building in VSTS Core application and the build literally goes:

  • dotnet restore
  • dotnet build
  • dotnet test
  • dotnet publish

And this worked really well for the basic application – I had it set up in minutes and got the resuilt I was looking for.

But during the life of the application I needed NuGet packages from my private feed and dotnet restore had no idea about my private feeds.

Even if supplied with nuget.config file I was getting 401 Unauthenticated – this is because I was not keeping my password(token) in this file.

Solution was to add this feed globally on the agent for every build. And this turned out to be easier than I thought.

In your build add a new task called Nuget Command:

When you configure this task give sources as Command parameter. And for arguments put this:

add -Name MyFeedName -Source https://MyProject.pkgs.visualstudio.com/_packaging/MyFeedName/nuget/v3/index.json -username myUsername@MyTeamName.onmicrosoft.com -password $(System.AccessToken)

My build task looks like this:

Replace the names accordingly. This adds a NuGet source to the agent. This $(System.AccessToken) is getting build variable that contains an access token – it is generated for every build you run, so no need to keep it around in your build script or nuget.config.

To make the token available you need change the toggle in build Options: Change Allow scripts to access OAuth Token to Enabled:

This way when you run dotnet restore your private feed will be available and it will use OAuth token that authenticates with the private package feed.

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.

Disclaimer

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.

Continue reading

There is a follow-up article about integration tests in 2016. Recommended for reading if you are using VSTS and looking at Cake build system

Unit tests are fine and dandy, but if you persist your data in database, persistence code must be tested as well. Some possible bugs will never be picked up only by unit tests. One of the issues I’ve been burned by is entity validation, another is a missing foreign key relationship.

Validation issues can burn you very easy. Look at this bit of code:

public class Person 
{
    [Key]
    public Guid PersonId { get; set; }

    [Required]
    public String FirstName { get; set; }

    [Required]
    public String LastName { get; set; }
}

public void CreatePerson(string firstName, string lastName)
{
    var newPerson = new Person();
    newPerson.FirstName = firstName;

    // dbContext was injected via constructor
    dbContext.Persons.Add(newPerson); 
    dbContext.SaveChanges();
}

NB: This is just a sample code. Nowhere in my projects we do such things.

Continue reading

At the moment I’m using excellent service from Microsoft: hosted TFS. The service is still in the preview (15 July 2013) and some features are in beta, but it works pretty smoothly already. One of the things I had to learn is how to use TFS as a build server. I’ve used to nice TeamCity with almost drag-and-drop build steps and simple configuration management. TFS is using XAML definition file to drive the build process. The default template that comes with any project is pretty much covers everything you might need when you start, but it is very complex and when you try looking on the XAML diagram, you might want to run away – it’s that big and complex. That’s what I did first time I looked on the XAML processes. Run away and installed TeamCity.

Now I’ve decided to give it another go. I’ve started from enabling nUnit tests on build server. By default TFS only works with MSTest. To enable nUnit, you need to add nUnit assemblies and nUnit to MSTest adapter to your source control. The process is perfectly described in this post by Ajay Majgaonkar. I’ve also seen the description of the process in some Microsoft documentation, but have lost the link.

Continue reading