Problem

I need to attach files to work items that are larger than 4KB on TFS 2010.

Solution

Use the web services on the Application Tier to increase the attachment size.

Explanation

The default value of work item attachments is 4KB.  However, that limit can be adjusted up to 2GB if required.  To update the value you must be a TFS Admin and on the TFS Application tier to perform this process.

Open IIS Manager and expand <Server>\Sites\Team Foundation Server\tfs\_tfs_resources\WorkItemTracking\v1.0.  If using Server 2008 switch to Content View to see the webservices.  Right click on ConfigurationSettingsService.asmx and select Browse.

The trick to making this work is to replace “_tfs_resources” with the collection name. 

After you replace “_tfs_resources” with your collection name press Enter to reload the page.  Now you can use the SetMaxAttachmentSize method to increase the file size.

Problem

I need to script my work item query administation.

Solution

Use the Work Item Query Administration tool from CodePlex http://wiqadmin.codeplex.com/

Examples

This will list out all the queries and the paths you need to export them

wiqadmin list /collection:http://MytfsUrl:8080/tfs/defaultcollection /p:MyProject /recursive

This is how you can export one once you know the path. Make sure you use “ on the path

wiqadmin export /collection:http://MytfsUrl:8080/tfs/defaultcollection /p:MyProject /n:"Team Queries/Iteration 1/Active Bugs" /f:bugs.wiql

Problem:

I am not asked to write TFS Event Handler web services very often and I can never remember where WorkItemChangedEvent is defined.  I spend more time searching for that missing reference than I do writing the code.

Solution:

For TFS 2010 WorkItemChangedEvent is in C:\Program Files\Microsoft Team Foundation Server 2010\Tools\Plugins\Microsoft.TeamFoundation.WorkItemTracking.Server.Dataaccesslayer.dll.

Problem:

We installed beta 1 of Microsoft Visual Studio Scrum and we need to upgrade without creating a new Team Project.

Solution:

1. (Optional) Add "Build Failure" as Reason for bug to allow it to work with the out of the box build templates.

2. Download all work items to Excel

3. Copy values from Owned By to Assigned To and publish changes back to TFS

4. Update Work Item Types using witAdmin and overwrite the original Scrum beta work item types

5. Update the Microsoft Project Mapping file if you changed the default “Assigned To” mapping to “Owned By” for MS Project resources

6. Update Work Item Queries to show Assigned To instead of Owned By

7. Import new MS Scrum v1.0 reports and bind to data sources

8. Import new build templates 

Explanation:

If you want to use an existing Build Template you may need to add the Build Failure reason to the bug work item type.  I would suggest making this change before you upload the template to TFS or use witAdmin to update the existing projects.   If you are going to update the original Build Template with the one in v1 you will lose the ability to create bugs on build failure.  The new template does not even allow it. I don't want failed builds to go unnoticed so I modify my build to fit the best practice established in the original release of TFS.  If you want to use that you should add the following reason tot the bug.

<REASON value="Build Failure" />

To begin download the latest version of Microsoft Visual Studio Scrum and install it. This process only copies the files to your computer it DOES NOT install into TFS.  You must use the Process Template Manager to upload the Template. The default location of the install is C:\Program Files (x86)\Microsoft\Microsoft Visual Studio Scrum 1.0\.

To upgrade an existing project we need to first move the Owned By values into Assigned To.  We need a All Work Items query to import the work items into Excel.  So create a simply query that returns all work items and save it.  Open Excel and import all work items using this query.  I found it helpful to sort the data by Owned By so I don't concern myself with those not currently Owned By anyone i.e. Sprints, Test Cases and Shared Steps they did not use Owned By. Make sure both columns Owned By and Assigned To are showing and copy from Owned By to Assigned To and publish.

Now simply use witAdmin or the Process Template editor to import the new work item types. The only two work items that DID NOT change are Shared Step and Test Case. The rest of the work items all have changes and should be imported.  However, if you receive an error trying to import the bug issue the following command:

c:\>witadmin changefield /collection:http://servername:8080/tfs/Collection0 /n:Microsoft.VSTS.TCM.ReproSteps /name:"Repro Steps"

Note if you made any customizations to the work items those will need to be remade on before you import.

Many of the Work Item Queries need to be updated to show the Assigned To field instead of the old Owned By field.  To update simply Right Click on the Query and select Edit Query.  Now click the Column Options button and remove the Owned By field and replace it with Assigned To. Repeat this for all the existing queries.

There was a new query added under the Current Sprint folder called Test Cases. It is a very simple query that simply list the work items of type Test Case.

Now use tfsfieldmapping to upload the Microsoft Project mappings.  The file you need to upload is located C:\Program Files (x86)\Microsoft\Microsoft Visual Studio Scrum 1.0\ Process Template\Classification\FileMapping.Xml.  Note you must be on a machine that has Office Primary Interop Assemblies (PIA) installed.  If you have Microsoft Project on the machine you should be fine. If not you can download the installer here http://www.microsoft.com/downloads/details.aspx?FamilyID=59daebaa-bed4-4282-a28c-b864d8bfa513&DisplayLang=en.

There are four new reports and two of the old ones were updated.  The process is the same for new or updated reports simply remember to check the box to overwrite existing reports.  All the reports are located in C:\Program Files (x86)\Microsoft\Microsoft Visual Studio Scrum 1.0\ Process Template\Reports.  The four new reports are Build Success over Time, Build Summary, Test Case Readiness and Test Plan Progress.  The new reports are in two sub folders Builds and Tests. The two reports that changed are Release Burndown and Velocity.  Simply visit the report server site and upload the new reports.  Once the new reports are uploaded you will have to update the data sources and the ExplicitProject Parameter.  To update the data sources click the Properties tab of the report and select the Data Sources link.  If the report was using TfsReportsDS map that to Tfs2010ReportsDS. If the report was using TfsOlapReportsDS map that to Tfs2010OlapReportDS and click the Apply button. While still on the Properties Tab click the Parameters link.  On the parameters page remove the value for ExplicitProject and uncheck the Prompt  User button and click Apply. Now you can view the report.

Final step is to check out the current DefaultTemplate.xaml file and check in the copy from v1.  Remember the new copy removes the creation of a bug on build failure.

Problem:

Team build cannot create Scrum for Team System bug on build failure.

warning : TF42097: A work item could not be created due to a field error. The following fields have incorrect values: Field: 'Reason' Value: 'Build Failure'

Solution:

Add ‘Build Failure’ as a reason to the Bug Work Item type.

Code:

<TRANSITION from="" to="Not Done">
    <REASONS>
        <DEFAULTREASON value="New" />
        <REASON value="Build Failure" />
    </REASONS>
</TRANSITION>

Explanation:

The problem is that when the build script attempts to create a bug for a build failure it is trying to set the reason for the bug to ‘Build Failure’.  ‘Build Failure’ is not a valid reason in the Scrum for Team System bug work item.  To add ‘Build Failure’ as a valid reason start the Visual Studio 2008 Command Prompt and use witExport to export the bug work item type.  The witExport command you need to use is below:

witexport /f bug.xml /t http://tfsServer:8080 /p teamProject /n bug

Replace tfsServer with your TFS server name and replace teamProject with the name of the team project you want to export the work item from.  This command will result in a file bug.xml to be saved on your hard drive with the bug work item type definition.  Open the file with your favorite xml editor.

Change

<TRANSITION from="" to="Not Done">
    <REASONS>
        <DEFAULTREASON value="New" />
    </REASONS>
</TRANSITION>

To

<TRANSITION from="" to="Not Done">
    <REASONS>
        <DEFAULTREASON value="New" />
        <REASON value="Build Failure" />
    </REASONS>
</TRANSITION>

Save the file and use witImport to import the modified bug work item type into your team foundation server. The witImport command you need to use is below:

witimport /f bug.xml /t http://tfsServer:8080 /p teamProject

Replace tfsServer with your TFS server name and replace teamProject with the name of the team project you want to import the work item into.  This command will result in the new work item type definition being stored for that team project.

Now when your build fails the work item will be created.

Another alternative is to simply update the value passed as the reason of the bug from ‘Build Failure’ to ‘New’.  To do that you simply change the following line in your tfsbuild.proj file.

Change

<WorkItemFieldValues>System.Reason=Build Failure;System.Description=Start the build using Team Build</WorkItemFieldValues>

To

<WorkItemFieldValues>System.Reason=New;System.Description=Start the build using Team Build</WorkItemFieldValues>

I guess one final option is to simply skip creating the work item all together.  Add this to the first Property Group:

<SkipWorkItemCreation>true</SkipWorkItemCreation>

You can also change the template used to create your tfsbuild.proj file by changing C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\PrivateAssemblies\1033\TFSBuild.proj so you don’t have to change every tfsbuild.proj file after build creation.