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.
You are currently browsing articles tagged TFS.
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.
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>
…. 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.