Category Archives: TFS

TFS Lab Environment stuck in “Deploying” state

A few days ago we had a sudden SQL Server reboot of the server hosting the TFS databases. Though I still have to determine the cause of that, it had a nasty side effect. When the crash occurred a deployment of a build to a lab environment was in progress. This caused the lab environment to stay in the deploying state even though the build was stopped and even deleted.

To fix things I had to dive into the actual table holding the Lab environment information of your project collection (called LabEnvironments in your project collection database).

The problem was that there was still a BuildUri value in the record for my Environment. After deleting that (and seeing one more build fail). Things were back to normal again.

How to apply Web.config transformations during TFS build.

Just a simple reminder to myself, because I already had to look this up twice:

If you want a project’s web.config files to use transformations as it would when you hit deploy in VS, you need to set the following MSBuild arguments in your Team Build definition:

/p:UseWPP_CopyWebApplication=True /p:PipelineDependsOnBuild=False

And it looks like this:

Editing ‘Changed By’ and ‘Changed Date’ fields using the TFS API

A while ago I ran into a problem while developing an application that uses the TFS API to create Work Items from requirements from some other application. I wanted to maintain as much of the info that was available in the original source in the new work items. This means I wanted to edit the Changed By and Changed Date fields.

To accomplish this you have to bypass some validation rules the TFS API has in place. To do this, you have to instantiate the work item store in the following way:

var workItemStore = new WorkItemStore(collection, WorkItemStoreFlags.BypassRules);

This is however, not all, as I soon found out when I was presented with the following error, even when I didn’t even edit the Changed By and Changed Date fields:

TF26212: Team Foundation Server could not save your changes. There may be problems with the work item type definition, or a conflicting work item type definition change may require a refresh on your client. Restart your client application and try again, or contact your Team Foundation Server administrator.

With the inner exception giving me some more error numbers to google:

TF237165: Team Foundation could not update the work item because of a validation error on the server. This may happen because the work item type has been modified or destroyed, or you do not have permission to update the work item.

It turns out that you need some special permissions to be able to use the BypassRules flag. Your account needs to be in the Project Collection Service Accounts group (or the Team Foundation Service Accounts). There are plenty of reasons that it is not a good idea to put regular users in this group, therefor it is not possible to add users to these service groups using Web Access or the Administration Console.

The only way to do so is with the help of the TFSSecurity.exe command line tool. For instance if you want to add your user account to the Team Foundation Service accounts group, use the following:

TFSSecurity.exe /g+ “Team Foundation Service Accounts” “[DOMAIN]UserName” /server:https://<server>:<port>/tfs

Team Foundation Server 2012 Update #2 installation

I decided to upgrade our production instance of Team Foundation Server 2012 with Update #2 fairly fast after its release since we are starting a new sprint on monday and we have been waiting for some of the new features.

I had done some research beforehand, and Update #1 installation went without any problems whatsoever so I felt fairly confident that it would be quite easy this time around as well. Ofcourse I checked if all my automatic back-ups had run, and that was the case.

I started the installation and file copied fine, but then I started the upgrade wizard and was greeted by the message described in the following connect bug report:

Luckily I had my documentation in order and could use the work around no problem. But no “Next, next, next” installation as promised. Also this bug was reported in CTP #4 and didn’t get fixed for the RTM…. BAD MICROSOFT

So before you upgrade, make sure you write down the settings you need for the upgrade procedure:

– SQL server name
– Analysis server name
– Reporting server name
– Reporting server accounts