none
vstest.console. can't be executed remotely RRS feed

  • Question

  • Hi team,

    I am writing a PS script to execute tests remotely. First the test assemblies are copied to the remote machine, and then use the Invoke-Command -ComputerName $remoteComputerName ... to execute vstest.console. However, vstest.console with /Platform:x64 InIsolation fails with below error message.

    vstest.console : Error: Failed to initialize client proxy: could not connect to vstest.discoveryengine.exe.
        + CategoryInfo          : NotSpecified: (Error: Failed t...veryengine.exe.:String) [], RemoteException
        + FullyQualifiedErrorId : NativeCommandError

    Error: There was no endpoint listening at net.pipe://remoteComputerName/vstest.discoveryengine/9524 that could accept the
    message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

    It seems that in isolation mode, there is an additional process named vstest.discoveryengine to do work. Maybe there is something wrong with this process.

    Interestingly, when I run vstest.console WITHOUT the x64 platform set, everything is fine. And i also find there is only one process name 'vstest.console.exe' running.

    So what am i gonna do to make x64-platform vstest.console running remotely?

    Env information:

    I've installed the Microsoft Visual Studio Agents 2012/Test Controller 2012 on my Windows Server 2012 R2

    Thanks,

    -Jingfei


    Keep involved!


    • Edited by Jingfei Friday, June 26, 2015 8:22 AM
    Friday, June 26, 2015 8:14 AM

All replies

  • Hi Jingfei,

    What type test you want to run remotely by the vstest.console.exe in the PS script?

    As far as I know that it is default that there are 2 ways run automated tests remotely.

    One way is that we could run automated test remotely by configuring the test controller and test agent and set their in the test setting file from the VS IDE.

    Reference:

    https://msdn.microsoft.com/en-us/library/hh546459.aspx

    https://msdn.microsoft.com/en-us/library/ff469838.aspx

    Another way is that we could run automated test remotely by command line like the vstest.console.exe.

    But I suggest you'd better ensure the automated test run remotely successfully from the VS IDE before you run it using vstest.console.exe in command line.

    So please try to run your tests remotely from the VS IDE and then check it.

    If you could run the test successfully remotely from the VS IDE, I suggest you could try to execute the test using vstest.console.exe in command line without the PS script.

    The executing command like:vstest.console.exe  myTestFile.dll /Settings:Local.RunSettings

    For more information:

    https://msdn.microsoft.com/en-us/library/jj155796.aspx?f=255&MSPPError=-2147217396

    After you ensure you could run the test remotely successfully using vstest.console.exe in command line and then try to write your PS script to run test again check it.

    Best Regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Monday, June 29, 2015 6:23 AM
    Moderator
  • Hi Tina,

    Thanks for your reply. I am sorry that your answer is too generic for my question. Also note that vstest.console would run remotely WITHOUT platform set to be x64. It just doesn't work in a 64 platform which requires an isolation mode essentially. So I can basically say your provided suggestion like running with VS IDE and without ps script would work probably. But I can't see no clues which could solve my problem. I have to use PS scripts to suit my project's requirement instead of the other means you mention. Any further ideas?

    Jingfei


    Keep involved!

    Monday, June 29, 2015 1:14 PM
  • Hi Jingfei,

    Sorry for my misunderstanding your issue.

    As you said that the vstest.console would run remotely WITHOUT platform set to be x64. It just doesn't work in a 64 platform which requires an isolation mode essentially.

    As far as I know that when we installed the VS, it is default that the vstest.console.exe is saved into the location path: "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE".

    So I think that the vstest.console.exe is a 32 bit process, so the test assembly needs to be able to load into a 32 bit process (in other words it must target the x86 or “Any CPU” architecture) to load properly. 

    This means that when you specifically target the x64 platform and you are using one of these test types, it does not work for it.

    Therefore, I suggest you could try to sue this x86 to check this issue again.

    Best Regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Tuesday, June 30, 2015 9:49 AM
    Moderator
  • Hi Tina,

    I am so sorry that your thinking of vstest.console.exe is a 32 bit process is basically right, but the fact is not as simple as we thought. Remember that in my original thread, when we use x64 platform to run the test assembly, it would propagate a new process named vstest.discoveryengine which per my guess is actually doing the job, i.e. running the test. And vstest.discoveryengine has both x32 an x64.  And, for sort of reason, when running remotely with x64, vstest.discoveryengine can't make a communication with the PS remote session or some what. I don't know if I have a missing setting or something else. I need your help on this.  And I have to run it in x64, it's also a hard requirement

    Thanks,

    Jingfei


    Keep involved!

    Tuesday, June 30, 2015 12:46 PM
  • Hi Jingfei,

    I am trying to involve someone familiar with this topic to further look at this issue. There might be some time delay. Appreciate your patience.

    Best Regards,


    We are trying to better understand customer views on social support experience, so your participation in this interview project would be greatly appreciated if you have time. Thanks for helping make community forums a great place.
    Click HERE to participate the survey.

    Wednesday, July 1, 2015 10:05 AM
    Moderator
  • Hi,

    Unfortunately this is going to require more debugging. If you cannot determine your answer here or on your own, consider opening a support case with us. Visit this link to see the various support options that are available to better meet your needs:  http://support.microsoft.com/default.aspx?id=fh;en-us;offerprophone 

    Friday, August 21, 2015 3:28 AM
  • Hi,

    With your link, I can't find a way to open a support case. Could you provide a more detailed guideline? Thanks a lot.


    Keep involved!

    Saturday, August 22, 2015 1:57 AM
  • Hi Jingfei,

    Have you found a solution for tihs issue? I have tried everything I can think of and I still get the same error.

    Monday, May 23, 2016 7:40 AM
  • I have managed to solve this. Test Project was built with Visual Studio 2015 update 2 and I was using Agents for Visual Studio 2015 on the remote server. Microsoft released Agents for Visual Studio 2015 Update 2 but it is missing from the msdn documentations. The new release is also missing from the msdn downloads. You can download it only from the https://www.visualstudio.com -> Downloads -> All Downaloads ->Tools for Visual Studio 2015 -> Agents for Visual Studio 2015 Update 2

    https://go.microsoft.com/fwlink/?LinkId=615472&clcid=0x409

    • Proposed as answer by ivip Friday, June 3, 2016 8:55 AM
    Monday, May 23, 2016 12:41 PM
  • I was experiencing this very issue when attempting to run vstest.console.exe on an x64 machine remotely from a build box using C# PowershellAdapter class.  The issue turned out to be that some dependent process, probably vstest.discovery.engine, runs in x86.  Changing the runsettings on the target machine to x86 allowed the tests to be run on that remote machine.
    Thursday, July 6, 2017 8:40 PM
  • Hi Jingfei,

    Were you able to solve this issue ? I am seeing the same issue and have been unable to find a solution so far. 

    Thursday, December 5, 2019 6:34 PM