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.

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:

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