Teams WIT Tools

TFS 2010 Beta2: Troubleshooting SharePoint configuration issues (TF249038).

In configuring the integration between Team Foundation Server and SharePoint Products, one of the most common errors we see in Beta 2 is:

TF249038: The following Web service is not available: http://servername/_vti_bin/TeamFoundationIntegrationService.asmx. This Web service is used for the Team Foundation Server Extensions for SharePoint Products. Either the extensions are not installed, or there is a problem with the URL. Verify that the following URL is a valid SharePoint Web application and is available: http://servername. If the URL is correct, verify that it is available and the firewall is not blocking access to it.

Troubleshooting Information

Possible causes	Determining what happened and what to do about it
The call to the web service actually returned HTML instead of some kind of exception.  SharePoint often does this with things like access denied or timeouts. This is the most common cause of this error.	What happened? 1. The best way to check what happened is to take a look at the SharePoint logs which are normally located at "%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\12\LOGS" on the SharePoint server. 2. If you are creating a new site, a. Look for an entry that starts with “CreateSite BEGIN” where the arguments listed after that include your new site’s location. b. Now, look for “ThreadAbortExecption” between the “CreateSite BEGIN” and the “CreateSite END” log messages.  This is the classic indication that the call has timed out. 3. If you aren’t creating a site, then just check for the ThreadAbortExceptions. How can I fix it? Timeouts appear to be the most common problem.  If you are seeing timeouts, there are a couple of things you can try: 1. You can try “warming up” SharePoint before you try to create a new project.  You can do this by visiting the site created for the team project collection (e.g.: http://servername/sites/DefaultCollection). 2. If you are running in a VPC/VM environment, try increasing the memory allocated to the VPC/VM.  When its memory constrained, creating a SharePoint site takes much longer than it normally would. If it does not appear to be a timeout, see if you can determine a cause and solution based on the SharePoint logs. If you cannot, post a question to the Microsoft Visual Studio Team Foundation Server 2010 Beta 2 forum at http://social.msdn.microsoft.com/Forums/en-US/tfsprerelease/threads. Please include detailed information on what you were doing that resulted in the error as well as any log information you were able to find. Please also let us know if this was a one-time failure or if it is reproducible.
The Microsoft.TeamFoundation.SharePoint.wsp did not get deployed to the SharePoint Products server.  This web service is deployed to SharePoint as part of this package.	What happened? 1. Verify that the Extensions for SharePoint were installed on the server. Also, confirm that the configuration wizard was run. a. Open the Team Foundation Administration Console on the SharePoint Products server. b. Click on the “Extensions for SharePoint Products” node. c. If there is a link to configure installed features, then it has not been configured. 2. In the "%AllUsersProfile%\Application Data\Microsoft\Team Foundation\Server Configuration\Logs" folder, find a log file with the string Microsoft.TeamFoundation.SharePoint.wsp in it.  Then take a look at the logging around the STSADM.exe commands to see what if anything failed. 3. Then go to the SharePoint Central Administration site. 4. Click on the Operations tab. 5. Click on Solution Management (under Global Configuration). 6. There should be 3 TFS related WSPs located there.  2 of them should be globally deployed and the third should be deployed to all of the content web applications. How can I fix it? 1. If these were not deployed, you may be able to correct it by running the Team Foundation Extensions for SharePoint extensions installation and wizard again. 2. You can also deploy these WSPs (solutions) manually if you are a Farm Administrator in SharePoint. This only works if the installation has been done to lay down the assemblies needed. a. The files are located at “%ProgramFiles%\Microsoft Team Foundation Server 2010\Tools\Templates”. b. Open a command prompt and change to the “%ProgramFiles%\Common Files\Microsoft Shared\web server extensions\12\BIN” folder. c. To add the solution to the SharePoint database, run the following command for each of the three WSP files: stsadm.exe -o addsolution -filename wspfile.wsp d. Now, we’ll deploy each solution using the SharePoint Central Administration site. Open it in a web browser. e. Click on the Operations tab. f. Click on Solution Management (under Global Configuration). g. You should now see the WSPs that were added above. h. Click on the first one. i. Click Deploy Solution on the next page. j. Select to deploy it now and click OK on the next page. k. Repeat the deploy steps for each of the solutions. l. Finally, grant Modify permissions for the “WSS_WPG” group to the following folder: %CommonProgramFiles%\Microsoft\Team Foundation\Web Access”.
We get a web exception back.  This might be something like the server is not available.	What happened? 1. The log for the action you’re doing may contain more information.  2. Project Creation logs are on the client machine and are typically located in %Temp% for the user creating the project.  They are normally named VSTS_TeamProjectCreation_(timestamp).log. 3. TFS Configuration Team Project Collection creation logs can be accessed using the Team Foundation Administration Console. How can I fix it? 1. Try to correct the problem from the web exception and try again. If needed, search the web and our forums to see if there is a solution to the problem. 2. If you cannot determine the cause of the web exception, post a question to the Microsoft Visual Studio Team Foundation Server 2010 Beta 2 forum at http://social.msdn.microsoft.com/Forums/en-US/tfsprerelease/threads. Please include detailed information on what you were doing that resulted in the error as well as any log information you were able to find. Please also let us know if this was a one-time failure or if it is reproducible.
The SharePoint site cannot actually start up or there is a firewall blocking your access to it.  The startup problems can happen if the credentials for the site are not valid, the sites are running under .NET 4.0 (instead of 2.0), there are errors in the web.config file.	What happened? The SharePoint sites must work in a browser in order for our integration to work. 1. Check that you can get to SharePoint Central Administration site using a web browser. 2. Check that you can get to the content SharePoint sites using a web browser. How can I fix it? 1. Try to correct the problem and try again. 2. If you cannot determine the cause of the problem or correct it, post a question to the Microsoft Visual Studio Team Foundation Server 2010 Beta 2 forum at http://social.msdn.microsoft.com/Forums/en-US/tfsprerelease/threads. Please include detailed information on what you were doing that resulted in the error as well as any log information you were able to find. Please also let us know if this was a one-time failure or if it is reproducible.

What are we doing to make this better in RTM?

1. Because timeouts appear to be the most common problem, we are increasing the timeout to 5 minutes (from 90 seconds) in several of our web service methods.

2. During the initial configuration of the SharePoint extensions, we cycle IIS which makes it “cold” before creating a project.  We’re going to try to warm up the SharePoint site after we cycle IIS in the RTM version.

3. Web exception messages will be included in the RTM version of the exception above.

4. When we get HTML or some other response that is not valid, that information will be included in the exception data and in the logs.

Additional Information

To get a better understanding of the integration between Team Foundation Server and SharePoint Products, see http://msdn.microsoft.com/en-us/library/ms253177(VS.100).aspx.

Credits:

Many thanks to Mary Ellen Chaffin, for providing this nice writeup.

Compatibility Matrix for 2010 Beta 2 Team Foundation Server to Team Explorer 2008 and 2005

Table of Contents

Principles

Definitions

Available Download

Compat Matrix

      2010 Team Explorer Client to the 2008 Team Foundation Server

      2008 Team Explorer Client without the Forward Compatibility Update (GDR)

      2005 Team Explorer Client without the Forward Compatibility Update (GDR)

      The Team Explorer 2008 Forward Compatibility Update (GDR)

      The Team Explorer 2005 Forward Compatibility Update (GDR)

      The MSSCCI Provider 2010 Power Tool

Principles

TFS compatibility is taken very seriously - both new clients accessing older server versions and older clients accessing newer server versions.  As such, we have worked to make the new TFS 2010 clients work with the TFS 2008 servers (in addition to TFS 2010 servers).  We are also ensuring that TFS 2005, TFS 2008 and MSSCCI clients will work with new TFS 2010 servers, although patches are required to ensure this.  Many of the features in TFS 2010 have components on both the client and server that work together to provide the full benefit.  Using either an older server or older client means that some of the TFS 2010 features will not be available to you, but we have taken great strides to ensure that key features (old or new) work. In addition, API compatibility support was maintained in the object model and web services, so programs written against the old client or server versions should continue to work as designed.

Example 1:  2010 Team Foundation Server supports work item hierarchy.  Older clients will be able to query, view and edit work items on a 2010 server but will not be able to view or change the hierarchy.

Example2: Test results publishing has been improved with the 2010 server and older clients will be able to use the improved publishing as they were able to publish Test results previously.

In the event that you must use an older client (e.g. when you are doing SQL 2005 Business Intelligence development with VS 2005), you can run a newer TFS 2010 client side by side and access functionality not available in the older client.

Because TFS 2010 is such a large step forward, a few features in TFS 2005, 2008 and MSSCCI clients need updates to work with TFS 2010 server.  As such, updates (patches) are or will be available to those clients.  The TFS 2010 RTM server will block connection to the older unpatched clients by default. An error message with the location of the client patch will be provided. This is a configurable setting and an administrator after reviewing the issues with unpatch client will be able choose to unblock the unpatched client or not. All of the details on the issues and configuration settings are below.

Definitions

Back Compatibility: The new version clients support the older server.

Forward Compatibility: The older clients support the new server, sometimes with the additional help from an update (patch).

Available Download

VSTS 2008 Forward Compatibility Update

 

Beta 2 Support Matrix		Servers
Clients	TFS 2010	TFS 2008	TFS 2005
VS / TE 2010	Y	Y	No
VS / TE 2008	N (Default)	Y (no change)	Y (no change)
VS / TE 2005	N (default)	Y (no change)	Y (no change)
VS / TE 2008 w/  GDR	Yes	Y (no change)	Y (no change)
VS / TE 2005 w/ GDR	Yes	Y (no change)	Y (no change)
MSSCCI  2010	Yes	Y (no change)	Y (no change)
MSSCCI 2008	No	Y (no change)	Y (no change)

2010 Team Explorer Client to the 2008 Team Foundation Server

The 2010 Team Explorer client provides a similar experience to the 2008 Team Explorer client when connected to a 2008 Team Foundation Server. New functionality the server does not have is disabled or hidden from the user.

How to connect 2010 Team Explorer to 2008 Team Foundation Server

Before TFS 2010, TFS services always appear at the root of a web site. Starting in TFS 2010, you can configure a path. The 2010 connect dialog defaults to the default TFS 2010 sub path “tfs”.

Workaround

Team Explorer 2010 connection dialog will need the path field cleared to connect to a previous version of Team Foundation Server.

2008 Team Explorer Client without the Forward Compatibility Update (GDR)

Here is the list of issues and workarounds.

Some Team Foundation Server 2010 administrative functions are only supported using Team Explorer 2010.

As Team Explorer 2008 and Team Explorer 2005 are not aware of several Team Foundation Server 2010 features, administrative functionality has been limited to the Team Explorer 2010 client. For example, the administrator can only run the Project Creation Wizard from Team Explorer 2010 to add Team Project to Team Foundation Server 2010. Team Explorer 2010 client can also be used to administer the Team Foundation Server 2008 server.

Tools only available to the Team Explore 2010 client when against a 2010 server include:

· PCW (Project Creation Wizard),

· Destroy Work Item, Destroy Work Item Type and Rename Work Item Type,

· Uploading Process Templates

· Uploading Work Item Definitions,

· Uploading TFS Field Mapping for Microsoft Project.

Workaround

Use Team Explorer 2010 to perform administrative functions on Team Foundation Server 2010.

How to connect a Team Explorer 2008 SP1 to a Team Foundation Server 2010 Server

TFS 2010 introduces the notion of Team Project Collections. A TFS “server” can house many Team Project Collections. Team Explorer 2008 SP1 can connect to any of the Team Project Collections in a TFS instance but you must type the full url for the collection.Workaround

Add the whole path as shown below in the Add Team Foundation Server dialog.

We can express the connection string as follows: http://<serverName>:<port>/<vdir>/<collectionName>

The <vdir> is an optional path for the TFS web sites specified by the administrator during setup. By default it is “tfs”.

Example connection strings looks like: http://myserver:8080/tfs/Collection1 or http://server:8080/Collection1

It is possible to connect to the default Team Project Collection by providing the server name only. This method is limited, as it only allows connection to one of the Team Project Collections in a TFS Instance.

Test results Publishing is not supported for a Team Explorer 2008 SP1 or older clients.

Test results cannot be published using Team Explorer 2008 SP1 or older clients.

Workaround

Use Team Explorer 2010 or Team Explorer 2008 SP1 with the Update to publish test results.

Rename in Version Control can cause unexpected results using Team Explorer 2008 SP1 or older clients.

Rename in Version Control can cause unexpected results using Team Explorer 2008 or older clients. It is possible to create a case where the client gets confused about a pending file that has been renamed and a new file with the pending files original name. In this case, only one file with a conflicting name can be checked in by the old client leaving the new file pending and unable to check in. This requires the user to undo the changes to get the client back to a good state. Using rename will never block other users from checking in files, nor will any data corruption occur on the server.

Workarounds

If you must work from the 2008 client without the update, always check in a file after a rename before creating another file with the same name.

Use Team Explorer 2010 or Team Explorer 2008 SP1 with the Update to use rename in Version Control.

Work Item Tracking Queries with new functionality are not supported for a Team Explorer 2008 SP1 or older clients.

Work Item Tracking Queries with new functionality create unexpected error messages.

Workaround

Place new queries with linking, grouping, categories, or field comparisons in a separate folder marked “New Clients Only” so customers using Team Explorer 2008 SP1 or older clients can distinguish those queries without these features.

Navigation to Reports is not supported for a Team Explorer 2008 SP1 or older clients.

Team Explorer 2008 SP1 or older clients do not recognize the path to the reports for a Team Project hosted on Team Foundation Server 2010.

Workaround

Use a browser to navigate to the http://<reportserver>/reports then click on the “Team Foundation Server Reports” folder and the Team Project Collection folder for the appropriate collection that contains the Team Projects you are interested in.

Navigation to non-default Shared Document, Project Portal and Process Guidance locations is broken for a Team Explorer 2008 SP1 or older clients.

Administrators are able to configure the location of the Shared Documents, Project Portal and Process guidance but Team Explorer 2008 SP1 Client will not be able to find the new location.

Workaround

If the Shared Document, Project Portal and Process Guidance locations have been modified, URLs to the new locations can be sent to the user with Team Explorer 2008 SP1 Clients or older clients.

Microsoft Project plan documents created using a Team Explorer 2010 client, break when opened from a Team Explorer 2008 SP1 or older client.

Customers who open a Microsoft Project plan created from a Team Explorer 2010 client with a Team Explorer 2008 or older client will cause the plan to become unusable.

Workaround

Do not port project plans to other Microsoft Project tools using older client add-ins without the Forward Compatibility GDR.

Team Explorer 2008 SP1 or older client users will be able to submit changes that affect gated build definitions, but they will not be prompted with the confirmation dialog and, if their check-in affects multiple gated definitions, it will fail.

The customer may not know if they were successful or not.

Workaround

The customer can check the build explorer (just like in Team Explorer 2010) or use the build notification applet (Team Foundation Server 2008 power tools release rather than Team Foundation Server 2010 release).

Team Explorer 2008 SP1 or older client users can create new build definitions but they will not be able to edit them or to edit other, existing build definitions.

New build definitions will be automatically upgraded to Team Foundation Server 2010 build definitions using the upgrade build process template, so Team Explorer 2008 or older client users will not be able to edit them.

Workaround

Use the Team Explorer 2010 to edit build definitions. Alternatively, you can use a text or XML editor to edit the build process template.

Team Explorer 2008 SP1 or older clients will not be able to modify build controller properties from the Manage Build Agents dialog box.

While users of Team Explorer 2008 will be able to use the Manage Build Agents dialog box when connected to Team Foundation Server 2010, they will not be able modify the properties of Team Foundation Server 2010 Build Controller. If they attempt this, they will get the following error message: Updating build agents is not supported from this client. Please use a client compatible with Team Foundation Build 2010 and try again.

Workaround

Use the Team Explorer 2010.

Team Explorer 2008 SP1 or older clients will not be able to view new 2010 controls like Stand Alone Labels, the Web Control, the Associated Test Automation Control, and the Test Steps Control.

New controls used in some new Team Project work item types like Test Cases show as missing in older clients. The location on the form where the control is missing displays as red with the path to the missing control shown.

Workaround

Use Team Explorer 2010 to view all of the 2010 controls or Team Explorer 2008 SP1 with the Update to view a read only version of the Associated Test Automation and Test Steps controls.

2005 Team Explorer Client without the Forward Compatibility Update (GDR)

All issues using the 2008 client without the GDR apply to the 2005 client. In addition, the follow issues also apply.

The 2005 Team Explorer client is only able to connect to the default Team Project Collection. There is only one default Team Project Collection in a TFS Instance. If there are multiple Team Project Collections, the 2005 Team Explorer client will not have access

Workaround

Use Team Explorer 2010 side by side with Team Explorer 2005 to check files into the 2010 server.

The 2005 Team Explorer client is unable to render new controls in the work item form so is unable to view some work items types that use the new controls created with the 2010 v5 Agile and CMMI process templates.

The 2005 Team Explorer throws an exception when trying to render the new controls. Therefore, unpatched 2005 clients are unable to view the work item form from within Team Explore if these new controls are present on the form. The Stand Alone Label Control and the Web Control are not found in the 2010 v5 Agile and CMMI process templates but my be added by updating a work item form. If they are added any work item type may through an exception from the 2005 client. In addition, the new Test Case work item form uses the Test Steps and the Associated Test Automation Controls, which also will not work.

Workaround

Use Team Explorer 2010 side by side with Team Explorer 2005 or use Team System Web Access perform work item tracking functions when working with Team Projects that use these controls.

The Team Explorer 2008 Forward Compatibility Update (GDR)

The VSTS 2008 Forward Compatibility Update is available and can be found at the Microsoft Download Center.

This update is applied over the 2008 SP1 version of Visual Studio Team System Team Explorer to work with 2010 TFS. The update will allow teams to move forward and use the 2010 server even if part of a team that uses the 2008 client.

The objective of this update is to continue to provide the experience of the 2008 client when working against a 2010 server. New functionality will require the 2010 client, but scenarios you already were able to perform in 2008 will continue to work.

Here are the compatibility scenarios that have been enabled or improved with the GDR.

Work Item Tracking

1) TFS 2010 provides flexibility to change the location of your Project Portal, Shared Documents and Process Guidance. The 2008 Forward Compat GDR retrieves the new location from the server and this allows the 2008 client to continue to navigate to the new locations.

2) With the addition of the Team Project Collection, the reporting server paths have changed for the Team Project RDL Reports. The GDR also enables the 2008 client to navigate to the reports new location.

3) The GDR enables the user to determine which queries that can only be run from a newer client.

Office Integration

4) The addition of hierarchy in TFS 2010 has created some portability issues with MS Project plan documents created using a 2010 client when sent to a user with the 2008 client. The GDR enables the 2008 client add-in to update values, but not to change link relationships like hierarchy and dependencies.

Version Control

5) The GDR enables the 2008 client to correctly view, update, undo, and commit pending changes, mostly centered around rename scenarios when working with the 2010 server.

6) The user can also correctly view committed changes in both the changeset details and Source Control Explorer, in rename scenarios when working with the 2010 server.

7) The 2008 client with the GDR displays accurate messages during conflict resolution, in rename scenarios when working with the 2010 server.

Test Case Management

8) Test Case Management is improved in TFS 2010 with Test Essentials and we want the customer using TE 2008 to participate. The Test Steps Control and the Associated Automation Control are viewable in a read only mode providing the user context from Team Explorer.

9) The ability to publish test results from Visual Studio using the Test Result Publishing Server and from the MS Test Command Line Tool is also enabled.

10) The GDR lets you view published test results that were created with the 2008 client.

The Team Explorer 2005 Forward Compatibility Update (GDR)

The VSTS 2005 Forward Compatibility Update, expected around RTM for TFS 2010, will be more focused on development scenarios. For administrative, project management and test case scenarios, the use of Team Explorer 2010 is recommended in the side by side configuration.

Scope for the 2005 Forward Compatibility Updates

· Connect to any Team Project in any Team Project Collections on a 2010 server.

· Determine which queries have new functionality and are unavailable to select.

· Navigation to non-default Project Portal, Shared Documents and Process Guidance

· Navigation to TFS 2010 Reports

· Correctly view, update, undo, and commit pending changes associated with rename.

· Correctly view committed changes in version control in rename cases.

Support for Test Management and Office Integration from Microsoft Project or Excel requires Team Explorer 2010 side by side with the 2005 client. For example, the Office Integration Add-Ins for Excel and Project can be launched from 2005 but will have 2010 functionality when side by side. Similarly, test cases can be published from 2010 Build Automation when side by side.

The MSSCCI Provider 2010 Power Tool

The Microsoft Source Code Control Interface (MSSCCI) power tool currently works with TFS 2005 and 2008 servers. Before TFS 2010 is finished, a new release of the Power Tools MSSCCI provider will be available and support TFS 2010 servers in addition to 2008 and 2005.

Compatible with:

· Visual Studio .NET 2003

· Visual C++ 6 SP6

· Visual Visual Basic 6 SP6

· Visual FoxPro 9 SP1

· Microsoft Access 2003 SP2

· SQL Server Management Studio

· Sparx Systems Enterprise Architect 6.1

· Sybase PowerBuilder 10.5

· Toad for SQL Server 2.0

Team Explorer 2005 & 2008 & 2010 Beta 1 Compatibility Matrix

Although many scenarios have been enabled in the VSTS Beta 1, there are a number of compatibility issues which are still being working on.

 

 * List of Known Issues and Workarounds

1) Team Foundation Server 2010 administrative functions are only supported using Team Explorer 2010.

Problem Statement

As Team Explorer 2008 and Team Explorer 2005 are not aware of several Team Foundation Server 2010 features, administrative functionality has been limited to Team Explorer 2010. For example, the administrator can only run the Project Creation Wizard from Team Explorer 2010 to add Team Project to Team Foundation Server 2010. Team Explorer Team Explorer 2010 client can also be used to administer the Team Foundation Server 2008 server.

Workaround

Use Team Explorer 2010 to perform administrative functions on Team Foundation Server 2010.

2) How to connect a Team Explorer 2008 SP1 to a Team Foundation Server 2010 Server

Problem Statement

Team Project Collections, new to Team Foundation Server 2010, change the path to the server.

Workaround

We can express the connection string as follows:

http://<serverName>:<port>/<vdir>/<collectionName>

Where the <vdir> is an optional, server level argument.

Example connection Strings looks like: http://myserver:8080/Collection1 or http://server:8080/tfs

Moreover customers can give the server name (using the Team Explorer 2008 way to create the connection string) to connect to default collection of the instance on that server.

3) How to connect Team Explorer 2010 to Team Foundation Server 2008

Problem Statement

The path field in the connection dialog is defaulted to Team Foundation Server

Workaround

Team Explorer 2010 connection dialog may need the path field cleared to connect to a previous version of Team Foundation Server.

4) Test Results Publishing is not supported for a Team Explorer 2008 SP1 or older clients.

Problem Statement

Test case results cannot be published using Team Explorer 2008 or older clients.

Workaround

Use Team Explorer 2010 to publish test case results.

5) Rename in Version Control is not supported for Team Explorer 2008 SP1 or older clients.

Problem Statement

Rename in Version Control can cause unexpected results using Team Explorer 2008 or older clients.

Workaround

Use Team Explorer 2010 to use rename in Version Control.

6) Work Item Tracking Queries with new functionality are not supported for a Team Explorer 2008 SP1 or older clients.

Problem Statement

Work Item Tracking Queries with new functionality create unexpected error messages.

Workaround

Place new queries with linking, grouping, categories, or field comparisons in a separate folder marked “New Clients Only” so customers using Team Explorer 2008 SP1 or older clients can distinguish those queries without these features.

7) Navigation to Reports is not supported for a Team Explorer 2008 SP1 or older clients.

Problem Statement

Team Explorer 2008 SP1 or older clients do not recognize the path to the reports for a Team Project hosted on Team Foundation Server 2010.

Workaround

Use a browser to navigate to the http://<reportserver>/reports then click on the “Team Foundation Server Reports” folder and the Team Project Collection folder for the appropriate collection that contains the Team Projects you are interested in.

8) Navigation to non-default Shared Document, Project Portal and Process Guidance locations is broken for a Team Explorer 2008 SP1 or older clients.

Problem Statement

Administrators are able to configure the location of the Shared Documents, Project Portal and Process guidance but Team Explorer 2008 SP1 Client will not be able to find the new location.

Workaround

If the Shared Document, Project Portal and Process Guidance locations have been modified, URLs to the new locations can be sent to the customers with Team Explorer 2008 SP1 Clients or older clients.

9) Microsoft Project plan documents created using a Team Explorer 2010 client, break when opened from a Team Explorer 2008 or older client.

Problem Statement

Customers who open a Microsoft Project plan created from a Team Explorer 2010 client with a Team Explorer 2008 or older client will cause the plan to become unusable.

Workaround

Do not port project plans to other Microsoft Project tools using older client add-ins during Beta 1.

10) Team Explorer 2008 or older client will not be able to manually queue a build without having the “View Build Resources” permissions.

Problem Statement

Build permission on upgrade were not automatically set to enable Team Explorer 2008 or older client users.

Workaround

Contact the Team Project Administrator to have the build permissions elevated for Team Explorer 2008 client users, if no build agents are visible in the Queue Build dialog in Team Explorer 2008.

11) Team Explorer 2008 or older clients will not be able to manage build resources using the “Manage Build Agents” dialog box.

Problem Statement

The “Manage Build Agents” dialog box disabled for the old client user and users get the following error message when trying to edit, add or delete: “Updating build agents is not supported from this client. Please use a client compatible with Team Foundation Build Codename Rosario and try again.”

Workaround

Use Team Explorer 2010 to manage build resources.

12) Team Explorer 2008 or older clients will be able to submit changes that affect gated build definitions, but they will not be prompted with the confirmation dialog and, if their check-in affects multiple gated definitions, it will fail.

Problem Statement

The customer may not know if they were successful or not.

Workaround

The customer can check the build explorer (just like a Team Explorer 2010 user would) or use the build notification applet (2008 power tools release rather than 2010 release).

13) Team Explorer 2008 or older client users can create new build definitions but they will not be able to edit them or to edit other, existing build definitions.

Problem Statement

New build definitions will be automatically upgraded to Team Foundation Server 2010 build definitions using the upgrade build process template, so Team Explorer 2008 or older client users will not be able them.

Workaround

Use Team Explorer 2010 Client to get the WF designer experience or to edit build definitions or use a text or XML editor to edit the build process template.

Restarting the TFS Add-Inn (Excel 2007) Updated

· These instructions will help determine if the Team Add-In is disabled in Excel and will allow you to enable it.

Open Excel

Select the Windows Menu

Select Excel Options

Go to Add-Ins

Manage Add-Ins

Sometimes you need to look under Disabled Items

Select TFS and OK!

Team Tool Bar should be back

Customizing Work Item Link Types in TFS 2010

A long time ago (almost 2 years ago), I blogged about how to customize link types. Since the Beta1 has been released, I thought it would be useful to reblog this information.

Here are the links. The information is still valid.

• Rosario - Customizing Link Types Primer
• Rosario: Filtering link types on a work item form

The dates of these blogs will give you an idea of how long we’ve been using these new link types internally.

Enjoy.

Forward Compat GDRs for Team Foundation Server 2010!

TFS will be providing a General Distribution Release (GDR) to enable older versions of Visual Studio Team System Team Explorer to work with 2010 TFS. Releasing these GDRs will allow teams to move forward even when some people are not ready due to legacy code or business intelligence issues.

We will support both Team Explorer 2008, and now Team Explorer 2005 clients!

We are still working on scope and schedule for the 2005 client GDR, but we are well on the way for the 2008 Forward Compat GDR and it will be ready by TFS 2010 Beta 2.

The objective of the GDR is to continue to provide the experience of the 2008 client when working against a 2010 server. New functionality will require the 2010 client, but scenarios you already were able to perform in 2008 will continue to work.

An example of new functionality is hierarchy trees utilizing parent/child link types. Queries in 2010 allow you select all of the work items in the tree. The older clients do not know how to parse the new query code, but clients with the GDR will allow you to recognize the queries that are not enabled for the 2008 client. You can see from the snapshot on the right, the user is able to quickly tell which queries they can use with the 2008 client. If the customer, still tries to open one of these queries they are provided an error message that indicates they need to use a 2010 client or Team System Web Access to view or edit the query.

In addition to this example, several other scenarios have been enabled.

Work Item Tracking

1) TFS 2010 provides flexibility to change the location of your Project Portal, Shared Documents and Process Guidance. The 2008 Forward Compat GDR will retrieve the new location from the server and this allows the 2008 client to continue to navigate to the new locations.

2) With the addition of the Team Project Collection, the reporting server paths have changed for the Team Project RDL Reports. The GDR also enables the 2008 client to navigate to the reports new location.

Office Integration

3) The addition of hierarchy in TFS 2010 has created some portability issues with MS Project plan documents created using a 2010 client when sent to a use with the 2008 client. The GDR enables the 2008 client add-in to update values but not to change link relationships like hierarchy and dependencies.

Version Control

4) The GDR enables the 2008 client to correctly view, update, undo, and commit pending changes, mostly centered around rename scenarios when working with the 2010 server.

5) The user can also correctly view committed changes in both the changeset details and Source Control Explorer.

6) The 2008 client with the GDR will also display accurate messages during conflict resolution.

Test Case Management

7) Test Case Management is really fantastic in TFS 2010 with Test Essentials and we want the customer using TE 2008 to participate, so the new Repro Steps control has been enabled. The Test Steps Control and the Associated Automation Control are viewable in a read only mode providing the user context from Team Explorer.

8) The ability to publish test results from Visual Studio using the Test Result Publishing Server and from the MS Test Command Line Tool are also enabled rounding out the test case management story.

As you can see, this provides a whole lot of goodness to using the Team Explorer 2008 with your new or upgraded Team Project on TFS 2010! Continue to look here to follow our progress for the Compat features.

SharePoint Integration in TFS 2010 Beta1

Last month, Brian Harry outlined some of the new features in the setup and administration experience for TFS 2010 here. This post drills into how SharePoint integration works for Beta1.

Installation

In TFS 2010, we’ve separated the installation from the configuration of TFS. The installation and configuration of SharePoint occurs during the configuration stage of TFS. This addresses a pain point we’ve heard from customers using 2008, where if for some reason, installation or configuration of SharePoint failed, the entire installation of TFS failed as well and rolled back.

When installing TFS 2010, you can choose to install:

Team Foundation Server – Choose this option if you are planning to either deploy only TFS on this box or keep SharePoint and TFS on the same box.

Extensions for SharePoint Products and Technologies – Choose this option if you have SharePoint already installed on the box and want to enable integration with TFS on another server. (Note: this option will not appear if you do not have SharePoint already installed.) This option supports both single-server and farm environments.

User Accounts/Permissions

Our SharePoint integration is much more flexible in 2010, but with this flexibility comes a bit more complexity. If you want to integrate SharePoint with TFS in 2010, then you need to create a two-way mapping: the TFS instance must know where the SharePoint instance is and vice versa. Depending on how you configure SharePoint, the same may hold true of the service accounts. That is, the TFS service account will need access to SharePoint (it must have farm administrator privileges) and the SharePoint service account will need access to TFS.

There are two main scenarios in installation:

• Scenario A: as a TFS administrator, you are in charge of both TFS and SharePoint.
• Scenario B: as a TFS administrator, you do not have control over SharePoint. For example, this may be the case if SharePoint is managed in a corporate farm.

Scenario A is the simpler of the two, and if you’re installing TFS and SharePoint on the same server, then your setup can become even simpler, as you’ll see below. In Scenario B, you’ll need to work together with your organization’s SharePoint administrator to integrate TFS and SharePoint. The TFS installation help file includes a useful worksheet that helps you and your SharePoint administrator collaborate on the information necessary to successfully configure TFS/SharePoint integration, including user accounts.

Configuration

Once the installation succeeds, you’ll move on to the configuration stage. Your options vary depending on whether you installed TFS or the extensions. One of the known issues discussed in the Beta1 ReadMe is a bug that occurs if you choose not to start the configuration wizard right after completing the MSI install (that is, you uncheck the “Launch Team Foundation Server Configuration Tool” option on the setup’s “Finish Page”). Buck Hodges has a great blog post here explaining the issue and how to avoid it.

• Team Foundation Server
  • Default Configuration
    
    
    This is the option you should choose if you plan on using a single server for TFS, SQL, and SharePoint. This option installs and configures Windows SharePoint Services (WSS) 3.0 for you, so if you already have SharePoint installed on the server or want to use Microsoft Office SharePoint Server (MOSS), you’ll need to run the custom configuration. Otherwise, just provide TFS with the details on the service account you want to use for SharePoint, and TFS will do all the installation and configuration for you. 
    
  • Custom Configuration
    
    
    
    This option allows you to customize various aspects of the TFS configuration. By selecting this, you can:
    • Opt out of installing/configuring SharePoint. To opt out, just uncheck the “Configure Sharepoint…” checkbox.
    • Install and configure WSS 3.0 on the server to integrate with TFS. While the Default Configuration does this for you as well, we offer this choice in custom configuration since you may wish to customize other, non-SharePoint related options. As in the Default Configuration, you’ll need to provide a service account for SharePoint.
    • Integrate TFS with an existing SharePoint site. If you fall under Scenario B described above, you’ll want to use the custom configuration to hook up TFS with SharePoint.
      
  • Application-Tier Only
    
    This is the option you should choose if you separate your application tier from your data tier (your SQL server instance for TFS is on a different server) and you do not want to install/configure SharePoint.
    
  • Upgrade from a previous version
    
    
    You can select an existing SharePoint site you want to integrate with. Note that the instruction text on the preceding page is incorrect. You cannot install SharePoint on upgrade in Beta1.
    
• Extensions for SharePoint Products and Technologies
  
  
  There’s not much to configure on this page. :) Just press “Configure” and you’re done.

TFS/SharePoint Mappings

The following diagram represents the recommended mappings when integrating with SharePoint.

TFS Instance/SharePoint Web Application

If you chose to integrate with SharePoint during configuration of TFS, this mapping is created for you. On the TFS side, you need the following information to create/edit mappings to Sharepoint Web Apps:

• The service accounts used for the SharePoint Web Application
• The base URL for SharePoint Web Application
• The SharePoint Central Administration URL
• The relative path for the Sharepoint sites for Team Projects

You can change the mappings in the SharePoint Web Applications Node of the Team Foundation Administration Console:

Recall that mappings are two-way. Thus, if you’re customizing the mappings or you’re creating a new mapping in the TFS Administration Console, you’ll need to keep the mappings from SharePoint to TFS in sync as well. If you are not the SharePoint administrator (scenario B, above), you’ll need to work together to create the mappings.

On the SharePoint server, the TFS mappings can be configured in the Extensions for SharePoint Products and Technologies node of the Team Foundation Administration Console. The following information is needed on the SharePoint side:

• The TFS service account, so that this can be added to the SharePoint farm administrators group
• The URL for the TFS instance
• For MOSS administrators: the single sign on name

Again, if you find yourself in scenario B, the TFS installation help file for Beta1 has a handy worksheet that you and your SharePoint administrator can use to make these mappings a smooth process.

Team Project Collection/SharePoint Site Collection

In TFS 2010, we’ve introduced the concept of a Team Project Collection (TPC). Brian Harry has a great blog post that defines and describes this key concept. You can create TPCs in the Team Foundation Administration Console. If you have SharePoint integration set up and you create a TPC, TFS can create and configure a new SharePoint site collection for you that maps to the TPC (the TFS service account must be added to the SharePoint farm administrator group for this to be successful).

Note that with this integration, you get the added bonus that, if you want to backup/restore your Team Project Collections, you can also backup/restore the corresponding site collections through SharePoint’s own backup/restore mechanism. This allows you to take full advantage of our support for moving TPCs to different servers.

Team Project/SharePoint Site

As with TPCs, if you have SharePoint integration set up and you create a Team Project, TFS can create a correlating SharePoint site that serves as the new Team Project’s portal page.

If you click “Configure…”, you can choose where you want to create the new SharePoint site:

While we give you flexibility here as far as the location, we recommend that you keep the location as a subsite of the project collection to enable the backup and restore scenario we mentioned earlier.

Note that if you wish, you don’t have to create the Process Guidance. You can configure the location of the process guidance later in the Project Portal Settings. This way, if multiple projects are using the same process, you can have them share the same guidance. Instead of updating the guidance for each project, you can now update it in one place.

Finally, in keeping with our theme of added flexibility, there’s an option not to create a SharePoint site at all. You can configure where the portal is later by entering the relevant data in the Project Portal Settings dialog. The dialog allows you to choose whether you want to use a SharePoint site (where TFS can easily integrate its reports and dashboards) or a fully qualified URL of your choice. The same goes for the process guidance.

Useful links

Beta1 install help file (.chm) - http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=2d531219-2c39-4c69-88ef-f5ae6ac18c9f

Brian Harry: TFS 2010 Admin, Operations & Setup Improvements - http://blogs.msdn.com/bharry/archive/2009/04/30/tfs-2010-admin-operations-setup-improvements.aspx

Buck Hodges: TFS 2010 Beta 1: Don’t run initial configuration from the administration console (MMC) - http://blogs.msdn.com/buckh/archive/2009/05/18/tfs-2010-beta-1-don-t-run-initial-configuration-from-the-administration-console-mmc.aspx

Team Explorer 2010 Beta 1 Compatibility

Although many scenarios have been enabled in the VSTS Beta 1, there are a number of compatibility issues which are still being working on.

 

 * List of Known Issues and Workarounds

1) Team Foundation Server 2010 administrative functions are only supported using Team Explorer 2010.

Problem Statement

As Team Explorer 2008 and Team Explorer 2005 are not aware of several Team Foundation Server 2010 features, administrative functionality has been limited to Team Explorer 2010. For example, the administrator can only run the Project Creation Wizard from Team Explorer 2010 to add Team Project to Team Foundation Server 2010. Team Explorer Team Explorer 2010 client can also be used to administer the Team Foundation Server 2008 server.

Workaround

Use Team Explorer 2010 to perform administrative functions on Team Foundation Server 2010.

2) How to connect a Team Explorer 2008 SP1 to a Team Foundation Server 2010 Server

Problem Statement

Team Project Collections, new to Team Foundation Server 2010, change the path to the server.

Workaround

We can express the connection string as follows:

http://<serverName>:<port>/<vdir>/<collectionName>

Where the <vdir> is an optional, server level argument.

Example connection Strings looks like: http://myserver:8080/Collection1 or http://server:8080/tfs

Moreover customers can give the server name (using the Team Explorer 2008 way to create the connection string) to connect to default collection of the instance on that server.

3) How to connect Team Explorer 2010 to Team Foundation Server 2008

Problem Statement

The path field in the connection dialog is defaulted to Team Foundation Server

Workaround

Team Explorer 2010 connection dialog may need the path field cleared to connect to a previous version of Team Foundation Server.

4) Test Results Publishing is not supported for a Team Explorer 2008 SP1 or older clients.

Problem Statement

Test case results cannot be published using Team Explorer 2008 or older clients.

Workaround

Use Team Explorer 2010 to publish test case results.

5) Rename in Version Control is not supported for Team Explorer 2008 SP1 or older clients.

Problem Statement

Rename in Version Control can cause unexpected results using Team Explorer 2008 or older clients.

Workaround

Use Team Explorer 2010 to use rename in Version Control.

6) Work Item Tracking Queries with new functionality are not supported for a Team Explorer 2008 SP1 or older clients.

Problem Statement

Work Item Tracking Queries with new functionality create unexpected error messages.

Workaround

Place new queries with linking, grouping, categories, or field comparisons in a separate folder marked “New Clients Only” so customers using Team Explorer 2008 SP1 or older clients can distinguish those queries without these features.

7) Navigation to Reports is not supported for a Team Explorer 2008 SP1 or older clients.

Problem Statement

Team Explorer 2008 SP1 or older clients do not recognize the path to the reports for a Team Project hosted on Team Foundation Server 2010.

Workaround

Use a browser to navigate to the http://<reportserver>/reports then click on the “Team Foundation Server Reports” folder and the Team Project Collection folder for the appropriate collection that contains the Team Projects you are interested in.

8) Navigation to non-default Shared Document, Project Portal and Process Guidance locations is broken for a Team Explorer 2008 SP1 or older clients.

Problem Statement

Administrators are able to configure the location of the Shared Documents, Project Portal and Process guidance but Team Explorer 2008 SP1 Client will not be able to find the new location.

Workaround

If the Shared Document, Project Portal and Process Guidance locations have been modified, URLs to the new locations can be sent to the customers with Team Explorer 2008 SP1 Clients or older clients.

9) Microsoft Project plan documents created using a Team Explorer 2010 client, break when opened from a Team Explorer 2008 or older client.

Problem Statement

Customers who open a Microsoft Project plan created from a Team Explorer 2010 client with a Team Explorer 2008 or older client will cause the plan to become unusable.

Workaround

Do not port project plans to other Microsoft Project tools using older client add-ins during Beta 1.

10) Team Explorer 2008 or older client will not be able to manually queue a build without having the “View Build Resources” permissions.

Problem Statement

Build permission on upgrade were not automatically set to enable Team Explorer 2008 or older client users.

Workaround

Contact the Team Project Administrator to have the build permissions elevated for Team Explorer 2008 client users, if no build agents are visible in the Queue Build dialog in Team Explorer 2008.

11) Team Explorer 2008 or older clients will not be able to manage build resources using the “Manage Build Agents” dialog box.

Problem Statement

The “Manage Build Agents” dialog box disabled for the old client user and users get the following error message when trying to edit, add or delete: “Updating build agents is not supported from this client. Please use a client compatible with Team Foundation Build Codename Rosario and try again.”

Workaround

Use Team Explorer 2010 to manage build resources.

12) Team Explorer 2008 or older clients will be able to submit changes that affect gated build definitions, but they will not be prompted with the confirmation dialog and, if their check-in affects multiple gated definitions, it will fail.

Problem Statement

The customer may not know if they were successful or not.

Workaround

The customer can check the build explorer (just like a Team Explorer 2010 user would) or use the build notification applet (2008 power tools release rather than 2010 release).

13) Team Explorer 2008 or older client users can create new build definitions but they will not be able to edit them or to edit other, existing build definitions.

Problem Statement

New build definitions will be automatically upgraded to Team Foundation Server 2010 build definitions using the upgrade build process template, so Team Explorer 2008 or older client users will not be able them.

Workaround

Use Team Explorer 2010 Client to get the WF designer experience or to edit build definitions or use a text or XML editor to edit the build process template.

Team Foundation Server 2010 - Relational Warehouse and Cube Schema Changes

Team Foundation Server 2010 is a BIG release for us by all counts. We have made conceptual changes; Brian introduced some of the key concepts in TFS 2010 that includes the concept of Team Project Collections (TPCs). These changes required a lot of infrastructure support that we built from the ground up and changes to all the subsystems including the warehouse adapters, relational warehouse schema and the Analysis Services cube schema.

As our Beta 1 release approaches, I wanted to outline the changes to the relational warehouse and cube schema. These are, unfortunately, breaking changes. While we will provide an updated set of out-of-the-box reports (details below), these schema changes will affect your custom reports. By custom reports, I mean SQL Server Reporting Services (SSRS) or Excel pivot table/chart reports you may have authored against the warehouse or cube.

Read the rest of the post: http://blogs.msdn.com/sunder/archive/2009/05/16/team-foundation-server-2010-relational-warehouse-and-cube-schema-changes.aspx

Sunder Raman

Program Manager, Team Foundation Server

Previous State and State Change Count

Today I am going to look at two interesting fields in the Warehouse related to Work Items – Previous State, and State Change Count.

The Previous State field stores the state a Work Item was in before it entered its current state.  This field is in the [Work Item] table in the relational/dimensional Warehouse and in the [Work Item] Dimension in the Cube.

The State Change Count measure counts the number of changes in State between a Work Item revision and its previous Revision (actually instead of 0 it will have a value of NULL – so it will either have a value of 1 or NULL).  It is in the [Work Item History] table in the relational/dimensional Warehouse and in the [Work Item History] measure group in the Cube.

The easiest way to understand their values is with an example.  In this example we are going to create a new Work Item and then edit it several times.  The table shows the values in the Warehouse (of course all of these are not in the same table in the Warehouse – but showing it like this makes the example simpler).

1.       Create a new Work Item.

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1

 

The Previous State is NULL because prior to Revision 1 the Work Item had no state.  The State Change Count is 1 because the Revision changed from state NULL to state Active.

2.       Modify a field other than state (i.e. Title)

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1
1	2	Active	NULL	NULL	1/2

 

The State the Work Item was in, before it was in its current state, is still NULL.  The state of Revision 2 didn’t change from Revision 1 so the State Change Count is NULL.

3.       Modify the state (i.e. Resolve the Work Item)

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1
1	2	Active	NULL	NULL	1/2
1	3	Resolved	Active	1	1/3

 

Now the State the Work Item was in before it was in its current state is Active.  The state changed so the State Change Count is 1.

4.       Modify a field other than state (i.e. Title)

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1
1	2	Active	NULL	NULL	1/2
1	3	Resolved	Active	1	1/3
1	4	Resolved	Active	NULL	1/4

 

5.       Modify the state (i.e. Reactivate the bug)

ID	Rev	State	Previous State	State Change Count	Date
1	1	Active	NULL	1	1/1
1	2	Active	NULL	NULL	1/2
1	3	Resolved	Active	1	1/3
1	4	Resolved	Active	NULL	1/4
1	5	Active	Resolved	1	1/5

 

Alright I think it is clear what the values will be for these fields… now what good are they?

The Previous State serves as a cache of state the work item before it entered the current state.  Without this one would have to walk back work item revisions until you found one that had a different state.  The Previous State can be used to answer questions like:

For my Work Items that are currently Active, how many of them have been reactivated (Previous State = Resolved)?  A large number of reactivated Work Items may indicate developers are not doing enough unit testing.

The State Change Count gives us a way to quickly identify revisions where the state changed.  Using this along with the Previous State you can identify things like resolved rates per day or incoming rates per day.  For example if you looked for Work Item revisions with State = Resolved, Previous State = Active, and State Change Count = 1 you would get those revisions that were resolved – and the dates.  Note that if a work item was reactivated then resolved again you would get it back two times – this may or may not be what you want for your report.

[Cross Posted from blogs.msdn.com/nericson]

Work Item rules workaround: Cannot close task unless Remaining Work is zero

In the last post in this series, Gregg blogged about restricting a bug such that only the creator can close it. This is the last post in this series of workarounds that we have been blogging about. We saved this as the grand finale for our series.

 

Customers have asked us: “I don’t want to allow users to close a task unless they have set Remaining Work to zero”

 

Here’s the solution:

1. Create a RemainingWorkValidation field

2. Add it to the form definition under the validation tab like the previous examples

3. Add the following rules to the RemainingWorkValidation field

<FIELD type="String" name="Remaining Work Validation" refname="Demo.RemainingWorkValidation">
  <ALLOWEDVALUES>
    <LISTITEM value="No Errors" />
  </ALLOWEDVALUES>
  <WHEN field="Microsoft.VSTS.Scheduling.RemainingWork" value="0">
    <COPY from="value" value="No Errors" />
  </WHEN>
</FIELD>

4. Add the following rule on the transition to closed state

<Transition from="Active" to="Closed">
  <REASONS>
    <REASON value="Deferred" />
    <REASON value="Obsolete" />
    <REASON value="Cut" />
    <DEFAULTREASON value="Completed" />
  </REASONS>
  <FIELDS>
    <FIELD refname="Demo.RemainingWorkValidation">
      <WHENNOT field="Microsoft.VSTS.Scheduling.RemainingWork" value="0">
        <COPY from="value" value="Remaining work has to be zero before closing the work item" />
      </WHENNOT>
    </FIELD>
  </FIELDS>
</Transition>

5. Add the following rule to active state

<State value="Active">
  <FIELDS>
    <FIELD refname="Demo.RemainingWorkValidation">
      <COPY from="value" value="No Errors" />
    </FIELD>
  </FIELDS>
</State>

 

6. Add the following rule to closed state

<State value="Closed">
  <FIELDS>
    <FIELD refname="Demo.RemainingWorkValidation">
      <WHENNOT field="Microsoft.VSTS.Scheduling.RemainingWork" value="0">
        <COPY from="value" value="Remaining work has to be zero before closing the work item" />
      </WHENNOT>
    </FIELD>
  </FIELDS>
</State>

 

Here’s what it looks like:

A word of caution, one of our readers ran into an issue with Team System Web Access with the previous closing an iteration workaround where the UI doesn’t refresh on WHEN rule. Though I haven’t had a chance to try this workaround using Web Access, the WHENNOT rule used here may have a similar issue in Web Access.

Sunder Raman

Program Manager, Team Foundation Server

[Cross-posted from http://blogs.msdn.com/sunder]

Work Item Rules Workaround: Only the creator of the bug can close the bug

In our last post in this series, Sunder blogged about saving the resolved reason. (You’ve probably figured out that we have “tag-teamed” this blog series). So anyway, here is the next item in the series.  Customers have asked us:

“I only want the creator of the bug to be able to close the bug … no one else”

“Oh … and by the way, I want to be able to have an administrator override and close a bug for anyone”

Another valid request, again which is not handled well with standard implementations of work item rules. In fact, Sunder and I tried and tried to figure this one out, and simply couldn’t come up with a solution.

Then I offered a $5 reward to a developer who said he could figure it out. Well I’m out $5, but now have something to offer to solve this problem. Worth the $5? You can be the judge…

 

Here are the steps:

1) Create ClosedByValidation field and add the following rules:

<FIELD name="Closed By Validation" refname="Demo.ClosedByValidation" type="String">
    <COPY from="currentuser" />
    <FROZEN not=“[project]\Project Administrators”/>
</FIELD>

 

2) Add the following rules to Closed state

<STATE value="Closed">
   <FIELDS>
      <FIELD refname="Demo.ClosedByValidation">
          <COPY from="currentuser" />
       </FIELD>
   </FIELDS>
</STATE>

3) Add the ClosedByValidation field to the form, so it looks like this. Note how I’ve displayed both the “Created By” field and the “ClosedByValidation” field.

 

How it works:

• The ClosedByValidation field copies the “Created By” value into itself right when the work item is created.
• It then immediately freezes the field (with the FROZEN) rule, which states that it cannot change.
• NOTE: The FROZEN rule is conditioned to NOT apply to project administrators, giving them an override capability.
• When the work item is Closed, then the current user is copied into the ClosedByValidation field.
• If the ClosedByValidation’s value remains the same (the original Created By) then all is well.
• If the ClosedByValidation’s value has changed, then the FROZEN rule displays a violation as you see in the screenshot above.

Pretty clever Mr. Developer.

CodePlex Tool: WIT Synchronizer

I just saw that Loic Baumann posted a tool on codeplex called WIT Synchronizer. It provides two pieces of functionality that has often been requested.

“I’ve made a change to my Process Template, how do I push those changes to existing projects”

“I’ve made some updates to my process in an in-flight project, and now want to update my Process Template with those changes”

I haven’t played around with this yet, but have plans to. I just wanted to get the word out.

Once I’ve played with it, I’ll let you know the results.

Work Item rules workaround: Saving the resolved reason

In our last post in this series, Gregg blogged about securing a work item type. Another question along these lines: “How can I save the resolved reason? I want to create metrics based on how bugs were resolved, but the value of the ‘Reason’ field is changed when the bug is closed”

Here’s the solution:

1. Add “Microsoft.VSTS.Common.ResolvedReason” field to the form definition

2. Add the following rules to the workflow transition from “Active” to “Resolved”

<Transition from="Active" to="Resolved">
   <REASONS>
    <REASON value="Fixed">
      <FIELDS>
        <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
          <COPY from="value" value="Fixed" />
        </FIELD>
      </FIELDS>
    </REASON>
    <REASON value="Deferred">
      <FIELDS>
        <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
          <COPY from="value" value="Deferred" />
        </FIELD>
       </FIELDS>
    </REASON>
    ...
</Transition>

Here’s the end result; I am displaying the field in the Details tab of the Bug form:

This workaround works by copying the resolved reason when the bug is resolved off into the Resolved Reason field.

Sunder Raman

Program Manager, Team Foundation Server

[Cross-posted from http://blogs.msdn.com/sunder/]

Work Item Rules Workarounds: Secure creation of a work item type

In our last post in this series, Sunder blogged about Deactivating a work item type. Here’s another popular request: “Secure creation of a work item type”. For example, people say:

• “Only my Testers can create bugs”
• “Only my Business Analysts can create Requirements”

This is a legitimate request and we don’t have a good answer in Work Item Tracking, but do have AN answer.

First you add the following rules to the default transition.

<Transition from="" to="Active“ for=>
  <REASONS>
    <DEFAULTREASON value="New" />
  </REASONS>
...
</FIELDS>

   <FIELD refname="System.State">
      <READONLY not="[project]\Business Analysts" />
   </FIELD>
  </FIELDS>
</Transition>

The group “[project]\Business Analysts” should then be populated with the users that can create this work item type.

Now if a user who is NOT in the group attempts to save a work item of that type, this is what he/she will see:

This is the approach we’ve found that works the best. But be aware of these issues:

• It doesn’t prevent a non-approved user from creating a work item of that type, only from saving the work item of that type. Not the best experience.
• The error message, of course, isn’t the best.

But it does do its job.

Someone who many have tried to solve this problem before, may be asking. Why aren’t we using transition security? Transition is the ability to allow only certain users to make a transition between work item states. Using this method, you would do this:

<TRANSITION from=“" to=“Active"

     for="[project]\AllTesters" not="[project]\Business Analysts">

</TRANSITION>

The reason we didn’t like that method, is because of the error message you received:

“The field ‘State’ contains a value that is not in the list of supported values”

So … when choosing a method, we chose the one that displayed the error message closest to what we’d like to show.

That’s it!