VSTS – Package Manager with NuGet

As our project has grown we have identified a number of occurrences where the same assembly is being used across a number of different branches. To improve the management of this single assembly I have been using the VSTS Package Manger to create a NuGet package that we can consume within these projects. This post is about my experience of using PM for the first time and some of the things I learned along the way. At the bottom of the post are links to URLs that I used to help me.

You can create a NuGet package on your machine using the NuGet CLI and upload it to the Package Manager manually. This is a good place to start if you want to get something into the PM and see how it looks when you pull down the package in Visual Studio etc. I found using the NuGet CLI to create the .nupkg file helped me to understand what would be required to make it part of a CI build. The NuGet CLI and VSTS NuGet Task allow you to build from either a .csproj (.vbproj) or .nuspec file. To create a .nuspec file for your project use the NuGet CLI with the spec command. The .nuspec file allows you to set the metadata for your project and include replacement tokens that can be substituted from the CLI. After creating my basic .nuspec file I can then run the following NuGet command to create my first package.

nuget pack MyCompany.MyProject.csproj -Build -Properties configuration=debug;description=My first NuGet Package;author=MyCompany -Verbosity Detailed

The -Properties argument defines what replacement tokens are substituted in the .nuspec file. If your project has an AssemblyInfo file but does not contain an entry for AssemblyCompany or AssemblyDescription you must provide these in the command line or the pack command will fail. (See the Replacement Tokens section for more information). The configuration=debug defines which project configuration will be built with the -Build flag. QUICK TIP – if you run the NuGet commands in PowerShell you need to escape the semi-colons using the opening single quote character (`).

The version number of your .nupkg will be taken from the AssemblyInformationalVersion (if available) or the AssemblyVersion entry within the AssemblyInfo file. If you are using a SharedAssemblyInfoFile (SolutionAssemblyInfoFile) to store common values then these need to be defined in the NuGet pack command -Properties as version=x.x.x.x or using the -Version argument.

At this point you can upload the completed package to the Package Manager following the instructions available here. Having created a .nupkg on my own machine the next  stage was to do this as a task of a build process. The current documentation of creating NuGet Packages during the build is a little out of date at the time of writing this article as it refers to the deprecated NuGet Packager task, however there is now a single NuGet task with the different NuGet commands as an option. When I first tried the NuGet build task the problem was making sure that the NuGet task could find the files to include in the .nupkg. To solve this problem I had to make sure the Visual Studio build task, for the .csproj, placed the files in the right location. This was achieved by adding the following MSBuild Argument /p:OutputPath=$(Build.SourcesDirectory)\MyCompany.MyProject\bin\$(BuildConfiguration) .

The .nuspec file included the source control ensures that common settings for the .nupkg are retained for each build. The NuGet Pack task allows for the setting of Pack Options for versioning, however for my build I set this to off and used the used the version specified in by the AssemblyInformationalVersion. I also specified some additional build properties (-Properties attribute) in the Advanced section.

Once the package has been created as part of the build the next stage is to include the NuGet push command task. Again, the current documentation is a little out of date as it refers to the deprecated NuGet Publisher task. To publish the package use the same NuGet task as before but this time selecting the push command. Since we have already created the Package Manager feed we just need to select this as the Target Feed in the push task. Having completed the NuGet push task, the process now has all the tasks to build the project, create a NuGet package and send it to our Package Manager. Finally, we can access the .nupkg from within Visual Studio.

URLs I have found useful on this journey

TeamCity – Upgrade to 7.1 & Migrate to SQL Server

Having gone through the process of upgrading a TeamCity server from 7.0.3 to 7.1 and then migrating to a SQL Server back end I thought I would highlight some of the problems and solutions I encountered.

First of all, this article helped me immensely in getting through the process. I followed the exact same process listed in the article to upgrade my TC server from 7.0.3 to 7.1 and then again when migrating to a SQL Server back end. The only notable difference was that I did not need to specify the SQL Server port number (1433) in the connectionUrl entry within the database.properties file. Also, before doing the upgrade to SQL Server make sure you can login to your new (empty) TeamCity database using a TCP/IP connection otherwise the maintainDB command will fail. You need to ensure that the SQL Browser service is running and then you can test a TCP connection either by;

  • Using the SqlCmd Utility and specifying the tcp protocol for the -S flag
  • Using SSMS and selecting the Options >> button and setting the Network Protocol under the Connection Properties tab

SSMS Options

The other part of the upgrade process that is worth a mention, for 7.1 at least, is the NTLM authentication. Make sure you read this article first, and complete the changes, before you complete the tasks listed in this article. Since we had made the switch a SQL Server back end I did come across one gotcha when trying to login to TeamCity after changing to NTLM authentication. As per the documentation “… on switching from one authentication to another you start with no users (and no administrator) and will be prompted for administrator account on first TeamCity start after the authentication change.” However, when I tried to create a new administrator account it would fail saying username or password is incorrect and I could not login to my new TeamCity server. To get around the problem I had to do the following;

  • Stop the TeamCity Server service.
  • Take a backup of my TeamCity database (just to be safe, but this is optional).
  • In SSMS open up the users table in the TeamCity database and look for the administrators entry in the table – this should be row #1.
  • In the auth_type column change the entry from DefaultLoginModule to NTDomainLoginModule.
  • Restart the TeamCity Server service

I was then able to login to the server as the administrator to ensure the settings were correct and new users to the system could automatically login to the TeamCity server.