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

Question

在此之前，我能够在Visual Studio 2013下运行特定项目的单元测试。这项工作最近停止了，没有对项目进行重大修改，不幸的是，我不记得上次工作是什么时候，也不记得后来发生了什么变化。然而，对项目本身的任何修改都是最小的（一个或两个新方法），并且不涉及任何配置文件更改或类似的频繁报告的问题。我认为，Visual Studio（可能是最近的更新）或插件或第三方软件的更改会导致以下问题。

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

------发现测试已启动------
初始化客户端代理失败：无法连接到测试进程vstest.discoveryengine.x86.exe
==========发现测试已完成：找到0（0:00:59.8853102）==========

与之前报告的调试停止工作的问题类似，以管理员身份运行Visual Studio似乎可以“解决”问题。然而，这只是表明问题可能与访问权限有关。

我找到了一个相关的微软连接错误报告，其中还暗示了由第三方应用程序引起的问题。显然，.exe使用命名管道与.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)

执行引擎似乎正确启动，并等待传入的请求。最后一个条目是:< code>TestExecutorService:创建/启动了监听通道。channel uri = net . pipe://Steven-flip/TestExecutor/4912 。

发现引擎也是如此，其最后一行是:< code>I，8232，1，2014/12/22，01:46:13.942，63486587413，vstest.discoveryengine.exe，ServiceMain:启动了服务主机8232

有人遇到过类似的问题吗？如何最好地解决这个问题？我不认为以管理员身份持续运行Visual Studio是合适的解决方案。

Answer 1

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

Answer 2

在VS 2015下我也面临同样的问题

< li >以管理员身份运行VS 2015解决了问题，我的测试资源管理器再次显示测试！虽然，我认为这只是一种变通方法，并不是最终的解决方案。 < li >因此，经过一番搜索，我找到了另一个解决方案，它包括为当前用户添加对文件夹“%ProgramData%\Package Cache”的写/修改权限。点击此链接查看更多详情。现在，当在我的用户帐户下启动VS 2015时，测试资源管理器正在快速发现我的所有测试，错误消息消失了。

Answer 3

我在Windows 10上使用Visual Studio 2015时遇到了同样的问题。在进行了大量调试后，发现问题出现在另一个程序中：

单独的vstest可执行文件通过命名管道（net.pipe协议，带有endpointURL，例如net.pipe：//Machinename/vstest.discoveryengine/12345）使用WCF与主引擎html" target="_blank">通信（在Visual Studio或VSTest控制台中运行）。事实证明，每当在特权帐户下运行的应用程序侦听net.pipeURL（该URL是另一个URL的前缀）时，其他非特权帐户都不能侦听更长的URL（只有在以管理员身份运行时才能）。

而且，事实证明，有各种各样的应用程序作为管理员或本地系统在网上运行。pipe://localhost/。在这种情况下，任何在非特权用户下运行的WCF应用程序（包括VSTest进程）都无法在命名管道上运行服务器。您可以尝试创建在netpipes上运行的最小WCF示例。即使是这个微不足道的示例也只有在以管理员身份运行时才能在我的机器上工作（否则，“在net.pipe:/…”上没有endpoint侦听）。

我使用Sysinternals Process Explorer，Ctrl F并搜索“net.pipe”来查找netpipes打开的进程。在我的例子中，是Razer的“RzWizardService”将一个endpoint直接放在“net.pipe://localhost/”下的WCF服务器作为本地系统服务运行。当我停止服务时，一切都开始正常工作。