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.

4 thoughts on “How I failed using MSTest on TeamCity without Visual Studio

  1. I ended up replacing all MSTest-based tests with NUnit. Works like a charm (and from VS UI is much faster for some reason).

    MSTest is a source of constant frustration – even if VS is installed, it fails here or there from time to time and integrates poorly with other tools. As a consequence – when some test is broken you could only guess if it is an MSTest problem or bug in your code. Before working with MS unit-test framework I always assumed my code is the weak link… as always, for each rule there are exceptions somewhere 🙂

    1. I had neither choice to convert all unit tests to NUnit test nor time. On a different project a have created a hybrid solution (conditional compiler directives) – MSTests and VS.NET code coverage support in VS.NET and NUnit tests on TeamCity.

      This unfortunate feature should be fixed in MSBuild 2012.

Leave a Reply

Your email address will not be published. Required fields are marked *

Blue Captcha Image