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">
<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">
<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:
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
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).
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:
The Coded UI extensibility framework works mostly with MSAA compliant applications (http://msdn.microsoft.com/en-us/library/dd380742.aspx). However, if you can’t get the Delphi source code and enable MSAA, you will have to do with the plain Windows Win32 support (http://msdn.microsoft.com/en-us/library/dd380742.aspx ).
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.
When launching a test from MTM, either manual or automated, it would get the message, MTM does not launch Test Runner and fails to do anything. The following error message was added to the Event Log after failure:
<Provider Name="VSTTExecution" />
<Data>(mtm.exe, PID 16168, Thread 1) Exception: System.IO.FileNotFoundException
Message: Could not load file or assembly 'Microsoft.VisualStudio.TestTools.UITest.WindowsStoreUtility, Version=126.96.36.199, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
We tried running it from another computer to isolate the Visual Studio Ultimate as the issue. It worked on another computer with Visual Studio Ultimate 2013 Update 3. The failing computer had Visual Studio Ultimate Update 2.
Root cause was not determined. Installing Update 3 fixed it.
The Austin TFS Users Group leadership team has weekly meetings over the phone to plan, develop and deliver bimonthly presentations based on community activities, and we welcome presenters who have ongoing practical experience with implementing ALM with TFS. Please send us an email if you are interested, or let us know at one of our meetings.
The leadership team had just had our quarterly face-to-face meeting on July 17th at Chez Zee on 5406 Balcones Dr., Austin, TX. In the picture below we have, from left to right:
George Altenbaugh, Amanda McConville, Tim Pacl, Clementino de Mendonça, and Joe Murphy. Missing from the picture is Bob Hardister, who could not attend because of a last minute impediment at work.
For the record: our team did not use user group funds for lunch: each person paid their own meal.
When using a TFS 2013 task backlog with more than 500 items, the following message is displayed:
You have exceeded the number of items allowed on your task board. The number of items to be displayed on the task board is: 578. This exceeds the allowed maximum of: 500. This maximum limit is configurable.
To resolve this issue, you can perform one of the following tasks:
· Reduce the number of items included in the current sprint.
· Your project administrator must increase the maximum number of allowed items.
You follow the second link, and you are taken to the following page which has outdated information:
Refer to the updated information for TFS 2013:
Although a user is already part of a TFS group, he can't access TFS work items (source code is fine), and TFS Web client/Visual Studio display the following message:
TF201072: A user or group could not be found. Verify that the users and groups used in your work item type defiition have been added to Team foundation server.
The cause is related to some snag in the TFS identity synch service, and it is usually related to a specific collection. There are many articles on the web which help determine the root cause, so here we are only focusing on a fast workaround.
Attaching and re-attaching the collection will force a refresh of the identity synch data, and will usually resolve the issue.
Backlogs have long been used to organize work. I could go back as early as Benjamin Franklin writings on how he dealt with practicing a list of mental virtues in an iterative, incremental fashion.
However I would like to point out two more recent examples, the first one in this post, followed by another post on the second one.
Not many are aware of how Steven Spielberg operated when developing his first block buster, Duel. It was shot in a relentless pace, just sixteen days, at a total cost of $425,000 – after all it was originally a TV movie. Its quality though attracted enough audience that allowed it to be released in Europe and Latin America as a theatrical release, and two years later it also came to movie theaters in the United States as well. Brode’s description of Spielberg’s approach is fascinating as anyone who practices Agile today would recognize what he was doing (my inline comments between s):
[Spielberg] became involved during the time period when Matheson [the original story author] was writing the script, though Spielberg did not consult with him during the writing process. Methodically he blocked out the entire film on IBM cards [the backlog], the first time he tried what would become his regular approach. Each card contained the gist of the scene, the angle he would take on it, and how many camera setups he needed. While filming in Lancaster, he assembled those cards on a huge bulletin board in his motel room [the task board]. Rather than opening the script to the day’s page, he would instead take down several cards. They constituted the day’s work [daily iterations – after all it was sixteen day project], and when each scene was finished, he would tear the card up and throw it away, knowing every night, by glancing at the bulletin board, how much was left to complete.
In addition to cards, he had his art director sketch the entire film on one long mural that arced around the motel room, an aerial view portraying every moment in the movie [the user story map], including chases. Never a great reader, Spielberg liked to avoid referring to his script and memorizing blocks of words, preferring to study this visual panorama, locking himself into it before filming any one day.
The films of Steven Spielberg, by Douglas Brode
I brought this extract to show that using backlogs has always been a way of working in the minds not only of software developers under a delivery pressure, but also of the general public. Well, at least for smaller projects – the DOD distortion field that swept the 70’s leading to Waterfall stems from the need of extra planning big projects under extreme risk pressure.
Hopefully this example shows how people while thinking create new ideas, which are eventually formalized as a best practice (I will bring that up on the next post related to backlogs), and finally automated in a tool such as Team Foundation Server 2013.
Where did Spielberg have the idea of using IBM punch cards? Maybe by interacting with friends at the university Computer Science department? If you happen to have a chance, please ask Spielberg for me.
I will be presenting on how to access a TFS Git repository programmatically on April 11th, from 11:30 to 1 PM.
If you are in Austin and would like to attend, please register at: http://tfsaustinaprilmeeting2014.eventbrite.com
Now that TFS 2013 supports Git there is a need to replicate on top of this new storage infrastructure the same kind automation that has been well known to TFS users for the past 8 years, for instance, build scripts and other administrative operations so that you can transparently access the repos, the same you can do with TFS Source Control. This talk explores some of the existing options, plus how-tos with code samples, and gotchas.
We intend to record the presentation and make it available online afterwards, so even if you can’t attend in person, check this post a few weeks from now.
Update: the recording is now available at UserGroup.TV.
[for my comments on the previous version of this report, and links to others, see here]
Not sure if you have been able to read the latest Gartner report on ALM, so here goes the link: http://www.gartner.com/technology/reprints.do?id=1-1N99LF3&ct=131120&st=sb
This current version is very precise in positioning both the strengths and perceived weaknesses of the Microsoft ALM platform, especially the “gap of relevance” in the mobile world.
However to me, although precise, this view is just perception. With the integration of Git into the toolset, in addition to the existing Eclipse integration with Team Explorer Everywhere, it now allows for developers across multiple platforms to use TFS (that includes developers of mobile apps for Apple products, for instance). Obviously the main benefit comes from the integrated reporting that it allows, and this should be made very clear to upper management when deciding whether to adopt yet another SCM/ALM tool.
As for the other perceived weaknesses:
- “The vendor lacks a stand-alone requirements management approach; instead, it takes an enhance-and-integrate Office approach.”
- This statement is a common misunderstanding between requirements elicitation and requirements management (I am using the SEI CMMI definitions): Microsoft has supported requirements management (even if bare-bones) since TFS 2005. However requirements elicitation is not properly there yet (although some could argue that it is a basic version). In my consulting experience the best way to handle this gap is to use something such as Blueprint with the business users. Microsoft has had out-of-the box requirements management that has been good enough for Agile teams since the inception of TFS, and has constantly improved on it. I would say that this category either has to be refined into the subcategories I mentioned, or that this statement should be fixed in the next report to acknowledge the actual state of affairs.
- “Microsoft lacks the agile depth of pure-play vendors around project portfolio analysis, and management or support of Scaled Agile Framework (SAFe).”
- It seems that the evaluation was not done using the latest version (TFS 2013) as it has has Agile portfolio features, and more in the backlog for v.next.
- As for the second part of the statement: if you examine the list of SAFe tooling partners up to October of 2013, they only mention three of the report leaders as supporting. I read this page at the time that the report was released on November 19th, and it was still the same three: Rally, VersionOne, and AgileCraft. It is interesting that Gartner chose to single out Microsoft for not supporting it out-of-the-box, instead of also mentioning that when writing about the other Leaders at the time (IBM, Atlassian and CollabNet).
- The fact that most of the Leaders did not yet support SAFe, plus the lack of any Big-5 consulting companies in the Partner directory (it competes with their own offerings) tells me that Gartner elevated a niche-factor to a major-must have feature with yet no market justification. However this niche-factor is getting a lot of buzz so I would expect it to become more important for the market in general by the time of the next report iteration.
- The list of SAFe partners is growing, with the addition of Hansoft, Sellegi and Usecase S.A., and the notable addition of a leader, IBM (to be more precise IBM DevOps – the Agile practice has not mentioned it much other than DAD).
So it is quite clear that after just a few years in the market that TFS not only now sets the pace as the best ALM system available, but it is also the one to catch, having done a maneuver similar to the ice speed skating ones that Viktor Ahn, a Russian/Korean gold medalist did in his impeccable career – a careful tour-de-force that has propelled it to the leadership in the market, and that builds on its own momentum.
I want to thank Richard Hundhausen and Brian Blackman for candid feedback on this post.
When trying to use the Microsoft.TeamFoundation.Build.Activities.Git library I got the error
The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
The detailed error message said it was looking for version 0.13.0.0 of libGit2Sharp.dll. I noticed that through Nuget I had installed 0.14.0.0. I uninstalled it and reinstalled the proper version using Nuget. However the error persisted.
Given that this should work under TFS since it is used by the build system, I looked for, and found the version installed by TFS (at C:\Program Files\Microsoft Team Foundation Server 12.0\Tools). By using ILSpy I discovered that although it has the same version ID (0.13.0.0), it is in fact different as it has a newer dependency on file git2-msvstfs.dll.
Apparently Microsoft had a “buddy build” of libGit2Sharp.dll added to TFS 2013 with the same version number, instead of using the official download at https://github.com/libgit2/libgit2sharp. I later found out what the differences are, and will report that in another post.
When doing operations against TFS repos you should use the version of libGit2Sharp.dll shipped with TFS (installed under C:\Program Files\Microsoft Team Foundation Server 12.0\Tools), as Microsoft did private changes but did not change the version number.