Category: Team System

I created a new WIT (work item type) to track progress of a set of activities we have here. Let’s call it “Setup”.

I wanted to restrict the users that create a new instance of the work item. The way to do this in TFS is to put a restriction on the state transition from “” to the first state of your workflow: “FirstStep” in our case.

To make things easier, I gave the group the same name of the WIT: “Setup”.

So I ended with something along the following lines:

<?xml version="1.0" encoding="utf-8"?>

<witd:WITD application="Work item type editor" version="1.0" xmlns:witd="http://schemas.microsoft.com/VisualStudio/2005/workitemtracking/typedef">

  <WORKITEMTYPE name="Setup">

    <WORKFLOW>

      <STATES />

      <TRANSITIONS>

        <TRANSITION from="" to="FirstStep" for="[project]Setup" />

      </TRANSITIONS>

    </WORKFLOW>

  </WORKITEMTYPE>

</witd:WITD>

The problem is that when I tried to save a new instance of the work item, I received the following message from TFS:

TF26212: Team Foundation Server could not save your changes. There may be problems with the work item type definition. Try again or contact your Team Foundation Server administrator.

That really doesn’t help…

After some research I found a blog post with a solution to the problem.

The problem is you should not have a WIT with the same name of a TFS group in whatever Team Projects you have.

When restricting the users or groups that can transition states of a work item type, there’s a little something you should pay attention to.

Lets say you want to restrict who can create a given type of work item to users of a custom “NewTesters” TFS Group. The docs says you should do something as follows:

<TRANSITION from="Resolved" to="Complete" for="[project]AllTesters" not="[project]NewTesters">
</TRANSITION>

On the “for” attribute some people may think that “[project]” is a place holder for the project’s name, but it is meant as a literal.

If your Team Project is named TheGreatestProjectEver, you should use "[project]AllTesters" literally as stated in documentation and not " TheGreatestProjectEver AllTesters"

Using "TheGreatestProjectEver AllTesters" will return:

“Warning: TF26171: (User/group {0} is not found.

TF26204: The account you entered is not recognized. Contact your Team Foundation Server administrator to add your account.”

As part of implementing branching for the project I’m currently working on, I had to do some restructuring of the source control folder structure.

The structure was generally well organized except for the fact they didn’t take branching into consideration when setting up the folder structure:

$

• Project
  • AnalysisServices
  • Assemblies
  • DatabaseObjects
  • IntegrationScripts
  • Models
  • OldLabBranch
  • TeamBuildTypes
  • Etc.

I wanted to create a branch in where AnalysisServices, Assemblies, DatabaseObjects and IntegrationScripts could be isolated in conjunction so new feature development could be done in parallel with regular maintenance without one breaking the other.

Using the branching guidelines I’ve talked a couple of posts ago, I managed to structure the folders as below:

$

• Project
  • OldLabBranch
  • Main
    • Sources
      • AnalysisServices
      • Assemblies
      • DatabaseObjects
      • IntegrationScripts
    • TeamBuildTypes
  • Models
  • Etc.

The problem with this setting is that your Team Build Types won’t show up in Team Explorer 2005 because it has a dependency of TeamBuildTypes being a direct child of your Team Project’s folder. Moving back TeamBuildType to $/Project did the trick and everything worked fine.

$

• Project
  • OldLabBranch
  • Main
    • Sources
      • AnalysisServices
      • Assemblies
      • DatabaseObjects
      • IntegrationScripts
  • Models
  • TeamBuildTypes
  • Etc.

When we upgrade to TFS 2008, I’ll move back TeamBuildTypes to the place recommended by the guidelines as they really do make sense.

There are times when loading a solution in Visual Studio 2005 you get a “Some of the properties associated with the solution could not be read” but the solution is nonetheless loaded.

There’s a KB about it, but the problem we had here had nothing to do to what’s being described on the article.

The problem lays on the fact that for some reason, the TFS source control section of the solution file got duplicated and there were multiple instances of it:

To fix the problem:

1. Unbind the solution from source control
2. Open the .sln with Notepad and make sure you delete all of the “GlobalSection(TeamFoundationVersionControl) = preSolution” sections from the file.
3. Bind the solution to source control again.

With that, Visual Studio will recreate the section properly and you should stop receiving the message.

This week I’m taking a look into branching and merging strategies in TFS.

VSTS Rangers and MVPs have released guidance for both TFS 2005 and 2008.

Even if you’re using 2005, if you want to dig into a little more details, you should take a look into the 2005 version of the guidance.

Microsoft Team Foundation Server Branching Guidance – Home (for TFS 2005)

TFS Branching Guide 2.0 – Home (for TFS 2008)

And by the way, yesterday I ordered Juan-Luc’s Professional Team Foundation Server from Amazon. It should arrive in two or three weeks.

Recently I’ve been doing some stuff with TFS so I added TFS Radio to the set of podcasts I hear regularly.

http://www.radiotfs.com/

Depois de refazerem a minha máquina aqui no trabalho, o menu de contexto do Source Control Explorer só trazia "No Commands Available".

Uma rápida procurada no Google e encontrei o post TFS Source Control- No Commands Available « Grant Holliday com a solução.

Sabe-se lá por que o Visual Studio estava configurado para usar o Source Safe. Ao mudar para TFS, tudo passou a funcionar corretamente.

Volta e meia durante uma palestra, a gente precisa aumentar o tamanho da fonte para que a audiência possa enxergar o que a gente está escrevendo ou mostrando.

Invariavalmente para fazer isto, todo mundo que eu conheço vai em Tools -> Options -> Fontes, etc…

Hoje encontrei uma dica no blog da Sara Ford mostrando como vincular key bindings a macros.

Com a dica dela você pode apertar CTRL+ALT+SHIFT+Up para aumentar a fonte e CTRL+ALT+SHIFT+Down para diminuí-la.

Esta e outras dicas podem ser encontradas no blog da Sara Ford.