Question Échec d'initialisation du proxy client: impossible de se connecter à vstest.discoveryengine.x86.exe


Avant, je pouvais exécuter les tests unitaires d'un projet particulier sous Visual Studio 2013. Cela a récemment cessé de fonctionner sans changements majeurs au projet, et malheureusement je ne me souviens pas quand il a fait son dernier travail, ni ce qui a changé depuis. Cependant, les modifications apportées au projet lui-même étaient minimes (une ou deux nouvelles méthodes) et n’impliquaient pas toute modification du fichier de configuration ou tout problème similaire fréquemment signalé. Je crois plutôt qu'un changement dans Visual Studio (peut-être une mise à jour récente), ou des plug-ins ou des logiciels tiers est à l'origine du problème suivant.

Lors du chargement du projet, après une minute, la sortie "Tests" dans la fenêtre de sortie affiche:

------ Découvrir le test a commencé ------
  Échec d'initialisation du proxy client: impossible de se connecter au processus de test vstest.discoveryengine.x86.exe.
  ========== Découvrez le test terminé: 0 trouvé (0: 00: 59.8853102) ==========

Similaire à un problème précédemment signalé où le débogage ne fonctionnait plusVisual Studio en tant qu'administrateur semble résoudre le problème. Cependant, ceci est simplement une indication que le problème pourrait avoir quelque chose à voir avec les droits d'accès.

j'ai trouvé un rapport de bogue sur Microsoft Connect, qui indique également le problème causé par une application tierce. Apparemment vstest.discoveryengine.x86.exe utilise des canaux nommés pour communiquer avec devenv.exe. Une autre application peut consommer la demande, ce qui entraîne une connexion défaillante pour Visual Studio. cependant, vérifier quels tubes nommés étaient utilisés, Je n'ai pas trouvé de coupables immédiatement évidents. J'imagine également que la connexion pourrait échouer pour d'autres raisons.

Après avoir activé la journalisation pour  devenv.exe, vstest.executionengine.exe et vstest.discoveryengine.exe J'ai trouvé les exceptions suivantes liées au moteur de découverte dans le journal 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)
   ...

... et plus tard, une exception similaire pour 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)

Le moteur d'exécution semble démarrer correctement et attend les demandes entrantes. La dernière entrée est: TestExecutorService: Created/Started the listening channel. ChannelUri=net.pipe://steven-flip/TestExecutor/4912.

Il en va de même pour le moteur de découverte dont la dernière ligne est: I, 8232, 1, 2014/12/22, 01:46:13.942, 63486587413, vstest.discoveryengine.exe, ServiceMain: Started the service host 8232

Quelqu'un at-il rencontré des problèmes similaires? Comment mieux y faire face? Je ne trouve pas que Visual Studio en tant qu'administrateur soit constamment une solution adaptée.


22
2017-12-21 23:18


origine


Réponses:


J'ai eu le même problème en utilisant Visual Studio 2015 sur Windows 10. Après avoir fait beaucoup de débogage, il s'est avéré que le problème était dans un autre programme:

Les exécutables vstest distincts communiquent avec le moteur principal (exécuté dans Visual Studio ou dans la console VSTest) en utilisant WCF sur des canaux nommés (le net.pipe protocole, avec une URL de point de terminaison, par ex. net.pipe://machinename/vstest.discoveryengine/12345). Comme il s'avère, chaque fois qu'une application exécutée sous un compte privilégié écoute sur une URL net.pipe qui est un préfixe d'une autre URL, aucun autre compte non privilégié ne peut écouter sur une URL plus longue (uniquement en tant qu'administrateur qu'il peut exécuter).

Et, en fin de compte, il existe diverses applications qui fonctionnent en tant qu’administrateur ou système local écoutent net.pipe://localhost/. Dans ce cas, aucune application WCF, y compris les processus VSTest, exécutée sous un utilisateur non privilégié ne peut exécuter un serveur sur des canaux nommés. Vous pouvez essayez de créer un exemple WCF minimal en cours d'exécution sur netpipes. Même cet exemple trivial ne fonctionnait sur ma machine que lorsqu’il était exécuté en tant qu’administrateur (sinon, il n’y avait pas d’écouteur à l’écoute sur net.pipe: // ...).

J'ai utilisé Sysinternals Process Explorer, Ctrl + F et recherché "net.pipe" pour trouver des processus avec netpipes ouverts. Dans mon cas, c'était le "RzWizardService" de Razer qui gardait un serveur WCF avec un noeud final directement sous "net.pipe: // localhost /" fonctionnant comme un service système local. Lorsque j'ai arrêté le service, tout a bien fonctionné.


11
2018-02-15 21:45



J'étais confronté au même problème sous VS 2015 et VS 2017. Après avoir vérifié quelques méthodes (désactiver WAS, réinstaller VS 2015, lancer l'outil SubInACL, lancer VS 2015 en mode sans échec, ..), j'ai constaté que:

  • En cours d'exécution de VS 2015 en tant qu'administrateur, résoudre le problème et mon explorateur de test affiche à nouveau les tests! Bien que, je pense que c'est juste une solution de contournement et non une solution finale.
  • Ainsi, après quelques recherches sur Google, j'ai trouvé une autre solution qui consiste à ajouter une permission d'écriture / modification pour l'utilisateur actuel au dossier "% ProgramData% \ Package Cache". Voir plus de détails dans ce lien. Maintenant, lors du lancement de VS 2015 sous mon compte d'utilisateur, Test Explorer découvre rapidement tous mes tests et le message d'erreur a disparu.

3
2018-03-14 23:23



J'ai récemment eu le même problème. Comme vous l'avez dit, cela pourrait être une interférence d'une autre bibliothèque du 3ème parti. Dans mon cas, j'ai essayé de désinstaller le plugin VS Emmet. Celui-ci a fonctionné pour moi. Après le redémarrage, les tests ont été redécouverts.


0
2018-05-06 06:46



Assurez-vous que votre paramètre Windows est défini pour le développeur - un package pour développeur sera automatiquement installé lors de la modification de ce paramètre, puis UWP C # unittest s'exécutera, sinon il générera une erreur similaire à celle décrite


0
2018-05-18 13:58