Posts tagged ‘TFS’

TFS 2015, Xunit transform to Trx

It turns out I was wrong in my last post about transforming nUnit tests to Trx ( Ms Test ) format for display in TFS 2015. It fails short as the nUnit format that xUnit spits out does not have any console or standard out traces. Therefor when you want to view more information about your tests or error traces on failures non are available. I went down the road to use the nUnit format because TFS was supposed to take it and display it in TFS without tranforming to Trx but that does not work. So the solution is to use the xUnit Xml V2 format by passing the -xml switch to xUnit. Then convert the xml to Trx using your Xslt transform. Mine is here on GitHub if you want a copy.

Could not load type Microsoft.VisualStudio.Services.Common.VssHttpClientBase

If your getting the following error on your TFS server web interface odds are that you are using incompatible version between TFS and VS or other Microsoft product. The object in question was moved from the common Dll to another. In my case I installed TFS RC and then never version of VS2013, after that I got the error.

Could not load type ‘Microsoft.VisualStudio.Services.Common.VssHttpClientBase’ from assembly ‘Microsoft.VisualStudio.Services.Common, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’.

To remedy the situation I upgraded TFS 2013 with the RTM version. After the upgrade I’m not getting the error anymore ant the TFS web interface works as expected.

Nant, Tf Unable to determine the workspace

I was using Nant to checkout files in a build script and got the error “Unable to determine the workspace” from Team Foundation Server repository. The trick is to reset the cache first, run this command
tf workspaces /s:http://yourserver.com:8080 /noprompt
from your Nant script before doing any checkouts etc, then it should work.

TeamCity update to version 4.5.5

I Just updated our TeamCity environment to version 4.5.5 today, we were running 3.1 before. I had resisted an update as I always do because things just break when you update software. Since we are having some network issues it was a perfect time to take the plunge. That is after we discovered that TC 4.5+ can use Team Foundation Server repository. As the MsBuild just is not mature enough yet and there are weird quirks all around we are going to use combo TC and TFS setup for a new project we just started. Mainly running the build using nant and nunit of course.
Back to the update, I took a backup of the TC server directory just in case. Then fired up the install, the install recognized the old version and offered to get rid of it for me. The install ran fairly quickly and picked up all the configurations from the last install. After the server was up the build agents got pushed to the new version and came online in a matter of couple of minutes, now that is sweet. No manual installs on the build agent machines, its auto ! Then I just kicked off a build and everything was business as usual, it can’t get any better than this.

Team Foundation Server, msbuild unittest code coverage

If you are like me and wonder how much coverage your unittests have you can add coverage to your Team Foundation Server builds and see for yourself.

Note, I have only tried this using VS2008

First right click /Solution items in your solution explorer Add new item, choose Test run Configuration, let’s name it CodeCoverage.testrunconfig

Choose Code coverage on the left and choose the dll’s you want covered, save and check it in.

In your build.proj file find the first PropertyGroup, at the end of it add the line about the config file. You will need this in order for MsBuild to find the configuration. Then it will look similar to the xml below. Note the path, in my case I had to add \MYPROJECT to the mix as that’s where my source gets checked out on the build machine. You can see where that is on the server or check the build log and look at what directory the file is checked out to.

<PropertyGroup>
    …. snip
 
    <RunConfigFile>
        $(SolutionRoot)\MYPROJECT\CodeCoverage.testrunconfig
    </RunConfigFile>
  </PropertyGroup>

The coverage numbers will show up in the Unittest section of the build report. It is of course important to remember a well covered code does NOT mean that your unittests are any good. Most likely they are but the coverage number just means how much of the code was touched during the unittest run.