Contents tagged with TFS

  • TFS 2010 and the missing Area & Iterations (stale data) Issue

    The symptom is this: you change some area or iteration in a TFS Project, but the change is not reflected (or updated) in VS or any other TFS Client.

    Well, it happens that TFS now has some clever caching mechanisms that need to be updated when you make a change like this, and those changes are propagated by some scheduled jobs TFS is continuously running in the Application Tier. 

    So, you you get this behavior, please check (and possibly restart) the "Visual Studio Team Foundation Background Job Agent" service. In my case, this service was logging a very odd "Object Reference Not Set" into the Windows Event Log, and a simple restart fixed it.

    Hope this is fixed by RTM...   (we are using the RC version).

    And by the way, if the job agent is broken there are some other things that stops working like email notifications.

    Best regards,

    Andrés G Vettori, CTO, VMBC



  • VM Prep Tool for Visual Studio Team Lab Management 2010

    Microsoft has released the first version of the Virtual Machine Preparation Tool for Visual Studio Team Lab management 2010. What a mouthfull! Try saying that three times in a row..

    Well, the tool function is to prepare existing VMs to be compatible with VS 2010 Lab Management requirements, and believe me, there are a few. Configuring an existing VM by hand is a tedious and VERY error prone task, and so this tool was born.

    Download it from, this version is prepared to work with VSTS 2010 Beta 2 and Windows Server 2008 X86 SP2 VMs. They will be adding more options as soon they finish testing of different versions (and flavors) of Windows. Perhaps R2 is on the pipeline?

    Best regards,

    Andres G Vettori, VMBC, CTO



  • Build Silverlight 2.0 or 3.0 projects with an x64 TFS 2010 Build Agent

    I was trying to build our biggest solution after migration (TEST migration) and found that Silverlight projects won't compile. The first error we received was "The Silverlight 2 SDK is not installed". I found a post on the Silverlight forum about this and managed to fix the error, but then a second error appear:

     "The "ValidateXaml" task failed unexpectedly ... System.IO.FileLoadException: Could not load file or assembly 'PresentationCore, Version=, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The given assembly name or codebase was invalid. (Exception from HRESULT: 0x80131047)

    According to the people in the Silverlight forum, this is a Silverlight BUG and it won't compile in an x64 environment, so the general workaround is to use an x86 Build Agent.

    Fortunately, I found a MUCH BETTER workaround for TFS 2010, wich only involves changing the configuration of the build definition and set the "MSBuild Patform" to "X86" (it was "Auto" before).

    After this, my Silverlight projects compile again, even in an x64 Build agent. Nice!

    Just for reference, the Silverlight post is here:

    Andres G Vettori, VMBC, CTO


  • Enabled new ALM features after migration of TFS2008 to TFS2010

    The test migration of our TFS 2008 went extremely well (the import command processed nearly 7GB of data from our TFS 2008) in less than half hour, and all running in my notebook (not some kickass server...).

    Today I executed the script published by Hakan Eskici to upgrate the process template from v4.2 to v5, by simply running a BET file. The process is very simple and fast, and after that we now have the updated process template with all the TFS 2010 goodies enabled.

    Check out the process and download the script from

    After the upgrade I created a new TASK and found the new "Original estimate" field, and the now separated "Remaining work" and "Completed work", and I almost cryied by the emotion...  :)

    Also the BUGS have now the new "Repro Steps" and "Test Cases" tabs that are extremely welcome. There also more changes than this (for example the new Test Case WI) so give it a try!

    Best regards,

    Andres G Vettori, VMBC, CTO


  • MOSS & TFS 2010: Insufficient rights when configuring SSO

    If you try to configure the SSO (Single Sign-On) in Sharepoint 2007 for TFS 2010, you migh get the dreaded "Insufficient Rights" error.

    Configuring the SSO for TFS is not THAT well documented, and you keep finding instructions like "Configure the propper applicaiton domain groups". What the heck that means?

    Anyway, the first step is to configure the "Microsoft Single Sign On" service on EVERY Sharepoint frontend server. Change startup to AUTOMATIC, configure a DOMAIN account for that service, make it local administrator, add it to the local WSS_ADMIN_WPG group.

    You can use the service account you used for running Sharepoint as it already has most of this configuration, or you can create a brand new account specially for the SSO service. If this Sharepoint server will be your new corporate server, probably want to choose the later.

    And lastly, you you try to configure the SSO in the Sharepoint Central Administration and get the error "Insufficient Rights", make sure you are LOGGED IN with the account used for running the SSO service.

    Hope that helps,

    Andres G Vettori, VMBC, CTO


  • Projects upgraded from VS2008 to VS2010

    Yesterday I did my first test migrating one of our our rather complex VS2008 solutions to VS2010 (and TFS 2010). The solution and projects upgrade went generally well, I only had a few minor things to fix I'm detailing below:

    • All WCF client proxies were automatically regenerated. This is not neccesarily bad but we had touched our generated code (for example, to add a #pragma warning disable 1591 to avoid failing compilation because of the missing XML comments). To solve this I only needed to undo the changes produced in the generated files and everything worked as usual.
    • The new VS and/or compiler seems to be more strict in some things. Compilation failed because it found a couple malformed XML configuration files, a a couple conflicts about references (projects referencing directly and indirectly different versions of the same component). Fixing those errors was easy and I'm happy to find them automatically in VS2010.
    • I had to uninstall WIX 3 and install the (experimental) WIX 3.5 with Votive support for VS2010. Wix projects didn't compiled at first so I had to manually edit the .wixproj file and change the tool path. Also the new WIX 3.5 has a known bug where some of the project variables have the wrong value (for example, var.project.ProjectDir now includes a trainling "/bin" that is clearly wrong). A quick fix is to include a "/.." in the source path to reference the root project folder, but this is probably going to need rolling back this hack after the bug is fixed.
    • Some projects didn't upgraded automatically (WebTests, for example) and I had to migrate them manually. I'm investigating a issue with this projects because VS2010 seems to prompt me to migrate the same projects EVERY time I open the solution.
    • Tests projects (Unit tests, for example) are migrated to Framework 4.0 automatically. Those projects cannot run or compile using a previous version of the CLR and therefore ALL its references need to be compiled for Framework 4.0 as well.

    Well, that's all for now...   I'm going to test some build scripts now...  wish me luck!

     Andres G Vettori, VMBC, CTO


  • Faster builds with VSTS Team Build

     If you have big solutions with hundreds of projects and hundred of thoudsands lines of code, you know that by default compiling in the build server takes some time. One of the things that take most time is getting the sources to compile, and that's because by default the build script performs a FULL GET instead of a "normal" get (or incremental, just getting the things that changed from the last build).

    In order to instruct the build agent to perform an incremental for VS2005 get you need to modify the build script and include the following:

    <PropertyGroup Condition="Exists($(SolutionRoot))">

    For VS2008 you only need to add the following:

    ·         </ItemGroup>·            <PropertyGroup>·               <IncrementalBuild>true</IncrementalBuild>·          ·            </PropertyGroup>·         </Project>

    This means that the build script should not delete or initialize a previously existing workspace and don't try to force the GET operation for ALL sources. Another thing we can do to speedup the build process (specially in CI builds) is to avoid associating WorkItems with each build (that is only done on the RELEASE build done manually by the release manager), and therefore we need to include the following in the build script:

    <PropertyGroup Condition="$(QuickBuild)=='True'">




    Hope you find this information useful, 

    Andres G Vettori, VMBC, CTO