Home/ Questions/Q 8445765
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-10T09:44:36+00:00

So I’ve downloaded VS2012 RTM and upgraded my Coded UI test projects to the

  • 0

So I’ve downloaded VS2012 RTM and upgraded my Coded UI test projects to the VS2012 versions.

The reason I have done this is because I was having issues with VS2010 Coded UI tools due to partial support of IE9.

So I ran the tests from my developer machine both locally and remotely (making use of the new Visual Studio agent tools), and the tests worked successfully. Presumably, the reason my tests now work is that VS2012 upgraded them so that they now work with IE9, right?

So – this is my problem. I want to automate these tests, by launching them from our build machine – but our build machine still runs on VS2010, and for the time-being this is not going to change.

So I checked in my new VS2012 Coded UI test solution into TFS and queued a new build – so the build machine built my solution. And the build was successful. All good there.

So, next I created a new test case in Microsoft Test Manager and associated with the ordered test list in my new solution. Then I launched the tests (using the existing VS2010 test controller) on my remote test environment (which has the existing VS2010 test agent tools).

But the tests failed – the same issues that affected my tests with the VS2010 Coded UI tests (due to lack of full support for IE9)

Why did they fail?

Do I need the new VS 2012 agent tools for my test controller and agents? Must I build my solution in VS2012?

Ideally, I don’t want to have to install VS2012 RTM on my build machine – I want to do the minimum possible to get my tests working and automating.

Is there a way around this?

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Your coded ui tests reference assemblies that come with VS installation or your agent’s installation (the assemblies defininf the WpfControl, Mouse, Keyboard, Playback and other classes).

    So if you run it on a build/test machine with older versions of the dll’s the same issues are going to stay, the tests will not start using the newer fixed assemblies thatt were shipped with VS2012.

    As a temporary workaround you can check what dll’s you reference and make sure that the build process puts them in the same directory with your tests assembly. That way the lookup for them will find the in the current directory without using the /path and finding them in the VS installation directory.

    • 0