Cannot find vstest.console calling from command line

[Greg Polito]

I am trying to use vstest.console, because I need to use the runsetting parameters. I am using the command prompt, because I am needing to call the runsetting file to grab the parameter, instead of getting the deprecated command that I can't think of right now.

Here is the command line script, 

vstest.console.exe cit-xxx-automatedtesting.dll /settings:e:\development\cit\cit-xxx-automatedtesting\code\dev-default.runsettings /TestAdapterPath:e:\development\cit\cit-xxx-automatedtesting\packages\mstest.testadapter.1.4.0\build\_common (Executable is powershell)

This works on the server from any directory, because it is in the path. But when running from bamboo, it cannot find vstest.console. We are using the system user, not the localadminuser. Do we need to use the local admin user (and why?), or what can I be missing? Thanks for the help.

[Daniel Santos]

Hi @Greg Polito

I'm afraid that your PATH variable does not have the same value when Bamboo is running as LocalSystem account. You could check this through:

1. Add the command SET right before the vstest.console.exe call.
2. Run the command SET in the server terminal with a normal user account that can execute vstest.
3. Compare the results.

You need to make sure the PATH variable will have the needed reference to find the program you are trying to use.

⚠️ Please keep in mind that you need to restart Windows when a change in system variable is performed and you want it to show up for in the service environment.
Reference: Changes that you make to environment variables do not affect services that run under the Local System account until you restart Windows

We do recommend that Bamboo is run as a local admin account (Running Bamboo as a Windows service as the local user) to make sure apps running from it can have access to the user interface. Apps like Selenium have trouble to work when running with a LocalSystem account.

Services running in an elevated security context, such as the LocalSystem account, should not create a window on the interactive desktop because any other application that is running on the interactive desktop can interact with this window. This exposes the service to any application that a logged-on user executes. Also, services that are running as LocalSystem should not access the interactive desktop by calling the OpenWindowStation or GetThreadDesktop function.

Reference:  Interactive Services - Windows applications | Microsoft Docs

I hope that answers your question.