Tag Archives: TeamCity

Building solution with multiple NuGet package projects on TeamCity

Let’s say you have a solution with projects in it and some projects represents NuGet packages. I know it is not ideal, but the NuGet package project are really small and I didn’t want to create solution for each individual project. And also they are share some code. And I didn’t want to publish all the packages when I made changes to one project only not affecting the others

A good example is a solution with UI controls – each project representing a group of UI elements or a single element. Like set controls from a big controls vendor – I imagine the solution is quite big with projects like grid control, map control, charting, etc. By adding a NuGet package projects you can keep these distributed separately – one package for grid (ComponentVendor.UI.Grid), one package for maps (ComponentVendor.UI.Maps), etc. End-users do not have to download one big massive package (ComponentVendor.UI) which will make them to delete the unused references later.

The solution structure

  Maps.NuGet (references Maps)
  Grid.Nuget (references Grid)

The first step was to create a TeamCity project for the solution and build configurations for:

  • root – build the entire solution (that’s why you set up the CI build) with VCS root pointing to source control root of the solution and with UI.sln as build file
  • all packages – manually triggered distribution all the packages at once
  • each NuGet package project

Setting up the build configuration for NuGet package project:

build steps

  • create new VCS root that points to the project source control directory to “isolate” this project from changes made in other projects
  • add VCS root checkout rule: +:.=>ProjectDirectory, this will checkout the sources into this directory NuGet build step
  • set MSBuild build file to .csproj file
  • add build step to create NuGet package with .csproj file as specification file and ProjectDirectory as base directory NuGet build step

The build and publication of the package is triggered by changes made to package project, for example by changing the package version.

How I failed using MSTest on TeamCity without Visual Studio

I was setting up a continuous integration for one project. I have configured a build step in TeamCity to build the solution and another to execute unit tests using MSTest. And that failed – the reason was Visual Studio was not installed on that machine. I googled around and found some useful posts:

The key components for running tests are MSTest.exe and QTAgent.exe. So I copied all the files to desired locations, I didn’t added the DLLs to GAC, opened command line and executed MSTest.exe and …

… an exception! Could not load file or assembly xxx.dll

So I found that DLL on my computer and copied it to directory with MSTest.exe, then fired MSTest.exe and another assembly load exception and again and again.

Because I could I installed VS.NET 2012 on that machine just to avoid this eternal cycle.

For those who can’t I used Fusion Log Viewer (fuslogvw) to log all assembly bindings to disk and then analyzed the files in LinqPad to get the list of loaded DLLs and their locations. See the attached file (some of the binded DLLs might be required by the tested project).

Hope this will help someone.