29

Before, I was able to run the unit tests of a particular project under Visual Studio 2013 just fine. This has recently stopped working without major changes to the project, and unfortunately I do not recall when it did last work, nor what changed since. However, any modifications to the project itself were minimal (one or two new methods), and did not involve any configuration file changes or similar frequently reported issues. I believe rather that a change in Visual Studio (perhaps a recent update), or plug-ins or third party software is causing the following issue.

While loading the project, after one minute the "Tests" output in the Output Window shows:

------ Discover test started ------
Failed to initialize client proxy: could not connect to test process vstest.discoveryengine.x86.exe.
========== Discover test finished: 0 found (0:00:59.8853102) ==========

Similar to a previously reported problem where just debugging stopped working, running Visual Studio as administrator seems to 'resolve' the issue. However this is simply an indication the problem might have got something to do with access rights.

I found a related Microsoft Connect bug report, which also hints at the problem being caused by a third party application. Apparently vstest.discoveryengine.x86.exe uses named pipes to communicate with devenv.exe. Another application could consume the request, thus resulting in a failed connection for Visual Studio. However, verifying which named pipes were in use, I did not find any immediately obvious culprits. I also imagine the connection might fail for other reasons.

After enabling logging for devenv.exe, vstest.executionengine.exe and vstest.discoveryengine.exe I found the following exceptions related to the discovery engine in the devenv log:

E, 10048, 42, 2014/12/22, 01:47:13.683, 63637924754, devenv.exe, TestRunnerServiceClient: Could not connect to test runner service within the available time 60000. Reason:System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at net.pipe://steven-flip/vstest.discoveryengine/8232 that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

Server stack trace: 
   at System.ServiceModel.Channels.ConnectionUpgradeHelper.DecodeFramingFault(ClientFramingDecoder decoder, IConnection connection, Uri via, String contentType, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.SendPreamble(IConnection connection, ArraySegment`1 preamble, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.DuplexConnectionPoolHelper.AcceptPooledConnection(IConnection connection, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout)
   ...

... and later on, a similar exception for vstest.executionengine.exe

E, 10048, 40, 2014/12/22, 01:47:15.600, 63642778910, devenv.exe, TestRunnerServiceClient: Could not connect to test runner service within the available time 60000. Reason:System.ServiceModel.EndpointNotFoundException: There was no endpoint listening at net.pipe://steven-flip/vstest.discoveryengine/9884 that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.

Server stack trace: 
   at System.ServiceModel.Channels.ConnectionUpgradeHelper.DecodeFramingFault(ClientFramingDecoder decoder, IConnection connection, Uri via, String contentType, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.SendPreamble(IConnection connection, ArraySegment`1 preamble, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.DuplexConnectionPoolHelper.AcceptPooledConnection(IConnection connection, TimeoutHelper& timeoutHelper)
   at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout)

The execution engine seems to start correctly and waits for incoming requests. The last entry is: TestExecutorService: Created/Started the listening channel. ChannelUri=net.pipe://steven-flip/TestExecutor/4912.

Same goes for the discovery engine of which the last line is: I, 8232, 1, 2014/12/22, 01:46:13.942, 63486587413, vstest.discoveryengine.exe, ServiceMain: Started the service host 8232

Did anyone encounter similar problems? How to best tackle this? I do not find constantly running Visual Studio as administrator to be a suitable solution.

Community
  • 1
  • 1
Steven Jeuris
  • 18,274
  • 9
  • 70
  • 161
  • Were you able to find a suitable solution for this? I am hitting the same issue. (In my case I am using the command line tool vstest.console.exe and I am already running this as an administrator) – Turbo Oct 01 '15 at 01:21
  • @Turbo Nope, haven't tried yet on new setup however (Windows 10, new VS). – Steven Jeuris Oct 01 '15 at 09:08
  • 3
    @Turbo, did you ever solve this? I'm blocked at this point. – Ben Power Apr 21 '16 at 02:32
  • 1
    I ran into this issue out of the blue when my vstest project was already working. I removed the test project and went to re-add it, but the SLN file wouldn't let me, so I deleted and re-made the SLN file, re-added the projects, and all was well again. Strange... – kayleeFrye_onDeck Feb 06 '19 at 00:17
  • 1
    This still happens in Visual Studio 2017 randomly without any hints on why it happens. – Christian Findlay Feb 13 '19 at 01:21

6 Answers6

15

I had the same problem using Visual Studio 2015 on Windows 10. After doing a lot of debugging, it turned out the problem was in another program:

The separate vstest executables communicate with the main engine (running in Visual Studio or in the VSTest Console) using WCF over named pipes (the net.pipe protocol, with an endpoint URL e.g. net.pipe://machinename/vstest.discoveryengine/12345). As it turns out, whenever an application running under a privileged account listens on a net.pipe URL which is a prefix of another URL, no other unprivileged account can listen on the longer URL (only when running as administrator they can).

And, as it turns out, there are various applications out there which run as administrator or local system listen on net.pipe://localhost/. In that case, no WCF application, including the VSTest processes, running under an unprivileged user can run a server on named pipes at all. You can try creating a minimal WCF example running on netpipes. Even that trivial example worked on my machine only when run as administrator (otherwise, “There was no endpoint listening at net.pipe://…” ensued).

I used Sysinternals Process Explorer, Ctrl+F and searched “net.pipe” to find processes with netpipes open. In my case, it was Razer’s “RzWizardService” keeping a WCF server with an endpoint directly under “net.pipe://localhost/” running as a local system service. When I stopped the service, everything started to work fine.

Community
  • 1
  • 1
Mormegil
  • 7,955
  • 4
  • 42
  • 77
  • 1
    Worked for me. Had to close most applications that used named pipes, then it took some time, but VS was able to start debugging and it stopped at the break point I placed in the code. – Ionut V. Mar 27 '17 at 09:13
  • In my case it was iStat Server which caused the problem. Had to run Process Explorer as Administrator to see it. Thanks for the solution. – jamting Sep 21 '17 at 17:09
3

I was facing the same problem under VS 2015 & VS 2017. After checking a couple of methods (disabling WAS, Reinstall VS 2015, launching SubInACL tool, launching VS 2015 in safe mode, ..), I found that:

  • Running VS 2015 as Admnistrator resolve the issue and my test explorer show the tests again! Although, I think this is just a workaround and not a final solution.
  • So, after some googling, I found another solution that consists of adding write/modify permission for current user to the folder "%ProgramData%\Package Cache". See more detail in this link. Now, when launching VS 2015 under my user account, Test Explorer is discovering all my tests quickly and the error message disappeared.
alex_milhouse
  • 891
  • 1
  • 13
  • 31
user7711717
  • 31
  • 1
1

I recently got the same problem. Like you said, it could be some interference from another 3th party library. In my case, I tried uninstalling the VS-plugin Emmet. This one worked for me. After restarting, tests got rediscovered.

Andries
  • 1,104
  • 9
  • 12
1

If this error occurs during a coding session where it was previously working without doing something like closing Visual Studio or your SLN, see if you can remove the test project from the SLN and then re-add it.

If you can't (or at least not without workarounds) then consider deleting your SLN file and re-making it. That's how I was unblocked. Nothing else worked, but TBH I was too lazy to look for net.pipe, as I considered that an intractable automation problem and had no interest in pursuing that route.

kayleeFrye_onDeck
  • 6,648
  • 5
  • 69
  • 80
0

Make sure that your windows setting is set for developer -- a package for developer will be automatically installed when changing to this setting and then UWP C# unittest will run, otherwise it will give similar error as you described

serup
  • 3,676
  • 2
  • 30
  • 34
0

My issue was that I created a new user on my machine and the UWP test app was still installed on the other user. This is not allowed (y tho) and I had to uninstall it.

To discover if the app is installed, run PowerShell as administrator, and execute this command:

Get-AppPackage *YourTestAppNameHere* -AllUsers

If there is a result, it means it the app is installed. You can then uninstall it with this command:

Get-AppPackage *YourTestAppNameHere* -AllUsers | Remove-AppPackage -AllUsers

Run the first command again to verify it uninstalled correctly.

James Esh
  • 2,219
  • 1
  • 24
  • 41