Scaled Agile Framework: Using TFS to support epics, release trains, and multiple backlogs whitepaper

The SAFE whitepaper + download was just launched today. See the announcement by Greg Boer at the MSDN ALM blog.

This was the result of lots of hours of internal contribution by the ALM Rangers.

The whitepaper provides both a high level view of how SAFe is realized using TFS, as well as detailed configuration/customization details.

In addition to the whitepaper, this release includes a download of the Visual Studio out-of-box process templates, with SAFe related customizations already made: Team Foundation Server 2013 Process Template Samples - Support for Scaled Agile Framework (SAFe).

This pretty much addresses Gartner’s concerns in their latest ADLM state of the industry report, showing a  quick turnaround from Microsoft to get these addressed.

Issue: updating Field AllowedValues that differ only by casing


Say you created a field and by mistake, there was a typo in one of the allowed values:

<FieldDefinition name="FieldToTestLowerUpperCase" refname="Custom.FieldToTestLowerUpperCase" type="String">
   <ALLOWEDVALUES expanditems="true">
     <LISTITEM value="Out of scope" />
     <LISTITEM value="Value 1" />
     <LISTITEM value="Value 2" />

What you really wanted was “Out of Scope”, not “Out of scope”:

<FieldDefinition name="FieldToTestLowerUpperCase" refname="Custom.FieldToTestLowerUpperCase" type="String">
   <ALLOWEDVALUES expanditems="true">
     <LISTITEM value="Out of Scope" />
     <LISTITEM value="Value 1" />
     <LISTITEM value="Value 2" />

Using Process Editor, even if you modify and republish the value, it does not change the casing.


I have been able to replicate your scenario with Process Tools Editor within VS 2013 Update 3 and TFS 12.0.30723.0 (Tfs2013.Update3).

I deleted the field using Process Editor to take it out of a custom Task, and then deleted it in the command line with witadmin:

witadmin deletefield

/collection:http://<tfsserver>:8080/tfs/<yourcollection> /n:Custom.FieldToTestLowerUpperCase

then re-added it using Process Editor with the right case (“Out of Scope”) and told it to rebuild the cache (“witadmin rebuildcache”). It still did not work, it still kept the same value.

I applied a simple change (add an extra space between “of” and “Scope”, saved it) and the new one had the uppercase plus the extra space (“Out of  Scope”). Then I modified the new field to use just a single space, rebuilt the cached, but it returned to using lowercase (“Out of scope”).

To see whether it was a bug with Process Editor, I did all operations using just witadmin in a command line prompt. It still did not work: even after an update, I would retrieve the work item definition and it would show the word “scope” in lowercase.

This value was cached somewhere, and not being able to update it is definitely a bug. By looking into the Fields table I confirmed that nothing really is deleted, only marked as deleted, and most likely it is reused when the value is reinserted. In addition, when a field AllowedValues is changed, the Import method (either using Process Editor, witadmin or the API) does not consider casing when checking whether the value needs to be updated.


I found the “Out of scope” value in the TFS Constants table (within the collection database):


PartitionId, ConstID, DomainPart, fInTrustedDomain, NamePart, DisplayPart, String, ChangerID, AddedDate, RemovedDate, SID, Cachestamp, ProjectID, TeamFoundationId, fReferenced

FROM Constants

WHERE (DisplayPart = 'Out of scope')

ORDER BY DisplayPart

Next I manually updated it to “Out of Scope”, and refreshed. This fixed the issue.

ATTENTION: Do this at your own risk, as modifying TFS tables directly is neither recommended nor supported, and might put your database in an unsupported state. I tested this on a sample TFS installation, which is not in production.

I only provided this workaround as a last resort and because it was a simple enough update of a string value. A better, supported path would be to open a case with Microsoft support using your MSDN incidents, and have it escalated to the Product Team as a Bug (I might also open a bug with Connect later, and will post the link here).

A few pointers on how to use Delphi applications with Coded UI

To use Delphi-based UIs with Coded UI tests you would need to implement the MSAA interface for each component you would want to use/have it visible with Coded UI.  Example implementations:

-          TEdit:

-          TreeView

The Coded UI extensibility framework works mostly with MSAA compliant applications ( However, if you  can’t get the Delphi source code and enable MSAA, you will have to do with the plain Windows Win32 support ( ).

Is it possible to build a plug-in or add-on in .NET using Coded UI extensibility for identifying Delphi (VCL) UI controls native properties (like id, control name)? As mentioned before, it is the UI control itself that has to expose MSAA compliant properties to be visible, that is, the TEdit or TForm needs to implement it. However the documentation on how to used CodedUI with Silverlight states the following:

“To test your Silverlight applications, you must add Microsoft.VisualStudio.TestTools.UITest.Extension.SilverlightUIAutomationHelper.dll as a reference to your Silverlight 4 application so that the Silverlight controls can be identified. This helper assembly instruments your Silverlight application to enable the information about a control to be available to the Silverlight plugin API that you use in your coded UI test or is used for an action recording.

If I understand this correctly, it might be possible to do the same for Delphi CLR .NET applications at the assembly level (I have not seen any reference implementation on how to do this though). For applications compiled to native code you would have to go to the source as explained above.

Issue: Failed to push new glyph for <file-excluded-by-gitignore> Return code from SccGlyphChanged was -2147024809


Visual Studio 2013 Ultimate Update 3 RTM with Microsoft git provider returns error "Failed to push new glyph for <file-excluded-by-gitignore> Return code from SccGlyphChanged was -2147024809." in Output window.


Issue occurs every time an a file is modified in an editor. The focus switches to the Output window with label "Source Control  - Git". An error message as above is returned for each file excluded by patterns in .gitignore.


This an issue with the way that Solution Explorer is interacting with the notifications from the git source control provider.

A glyph is a source control UI element, that is all those little symbols on the left side of the file in Solution Explorer, as explained in implementing a source control provider. This post talks at length about what is going on in a general fashion, including explaining what the error message number means.

What is missing is the connection with .gitignore patterns. This might point to some logic error in the code that handles the background processing that updates the Solution Explorer UI every time a file source control status is modified by editing it in place.

User was using Update 3 RC prior to installing Update 3 RTM, therefore this might be a left over from RC.

I looked into another related issue with .gitignore that when you have a specific exclusion rule (say "/TFS"), it does not process the file (with a name that starts with "TFS"), plus the Solution Explorer glyph changes to that of a committed file. The workaround for this was to take out the .gitignore rules. Another would be to through suppressing the Output window activation and filtering out messages related to this error by using its automation interface.

All points to an issue with the way that the git provider interacts with the Visual Studio UI.


I have confirmed with Microsoft that this is a bug and that it has been fixed in an upcoming version.


<<  February 2017  >>

View posts in large calendar

Month List