Testing.Fakes Exception: Failed to resolve profiler path from COR_PROFILER_PATH and COR_PROFILER environment variables

Question

Test which use Microsoft Fakes Framework fail with exception: Microsoft.QualityTools.Testing.Fakes.UnitTestIsolation.UnitTestIsolationException: Failed to resolve profiler path from COR_PROFILER_PATH and COR_PROFILER environment variables

VS solution and builds were originally created in VS 2012 and run fine under TFS 2012 build/ controller, but not under TFS 2013. I do have Ultimate VS 2012 and Ultimate VS 2013 installed on TFS 2013 build server. While troubleshooting this issue, I changed test setting in the build definition from using "Visual Studio Test Runner" to "MSTest.exe Test Runner (VS 2010 Compatible)", and now not able to change it back as "Visual Studio Test Runner" is no longer an option in the drop-down of choices. I even replaced build template in TFS 2013 with the one in TFS 2012 but "Visual Studio Test Runner" is still not an option in the drop-down of choices in the build definition Process\Automated Tests section while editing Test Run.

How to solve the problem and get the tests which use Microsoft Fakes to run in TFS 2013 build?

Answer 1

I was having this exact same problem and it turned out that I had a .testsettings file created in my solution and was telling the test runner in the IDE to use it. If you are getting this error in the Visual Studio IDE, verify that you do not have a .testsettings file specified by going under the Test menu -- if there is a .testsettings file specified with a checkmark next to it, click it to remove the checkmark. I suspect the presence of the .testsettings file causes Visual Studio to initialize the test runner differently.

If this is happening on the build server, verify that your build definition does not have a .testsettings file specified; ideally, perhaps remove the file altogether from source control and/or your solution. The presence of this file can trip up a TFS build.

Answer 2

I got the exact same error, but in my case it was a bug in ReSharper 2017.3.1: https://youtrack.jetbrains.com/issue/RSRP-467796

Already fixed in ReSharper 2018.1