I’ve recently banged my head against a simple, yet annoying problem with Team Build and the way build result files are published to the so-called drop location. In my case, this location is a share on our file server. Knowingly, the build service executes under a TFSBUILD account which I have given Co-Owner permission level at the share.
Everything builds and results are published, yet all builds are only partially successful. Digging around the somewhat unmanageable BuildLog.txt file I see that Test results from MSTest is published via a call to http://tfs:8080/Build/v1.0/PublishTestResultsBuildService2.asmx which subsequently fails with this error:
The results directory “\\fileserver\tfsbuilds\BuildFolder.1\TestResults” could not be created for publishing.
The solution is quite simple. Since the actual publishing of test results is done by the PublishTestResultsBuildService2 service, executing under the TFSSERVICE account, we also need to give that account Co-Owner permissions to the drop location share.
Obvious? I think not
Using the VSSConverter tool you can import source code including revision history from Visual SourceSafe into Team Foundation Server. The thing to do is first run the tool in analyze mode which will scan your VSS repository for problems and also generate a user mapping file that will come in handy later on.
First, you need a settings.xml file. If you’re not too happy with doing xml-in-notepad configuration, there is a GUI tool to help you out. The format isn’t too hard so I went ahead and created it by hand and came up with something like this:
<?xml version=”1.0″ encoding=”utf-8″ ?>
<VSSDatabase name=”C:\path-to-vss-repository“ />
<UserMap name=”Usermap.xml“ />
<SQL Server=”your-existing-sqlserver“ />
<Project Source=”$/ProjectX“ Destination=”$/ProjectX“ />
<TeamFoundationServer name=”tfs-server“ port=”8080“ protocol=”http“ />
<Output file=”MigrationReport.xml“ />
By default VSSConverter wants to use SQLExpress during import. Adding the SQL element I was able to use my existing SQL Server. So with this stuff in place, the analyze mode gave me some warnings (luckily no errors) about shared files not being supported in TFS and that these would end up as independent copies. I’m fine with that but if you’re heavily relying on shared files in VSS you probably need to think twice before migrating.
Quite jolly after a successful analyze I went ahead to do the actuall migration. First, I quickly edited the Usermap.xml file to map VSS users to Windows users. Then, I was hoping that my initial
<Project Source=”$/“ Destination=”$/“ />
would work and that VSSConverter created a Team Project for each root project in my repository. But nooo. If you want separate Team projects for each top-level folder in VSS you must create these manually through the Team Explorer and then put up a Project element in the settings file for each project.
I actually had a couple of projects in VSS that I wanted to migrate into the same Team project. So I created ProjectX in TFS and imported ProjectY. So far so good. Next I tried to import ProjectZ into ProjectX and got error TF60099 slammed in my face. Seems that VSSConverter remembers the first project paths in order to do an incremental import later on, and refused to import a different VSS project. Given this tip I solved the problem by creating a sub-folder in ProjectX and configured my import like this:
<Project Source=”$/ProjectZ“ Destination=”$/ProjectX/ProjectZ“ />.
And that was it, actually. Goodby Visual SourceSafe. Good riddance, I’d say.
If you’re going to patch your TFS installation with SP1, make sure you download and install the Visual Studio Team Foundation Server Quiescence GDR first. This is mentioned in the release notes but I certainly missed it. Other than that, my patching experience was quite painless…