无法初始化客户端代理:无法连接到vstest.discoveryengine.x86.exe

Question

之前,我能够在Visual Studio 2013下运行特定项目的单元测试.这最近停止了工作,没有对项目进行重大改变,不幸的是,我不记得它什么时候做了最后一次工作,也没有改变.但是,对项目本身的任何修改都是最小的(一个或两个新方法),并且不涉及任何配置文件更改或类似的频繁报告的问题.我相信Visual Studio(可能是最近的更新)或插件或第三方软件的更改导致了以下问题.

加载项目时,一分钟后,"输出"窗口中的"测试"输出显示:

------发现测试开始------
无法初始化客户端代理:无法连接到测试进程vstest.discoveryengine.x86.exe.
==========发现测试结束:0找到(0:00:59.8853102)==========

类似于以前报告的问题,只是调试停止工作,以管理员身份运行Visual Studio似乎"解决"了这个问题.然而,这只是表明问题可能与访问权限有关.

我发现了一个相关的Microsoft Connect错误报告,该报告还暗示了由第三方应用程序引起的问题.显然vstest.discoveryengine.x86.exe使用命名管道进行通信devenv.exe.另一个应用程序可能会使用该请求,从而导致Visual Studio连接失败.但是,验证哪些命名管道正在使用中,我没有找到任何立即明显的罪魁祸首.我还想象连接可能由于其他原因而失败.

启用日志记录后 devenv.exe,vstest.executionengine.exe和vstest.discoveryengine.exe我发现与在devenv的日志中发现引擎但下列情况除外:

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)
   ...

......以及稍后的类似例外 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)

执行引擎似乎正确启动并等待传入​​的请求.最后一项是:TestExecutorService: Created/Started the listening channel. ChannelUri=net.pipe://steven-flip/TestExecutor/4912.

同样适用于最后一行的发现引擎: I, 8232, 1, 2014/12/22, 01:46:13.942, 63486587413, vstest.discoveryengine.exe, ServiceMain: Started the service host 8232

有没有人遇到类似的问题？如何最好地解决这个问题？我不认为不断运行Visual Studio作为管理员才能成为合适的解决方案.

Answer 1

我在Windows 10上使用Visual Studio 2015遇到了同样的问题.经过大量的调试后,结果发现问题出现在另一个程序中:

单独的vstest可执行文件使用WCF通过命名管道(net.pipe协议,例如端点URL net.pipe://machinename/vstest.discoveryengine/12345)与主引擎(在Visual Studio或VSTest控制台中运行)进行通信.事实证明,每当在特权帐户下运行的应用程序侦听net.pipe URL(另一个URL的前缀)时,没有其他非特权帐户可以侦听更长的URL(只有在以管理员身份运行时才可以).

事实证明,有各种各样的应用程序以管理员或本地系统的方式运行net.pipe://localhost/.在这种情况下,在非特权用户下运行的WCF应用程序(包括VSTest进程)根本不能在命名管道上运行服务器.您可以尝试创建在netpipes上运行的最小WCF示例.即使是那个简单的例子只有在以管理员身份运行时才能在我的机器上工作(否则,"net.pipe:// ..."中没有端点监听).

我使用Sysinternals Process Explorer,Ctrl + F并搜索"net.pipe"来查找netpipes打开的​​进程.就我而言,Razer的"RzWizardService"将一个端点直接保存在WCF服务器上,该端点位于作为本地系统服务运行的"net.pipe:// localhost /"下.当我停止服务时,一切都开始正常.

Answer 2

我最近遇到了同样的问题。就像你说的，这可能是来自另一个第三方库的一些干扰。就我而言，我尝试卸载 VS-plugin Emmet。这对我有用。重新启动后，重新发现测试。