Friday, February 6, 2015 from 11:30 AM to 1:00 PM (CST)
TFS Process Template Customizations
During this presentation you will learn about customizing the process configuration and work item templates for TFS 2013.
Areas covered will be configuring a backlog page, map metastates, assign fields used in agile planning, specify weekend days, and changing the color of a work item type.
Work Item Template: Programmability
TFS work items do not allow scripting or code to run however there are dynamical capabilities such as rules, actions, and certain form controls that can be used to simplify or even automate activities in a work item. We will look closely at these capabilities and explore how they can be used.
George is an ALM Architect/Project Manager/Scrum Master with 20 years of experience working with companies such as Deloitte Consulting, Trilogy/pcOrder, Coremetrics, and Dell. He has managed software development projects for state governments in California, Washington, Kentucky and Texas and companies such as Ingram Micro, Bay Networks, and Volvo. George helped Dell implement TFS as the complete ALM solution for the IT and product development groups. He combined the Scrum and CMMI TFS 2010 templates to model the Dell SDLC and then managed and implemented the TFS Process Template changes to keep abreast of Dell's dynamic development methodology.
George has a B.S. in Computer Science from Indiana University of Pa. and an MBA from Carnegie Mellon University's Tepper School of Business. He is married to Kathy and has 3 beautiful daughters. In his spare time he is a Porsche Club driving instructor and is the President of the Northwest Pony Softball League.
Tim is an ALM Architect/TFS Administrator/Scrum Master currently working for Dell in Round Rock, Texas. He retired from the U. S. Navy in 1996 where he was a nuclear technician and supervisor aboard submarines, as well as a certified navy instructor and instructor trainer. He has been working in the computer industry since 1996 as a developer, build master, and ALM Architect for various companies including Dell, Microsoft, and his own consulting company. Tim holds multiple certifications including Master Training Specialist, Scrum Master, and Universal Refrigerant Technician. He is a member of the Austin TFS User Group leadership team and is a TechNet Guru. Tim has been married for over 30 years and has 4 adult children and 5 grandchildren. In his spare time he resolves issues for his TFS customers, plays with his grandkids, and occasionally sleeps.
Microsoft Ignite seems to be attracting a lot of attention from enterprise folks focused on Azure, Office, and now Skype for business.
Typical sessions (among 273 others) that caught my attention were the ones related to legal compliance in general. I had not yet seen so many interesting sessions on the topic all put together in one place. That’s the kind of topic that really differentiates a conference for the general public from something really targeted at enterprise customers. For instance:
From the horse's mouth: learn how the legal personnel from within Rogers Communication and Microsoft IT started using hold and eDiscovery instead of third party products, and hear best practices learned in real-world scenarios.
Going through a process of legal discovery is a nightmare situation for those who have ever lived it, and it would be interesting to see what technologies can do to make it easier. Microsoft is calling that “eDiscovery for Microsoft Office 365” and “in-Place eDiscovery”.
There are also about 53 sessions on the “Enterprise Developers” category, mostly dealing with Office 365, Skype, and Azure. However for me the crown jewels on this category are:
This session demos using Desired State Configuration (DSC) with Release Management for Microsoft Visual Studio 2013 to tackle real-world deployment challenges. We start by presenting an overview of the key concepts, architecture, and configuration of the various components. We discuss the out-of-the box deployment actions available to compose automations for common deployment scenarios and how to use extensibility to cover the not-so-common scenarios. In more detail, we discuss adding custom DSC resources, how to trigger release as part of a build and how to leverage logs to diagnose failed releases. These are presented through specific scenarios encountered in the field.
With Release Management for Microsoft Visual Studio you can achieve true continuous delivery on any platform. This session demos how to use Release Management for continuous delivery in cross-platform environments including Windows and Linux. We cover how to leverage Desired State Configuration (DSC) and ASP.NET core to create a release pipeline for both Windows and Linux.
I am also curious to see what will be of the Hackathon session:
The cloud-targeted app is failing in production. Competitive time to market advantage is at risk, the business is at an inflection point. "It worked fine in testing!" says the Development Team. "We had no visibility to production infrastructure needs until a week ago!" says the Operations Team. Does any of this sound familiar? Learn firsthand how to embrace a DevOps mindset, evolve your traditional ALM approach regarding people, process and tools, and help your business accelerate its journey to a cloud-first approach! Join us for the DevOps Hackathon @ Ignite where you will team up with fellow attendees from developer and operations roles to apply DevOps practices to a real world challenge. Small teams will be formed at the start of the [session].
I am not sure yet if I will be able to attend, but this if I am then this would be an interesting session to be.
Even if you might not be able to attend, just browsing over the session catalog for Ignite is already a learning experience of what is coming on the Microsoft pipeline.
Call to a .NET Framework assembly on a network folder fails with error:
"Could not load file or assembly 'file://\\server\path\file.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
In this particular case, I wanted to call an assembly with tests which had been deployed using Team Build to a shared folder, then use MSTest in the command line to run them.
MSTest behaved differently depending on whether it is being called from a Windows 2008 R2 Standard server or Windows 8 Client. Using the following command line:
MSTest /testcontainer:\\server\path\file.dll /detail:debugtrace /detail:traceinfo
- From Windows 8 client, user as local administrator: command works as expected. It loads the tests and executes them.
- From Windows 2008 R2 Standard, user as a local administrator: command fails with the following message:
Could not load file or assembly 'file://\\server\path\file.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
Further troubleshooting using 1) a mapped drive 2) PowerShell 3) /testcontainer parameter between quotes show that all these would also fail under Windows 2008 R2 Standard.
The error “Could not load file or assembly” (0x80131515) is a catch-all error. For instance, it is also reported when the exe or dll was downloaded from an unsafe zone. This is fixed by right-clicking the assembly and choosing “Unlock” from the General tab. Sometimes the “Unlock” option won’t show, and in this case it wasn’t.
Blocking is done based on a Zone Identifier alternate stream that is added to a file when it is copied from the Internet. To validate that the file is actually blocked, display this Zone Identifier using the following command (note the direction of the “<” sign – the opposite one would erase the file):
more < file.dll:Zone.Identifer
If ZoneId = 3 or 4, your file is blocked. In our case, the files show no alternate Zone.Identifier stream.
Since copying the files locally to a folder in the Window 2008 R2 Standard server allowed MSTest to execute the tests, this showed that the issue was constrained to some security policy differences between Windows 8 and Windows 2008 R2 Standard. This also confirmed that the files were not blocked.
Next step I looked into the .NET Framework security policy configuration. Using the instructions from this Microsoft blog post I modified the CAS policy settings using the following command prompt:
CasPol.exe -m -ag 1.2 -url file://\\server\path\file\* FullTrust
This added the following record into the CAS policy (CasPol.exe -l):
1.2. Zone - Intranet: LocalIntranet
1.2.1. All code: Same site Web
1.2.2. All code: Same directory FileIO - 'Read, PathDiscovery'
1.2.3. Url - file://\\server\path\file\*: FullTrust
This did not resolve the issue as expected, but the following error started to be reported on the Event log:
Log Name: Application
(MSTest, PID 2000, Thread 1) AssemblyEnumerator.EnumerateAssembly threw exception: System.IO.FileLoadException: Could not load file or assembly 'file://\\server\path\file.dll' or one of its dependencies. Operation is not supported. (Exception from HRESULT: 0x80131515)
File name: 'file://\\server\path\file.dll' ---> System.NotSupportedException: An attempt was made to load an assembly from a network location which would have caused the assembly to be sandboxed in previous versions of the .NET Framework. This release of the .NET Framework does not enable CAS policy by default, so this load may be dangerous. If this load is not intended to sandbox the assembly, please enable the loadFromRemoteSources switch. See http://go.microsoft.com/fwlink/?LinkId=155569 for more information.
By following the link recommended in the log, I got more information on the issue and how to solve it with the configuration switch loadFromRemoteSources.
From MSDN documentation:
“In the .NET Framework version 3.5 and earlier versions, if you loaded an assembly from a remote location, the assembly would run partially trusted with a grant set that depended on the zone in which it was loaded. For example, if you loaded an assembly from a website, it was loaded into the Internet zone and granted the Internet permission set. In other words, it executed in an Internet sandbox. If you try to run that assembly in the .NET Framework version 4 and later versions, an exception is thrown; you must either explicitly create a sandbox for the assembly (see How to: Run Partially Trusted Code in a Sandbox), or run it in full trust.
The <loadFromRemoteSources> element lets you specify that the assemblies that would have run partially trusted in earlier versions of the .NET Framework are to be run fully trusted in the .NET Framework 4 and later versions. By default, remote assemblies do not run in the .NET Framework 4 and later […]. If you set enabled to true, remote applications are granted full trust.
If <loadFromRemoteSources> enabled is not set to true, an exception is thrown under the following conditions:
- The sandboxing behavior of the current domain is different from its behavior in the .NET Framework 3.5. This requires CAS policy to be disabled, and the current domain not to be sandboxed.
- The assembly being loaded is not from the MyComputer zone.”
And, in the same article:
In the .NET Framework 4.5, assemblies on local network shares are run as full trust by default; you do not have to enable the<loadFromRemoteSources> element.
This part of the documentation also shows why it worked on Windows 8: .NET Framework 4.5 is the default for Windows 8.
For validation purposes, I originally applied the recommended setting to machine.config, which is too wide. Later I tested with just MSTest.exe.config and it also worked, which is a smaller recommended scope.
[Verified] Add the following entry to the MSTest.exe.config file (at C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE):
[According to documentation] Use .NET Framework 4.5.
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=22.214.171.124, 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.
Example on how to handle IT support communications with a blog:
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.