Visual Studio 2015 CodedUI测试无法在2017年签入后加载2013年dll

Question

I didn't run into this problem, but a member of my team did. Most of the team is working in a Windows 10 environment, using Visual Studio 2015 Enterprise. This one particular team member is using Windows 7 (we started upgrading last year, but they have chosen not to do so...though this may force them to). However, that is the only difference that I can see (they are using Visual Studio 2015 Enterprise).

We have another team that we work closely with that is using Visual Studio 2017 (our team should be upgrading soon, but we're not there yet). One of those members made a check in to our Testing solution (which is all CodedUI tests) that altered all of our project files. However, the only change that I can see is that the false property was added to the Microsoft.VisualStudio.QualityTools.CodedUITestFramework reference (it didn't change the version called out, which is 14.0.0.0).

My environment handled this changed just fine (Windows 10, VS2015) but the one team member with Windows 7 is seeing the following error when they try to run a test:

Could not load file or assembly 'Microsoft.VisualStudio.QualityTools.CodedUITestFramework, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified..

I guess I should note that we started writing our Testing solution in VS2013, originally. That's why the reference is to 12.0.0.0. Also, the environment in question has both versions of the dll available.

It doesn't matter which test they try to run, all of our tests throw this error. The Testing solution builds just fine on their environment, so everything is compiling fine.

Any suggestions? I think our immediate solution is to get all of our environments upgraded, but I'd like to understand why this error is happening. We've seen it before (around the time when we upgraded from VS2013 to VS2015), but just never took the time to investigate.

Answer 1

I'm sure I haven't gotten to the exact root of the problem, but we found that by uninstalling Visual Studio 2013 from the environments in question fixed the error. The problem actually had nothing to do with Windows 10 vs. Windows 7.