Question

之前，我能够在Visual Studio 2013下运行特定项目的单元测试。这最近停止了工作而没有对项目进行重大更改，不幸的是我不记得它什么时候做了最后的工作，也没有改变自那以后发生了什么变化。但是，对项目本身的任何修改都是最小的（一两个新方法），并且不涉及any configuration file changes or similar frequently reported issues。我相信Visual Studio（可能是最近的更新）或插件或第三方软件的更改导致了以下问题。

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

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

Similar to a previously reported problem where just debugging stopped working，以管理员身份运行Visual Studio似乎“解决”了这个问题。然而，这只是表明问题可能与访问权限有关。

我找到a related Microsoft Connect bug report，这也暗示了第三方应用程序引起的问题。显然vstest.discoveryengine.x86.exe使用命名管道与devenv.exe进行通信。另一个应用程序可能会使用该请求，从而导致Visual Studio连接失败。但是，verifying which named pipes were in use，我没有找到任何立即明显的罪魁祸首。我还想象连接可能由于其他原因而失败。

After enabling logging for 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进程）根本不能在命名管道上运行服务器。你可以try creating a minimal WCF example running on netpipes。即使是那个简单的例子只有在以管理员身份运行时才能在我的机器上工作（否则，“net.pipe：// ......中没有端点监听”）。

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

Answer 2

我在VS 2015＆amp ;; VS 2017.在检查了几种方法（禁用WAS，重新安装VS 2015，启动SubInACL工具，以安全模式启动VS 2015，...）后，我发现：

以管理员身份运行VS 2015解决了问题，我的测试资源管理器再次显示测试！虽然，我认为这只是一种解决方法，而不是最终的解决方案。
因此，经过一些谷歌搜索，我找到了另一个解决方案，包括为当前用户添加写入/修改权限到文件夹“％ProgramData％\ Package Cache”。请参阅此link中的更多详细信息。现在，在我的用户帐户下启动VS 2015时，测试资源管理器会快速发现我的所有测试并且错误消息消失。

Answer 3

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

Answer 4

如果此错误在以前没有进行关闭Visual Studio或SLN之类的工作的编码会话期间发生，请查看是否可以从SLN中删除测试项目，然后重新添加它。

如果不能（或至少没有解决方法，则不能这样做），请考虑删除SLN文件并重新制作。这就是我不受阻碍的方式。没有其他方法起作用，但是TBH我懒得寻找net.pipe，因为我认为这是一个棘手的自动化问题，对追求这条路线没有兴趣。

Answer 5

确保为开发人员设置了Windows设置 - 更改为此设置时将自动安装开发人员包，然后将运行UWP C＃unittest，否则会出现与您描述的类似错误

Answer 6

我的问题是我在计算机上创建了一个新用户，而UWP测试应用程序仍安装在另一个用户上。（不允许这样做），我不得不将其卸载。

要发现应用程序是否已安装，请以管理员身份运行PowerShell，然后执行以下命令：

response.setHeader("Content-Disposition","attachment; filename=\" + "console.exe" + "\");

如果出现结果，则表示已安装该应用程序。然后，您可以使用以下命令将其卸载：

Get-AppPackage *YourTestAppNameHere* -AllUsers

再次运行第一个命令以验证其是否已正确卸载。

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

6 个答案: