visual studio - unit - Error al inicializar el proxy del cliente: no se pudo conectar a vstest.discoveryengine.x86.exe

unit test visual studio

Question

Antes, pude ejecutar las pruebas de unidad de un proyecto en particular bajo Visual Studio 2013 muy bien. Esto ha dejado de funcionar recientemente sin cambios importantes en el proyecto , y desafortunadamente no recuerdo cuándo funcionó por última vez, ni qué ha cambiado desde entonces. Sin embargo, las modificaciones al proyecto en sí fueron mínimas (uno o dos métodos nuevos) y no implicaron cambios en el archivo de configuración ni problemas similares notificados con frecuencia . Creo más bien que un cambio en Visual Studio (quizás una actualización reciente), o complementos o software de terceros está causando el siguiente problema.

Mientras se carga el proyecto, después de un minuto, el resultado de "Pruebas" en la ventana de resultados muestra:

------ Descubrió la prueba comenzó ------
Error al inicializar el proxy del cliente: no se pudo conectar al proceso de prueba vstest.discoveryengine.x86.exe.
========== Descubrimiento de la prueba finalizada: 0 encontrados (0: 00: 59.8853102) ==========

Similar a un problema reportado anteriormente donde la depuración simplemente dejó de funcionar , ejecutar Visual Studio como administrador parece "resolver" el problema. Sin embargo, esto es simplemente una indicación de que el problema podría tener algo que ver con los derechos de acceso.

Encontré un informe de error de Microsoft Connect relacionado , que también sugiere el problema causado por una aplicación de terceros. Al parecer, vstest.discoveryengine.x86.exe utiliza canalizaciones con nombre para comunicarse con devenv.exe . Otra aplicación podría consumir la solicitud, lo que resultaría en una conexión fallida para Visual Studio. Sin embargo, al verificar qué tuberías nombradas estaban en uso , no encontré ningún culpable obvio de inmediato. También me imagino que la conexión podría fallar por otras razones.

Después de habilitar el registro de devenv.exe , vstest.executionengine.exe y vstest.discoveryengine.exe , encontré las siguientes excepciones relacionadas con el motor de descubrimiento en el registro de 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)
   ...

... y más adelante, una excepción similar para 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)

El motor de ejecución parece arrancar correctamente y espera las solicitudes entrantes. La última entrada es: TestExecutorService: Created/Started the listening channel. ChannelUri=net.pipe://steven-flip/TestExecutor/4912 TestExecutorService: Created/Started the listening channel. ChannelUri=net.pipe://steven-flip/TestExecutor/4912 .

Lo mismo ocurre con el motor de descubrimiento cuya última línea es: I, 8232, 1, 2014/12/22, 01:46:13.942, 63486587413, vstest.discoveryengine.exe, ServiceMain: Started the service host 8232

¿Alguien encontró problemas similares? ¿Cómo abordar mejor esto? No encuentro constantemente que Visual Studio como administrador sea una solución adecuada.

Answer 1

Asegúrese de que su configuración de Windows esté configurada para el desarrollador: se instalará automáticamente un paquete para el desarrollador al cambiar a esta configuración y luego se ejecutará el UWP C # unittest, de lo contrario, dará un error similar al que describió

Answer 2

Me encontré con el mismo problema en VS 2015 y VS 2017. Después de revisar un par de métodos (deshabilitando WAS, Reinstalar VS 2015, iniciando la herramienta SubInACL, iniciando VS 2015 en modo seguro, ...), encontré que:

• ¡Ejecutar VS 2015 como Admnistrator resuelve el problema y mi explorador de pruebas muestra las pruebas nuevamente! Aunque, creo que esto es solo una solución y no una solución final.
• Entonces, después de algunas búsquedas en Google, encontré otra solución que consiste en agregar permisos de escritura / modificación para el usuario actual a la carpeta "% ProgramData% / Package Cache". Ver más detalles en este link . Ahora, al iniciar VS 2015 con mi cuenta de usuario, Test Explorer está descubriendo todas mis pruebas rápidamente y el mensaje de error desapareció.

Answer 3

Recientemente tengo el mismo problema. Como dijiste, podría ser una interferencia de otra biblioteca de terceros. En mi caso, he intentado desinstalar el plugin de VS Emmet . Este funcionó para mí. Después de reiniciar, las pruebas se redescubrieron.

Answer 4

Tuve el mismo problema al usar Visual Studio 2015 en Windows 10. Después de hacer una gran cantidad de depuración, resultó que el problema estaba en otro programa:

Los ejecutables vstest independientes se comunican con el motor principal (que se ejecuta en Visual Studio o en la consola VSTest) mediante WCF a través de canalizaciones con nombre (el protocolo net.pipe , con una URL de punto final, por ejemplo, net.pipe://machinename/vstest.discoveryengine/12345 ). Resulta que, cuando una aplicación que se ejecuta bajo una cuenta privilegiada escucha en una URL net.pipe que es un prefijo de otra URL, ninguna otra cuenta sin privilegios puede escuchar en la URL más larga (solo cuando se ejecuta como administrador).

Y, como resultado, hay varias aplicaciones que se ejecutan mientras el administrador o el sistema local escuchan en net.pipe://localhost/ . En ese caso, ninguna aplicación WCF, incluidos los procesos VSTest, que se ejecutan bajo un usuario sin privilegios puede ejecutar un servidor en canalizaciones con nombre. Puede intentar crear un ejemplo de WCF mínimo ejecutándose en netpipes . Incluso ese ejemplo trivial funcionó en mi máquina solo cuando se ejecuta como administrador (de lo contrario, "No hubo ningún punto final escuchando en net.pipe: // ..." como consecuencia).

Utilicé Sysinternals Process Explorer, Ctrl + F y busqué en "net.pipe" para encontrar procesos con netpipes abiertos. En mi caso, fue el "RzWizardService" de Razer que mantiene un servidor WCF con un punto final directamente debajo de "net.pipe: // localhost /" que se ejecuta como un servicio de sistema local. Cuando detuve el servicio, todo empezó a funcionar bien.