JetBrains TeamCity 5.0 released

JetBrains released a new version of TeamCity, a popular build management and continuous integration server. The release includes a number of important new features:

In the past, if you owned a license to a previous version of Team City Enterprise Edition, you qualified for a free upgrade. Unfortunately, this is no longer the case. With TeamCity 5.0, JetBrains requires you to buy an annual subscription at $999 per year in order to qualify for an upgrade.

The Professional Edition that supports up to 20 user accounts and 20 build configurations is still available at no cost.

Happy coding!

NUnit 2.5 GUI cannot locate iBatis.NET sqlMap.config

NUnit 2.5 was released last month introducing a large set of new functionality into the NUnit framework. If you are using an earlier version of NUnit today, take a look at the following new features released in 2.5:

  • Parameterized, data-driven tests
  • New constraints
  • New asserts
  • Theories
  • Distributed parallel tests
As in previous versions, NUnit 2.5 allows running tests from multiple assemblies by using NUnit test project files. We find a lot of value in using these files on local development workstations. However, our automated build and continuous integration server, TeamCity 4.5.1, does not support NUnit project files and requires all test libraries to be listed manually. As a result, TeamCity executes tests with the value of AppDomain.BaseDirectory set to the location of the executing assembly. While we used to be able to configure the same behavior in previous versions of NUnit, NUnit GUI 2.5 no longer updates AppDomain.BaseDirectory at the assembly level and is likely to fail your unit or integration tests when they rely on the AppDomain.BaseDirectory value.

We came across this issue while upgrading our persistence tests. When iBatis.NET Data Mapper was used, tests succeeded on the build server but failed locally (could not find sqlMap.config or properties.config). I looked into the iBatis.NET 1.6.1 source code and noticed that the framework uses AppDomain.BaseDirectory to load its configuration files. To fix the problem, update AppDomain.BaseDirectory to the location of the executing assembly before creating the iBatis.NET Sql Mapper:

var  assembly =  Assembly.GetExecutingAssembly();
var  applicationBase = assembly.CodeBase.Substring(0, assembly.CodeBase.Length - assembly.ManifestModule.Name.Length);
AppDomain.CurrentDomain.SetData("APPBASE", applicationBase);

Contact us if you are interested in upgrading your applications to NUnit 2.5 or configuring them for TeamCity. Happy coding!

How to automatically fail TeamCity 4.0 build when MSTest 2008 webtests fail

Out of the box, there are two options to configure MSTest 2008 webtests with TeamCity 4.0 build server. The first option is to add webtest names to the MSTest assemblies list. The second option is to specify MSTest configuration and .vsmdi metadata files. In both cases, TeamCity 4.0 does not fail a project build when webtests fail. Nor does TeamCity display webtests results as it does for unit tests.

To solve this issue, we created a custom command-line file to execute MSTest webtests:

set ConfigPath=<Path to your webtest configuration and .vsmdi files>
set ResultPath=<Path to .trx and .txt result files>
set MSTestPath=<Path to your MSTest.exe>

"%MSTestPath%\MSTest.exe" /runconfig:%ConfigPath%/Your.testrunconfig
/resultsfile:%ResultPath%\Your%1.trx >> %ResultPath%\Your%1.txt

if not %errorlevel% == 0 exit 1

This file takes a build number as the first positional parameter, executes webtests listed in Your.vsmdi, and saves .trx result file as well as the execution summary report so that TeamCity could store them as build artifacts. We then configured a dependent build configuration to run this command-line file as part of our build process.

Happy coding!

MSTest 2008 results file does not get refreshed when tests are executed in TeamCity 4.0

We run into a locking issue last week while setting up MSTest 2008 with TeamCity 4.0. We recommend using NUnit instead of MSTest, but MSTest 2008 is supported by TeamCity 4.0 and we did not anticipate any problems using it. The first build worked correctly as expected, but the second and all subsequent builds did not seem to execute any tests and did not overwrite MSTest results file created by the first build. All builds were displayed as successful and all included MSTest results from the first run!

I looked closer into the build logs and noticed the following entries:

  • "The results file 'C:\TeamCity\...\tests.trx' already exists. Please specify a different results file or verify the existing file is no longer needed and delete it."
  • "The command 'C:\...\mstest.exe' /testcontainer..." exited with code 1.

When I tried deleting the results file manually, I received the "Error Deleting File or Folder" exception. The file was locked by TeamCityAgentService-windows-x86-32.exe -> java.exe process.
To resolve this problem, we ended up naming our MSTest results file name as tests%env.BUILD_NUMBER%.trx. This way, each new build generates a brand-new results file. Note that this solution requires you to delete historical .trx files on a regular basis, which could be easily accomplished with a command line script.

Happy coding!

Welcome to ModelBlog

Thank you for visiting ModelBlog. We hope the time you spend with us will be both entertaining and worth your while. Have fun!