With the release of Visual Studio 2017 I made the decision to uninstall 2015 a couple of days ago. This immediately presented me with two challenges:

1. My unit tests stopped working when run on my private build agents.
2. I could no longer push to my VSTS Git repositories. This turned out to be my error but I’ll cover that one in a separate post…

In this post I’ll surface some options to resolve the issue and justify why I chose one particular solution.

It seems that when you add the Visual Studio Test build task it sets the VSTest version to Visual Studio 2015 by default:

This means when the build attempts to run the unit tests it now couldn’t find vstest.console.exe as I assume it’s looking in the old C:\Program Files (x86)\Microsoft Visual Studio 14.0 path.

******************************************************************************

Starting: Test Assemblies

******************************************************************************

==============================================================================

Task : Visual Studio Test

Description : Run tests with Visual Studio test runner

Version : 1.0.84

Author : Microsoft Corporation

Help : [More Information](https://go.microsoft.com/fwlink/?LinkId=624539)

==============================================================================

Preparing task execution handler.

Executing the powershell script: C:\Users\SimonLamb\Downloads\vsts-agent-win7-x64-2.111.1\_work\_tasks\VSTest_ef087383-ee5e-42c7-9a53-ab56c98420f9\1.0.84\VSTest.ps1

No results found to publish.

System.Management.Automation.CmdletInvocationException: Unable to determine the location of vstest.console.exe —> System.IO.FileNotFoundException: Unable to determine the location of vstest.console.exe

at Microsoft.TeamFoundation.DistributedTask.Task.Internal.InvokeVSTestCmdlet.GetVsTestLocation()

at Microsoft.TeamFoundation.DistributedTask.Task.Internal.InvokeVSTestCmdlet.ProcessRecord()

at System.Management.Automation.CommandProcessor.ProcessRecord()

— End of inner exception stack trace —

at System.Management.Automation.Runspaces.PipelineBase.Invoke(IEnumerable input)

at System.Management.Automation.PowerShell.Worker.ConstructPipelineAndDoWork(Runspace rs, Boolean performSyncInvoke)

at System.Management.Automation.PowerShell.Worker.CreateRunspaceIfNeededAndDoWork(Runspace rsToUse, Boolean isSync)

at System.Management.Automation.PowerShell.CoreInvokeHelper[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)

at System.Management.Automation.PowerShell.CoreInvoke[TInput,TOutput](PSDataCollection`1 input, PSDataCollection`1 output, PSInvocationSettings settings)

at Microsoft.TeamFoundation.DistributedTask.Handlers.LegacyVSTSPowerShellHost.VSTSPowerShellHost.Main(String[] args)

LegacyVSTSPowerShellHost.exe completed with return code: -1.

******************************************************************************

Finishing: Test Assemblies

******************************************************************************

There’s actually a few solutions to this but I’ll throw down three because it’s nice to have options. 🙂

1. Specify the location to the vstest.console.exe executable. It’s located in the Visual Studio directory which has now dropped the version number and is just C:\Program Files (x86)\Microsoft Visual Studio\2017\.

2. Choose Latest for the Test platform version.

3. Flick the test task to Version 2.0 which opens up some more options for the Test Platform version.

This means you have some different options in the Test platform version. Note there is no Latest on the Version 2.0 task.

Selecting Visual Studio 2017 will also solve your problem.

Which option did I go with? I chose to specify the Test platform version as Latest so that my build definitions would work on both my machine running the private agent or a hosted agent. The other options would work fine but this ensures it still works regardless of the environment.