Reference missing errors when building coded UI projects with automation on VS 2013 for TFS 2012.

We had an interesting scenario where a customer was using automation with the coded UI projects they had.

The customer was using the name space (System.Windows.Automation) for getting the classes like PropertyCondition and AutomationElement to solve his UI automation problems.

What was weird in the customer’s case was that customer was using VS 2013 as his client, but the TFS server and the build server was still TFS 2012. Team builds started failing, since reference to the Automation namespace were added. But the local build was always successful.

While we don’t recommend this (ideally all the software involved should be of the same level) we decided to take a look on what could be wrong.

His builds on TFS 2012 build machine were failing with these errors –

The type or namespace Condition couldn’t be found
The type or namespace name ‘PropertyCondition’ doesn’t exist in the namespace ‘System.Windows.Automation’
The name AutomationElement doesn’t exist in the current context

However the build ran fine if we removed all the reference to the DLL – even on the TFS 2012 build machine. What we found was the VS 2013 picked these namespaces from UiaComWrapper assembly reference. This reference is added automatically by VS 2013.
You can check this link for more information on this - https://uiacomwrapper.codeplex.com/

We could get the team build working by explicitly specifying the target visual studio version as 12.0 (VS 2013). However this wasn’t an ideal solution as the test agent and test controller were of VS 2012 and the build output we got was not compatible with this. (Issues like this are one of the prime reasons for us suggesting to use the same version of software)

To get this working on TFS 2012(or at target version of VS 2012), we had to add the reference to the UIAutomationClient assembly present in the .NET folder to the project. After we added the reference the Team build started working fine and we could test the build output by running the coded UI test on test agent.

Downside to this was, the reference to UIAutomationClient broke the local build from VS 2013. The local build started failing with the error

The type 'System.Windows.Automation.Condition' exists in both 'c:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\PublicAssemblies\UIAComWrapper.dll' and 'c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5\UIAutomationClient.dll'

This is logical as we have two assemblies having the same set of namespaces referenced within the project. We couldn’t find a way to remove the reference to UIComwrapper as VS seemed to add it back automatically.
So we had to settle with removing the reference to UIAutomationClient when coding locally and then when checking the code into TFS add the reference back.
While this may not be the ideal solution, this did get things moving.

Content created by – Venkata Narasimhan A 
Content reviewed by – Romit Gulati