Échec d'initialisation du proxy client: impossible de se connecter à vstest.discoveryengine.x86.exe
Auparavant, je pouvais très bien exécuter les tests unitaires d'un projet particulier sous Visual Studio 2013. Cela a récemment cessé de fonctionner sans modifications majeures du projet, et malheureusement, je ne me souviens pas de la date du dernier travail ni de 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 aucune modification du fichier de configuration ni aucun problème similaire fréquemment signalé . Je pense plutôt qu'un changement de Visual Studio (peut-être une mise à jour récente), de plug-ins ou de logiciels tiers est à l'origine du problème suivant.
Lors du chargement du projet, au bout d’une minute, la sortie "Tests" de la fenêtre de sortie affiche:
------ Le test de découverte 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és (0: 00: 59.8853102) ===========
Semblable à un problème précédemment signalé où le débogage ne fonctionnait plus , l'exécution de Visual 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 Microsoft Connect lié , qui évoque é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 pourrait utiliser la demande, entraînant ainsi l'échec de la connexion de Visual Studio. Cependant, vérifiant quels tuyaux nommés étaient utilisés , je n’ai trouvé aucun coupable immédiatement évident. J'imagine aussi que la connexion pourrait échouer pour d'autres raisons.
Après avoir activé la journalisation pourdevenv.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 bien démarrer 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 faire face à cela? Je ne trouve pas que l'exécution en continu de Visual Studio en tant qu'administrateur soit une solution appropriée.
J'ai eu le même problème lors de l'utilisation de Visual Studio 2015 sous Windows 10. Après de nombreuses opérations de débogage, le problème se trouvait dans un autre programme:
Les exécutables vstest distincts communiquent avec le moteur principal (s'exécutant dans Visual Studio ou dans la console VSTest) à l'aide de WCF sur des canaux nommés (protocole net.pipe, avec une URL de noeud final, par exemple net.pipe://machinename/vstest.discoveryengine/12345). En fin de compte, lorsqu'une application exécutée sous un compte privilégié écoute une URL net.pipe qui est le préfixe d'une autre URL, aucun autre compte non privilégié ne peut écouter sur l'URL la plus longue (uniquement lorsqu'il est exécuté en tant qu'administrateur).
Et, comme il se trouve, il existe diverses applications qui fonctionnent en tant qu'administrateur ou système local à écouter sur net.pipe://localhost/. Dans ce cas, aucune application WCF, y compris les processus VSTest, exécutée sous un utilisateur sans privilège ne peut exécuter un serveur sur des canaux nommés. Vous pouvez essayez de créer un exemple de WCF minimal sur les netpipes . Même cet exemple trivial ne fonctionnait sur ma machine que lorsqu'il était exécuté en tant qu'administrateur (sinon, «aucun point d'extrémité n'écoutait sur net.pipe: //…» qui s'ensuivit).
J'ai utilisé Sysinternals Process Explorer, Ctrl + F et cherché «net.pipe» pour trouver des processus avec des netpipes ouverts. Dans mon cas, c’était «RzWizardService» de Razer qui gardait un serveur WCF avec un noeud final directement sous «net.pipe: // localhost /» s’exécutant en tant que service système local. Quand j'ai arrêté le service, tout a commencé à bien fonctionner.
Je rencontrais le même problème sous VS 2015 et VS 2017. Après avoir vérifié plusieurs méthodes (désactivation de WAS, réinstaller VS 2015, lancement de l'outil SubInACL, lancement de VS 2015 en mode sans échec, ..), j'ai constaté que:
- L'exécution de VS 2015 en tant qu'administrateur résout le problème et mon test Explorer affiche à nouveau les tests! Bien que, je pense que ceci est juste une solution de contournement et pas une solution finale.
- Ainsi, après quelques recherches sur Google, j'ai trouvé une autre solution consistant à ajouter une autorisation d'écriture/modification pour l'utilisateur actuel au dossier "% ProgramData%\Package Cache". Voir plus de détails dans ce link . Maintenant, lors du lancement de VS 2015 sous mon compte utilisateur, Test Explorer découvre rapidement tous mes tests et le message d'erreur disparaît.
Si cette erreur se produit lors d'une session de codage où elle fonctionnait auparavant sans fermer Visual Studio ou votre SLN, voyez si vous pouvez supprimer le projet de test du SLN puis le rajouter à nouveau.
Si vous ne pouvez pas (ou du moins pas sans solution de contournement), envisagez de supprimer votre fichier SLN et de le refaire. C'est comme ça que j'ai été débloqué. Rien d’autre n’a fonctionné, mais TBH j’étais trop paresseux pour rechercher net.pipe, car j’ai considéré qu’il s’agissait d’un problème d’automatisation insoluble et n’avais aucun intérêt à poursuivre sur cette voie.
J'ai récemment eu le même problème. Comme vous l'avez dit, cela pourrait être une ingérence d'une autre bibliothèque du 3ème parti. Dans mon cas, j’ai essayé de désinstaller le plug-in VS Emmet . Celui-ci a fonctionné pour moi. Après le redémarrage, les tests ont été redécouverts.
Mon problème était que j'ai créé un nouvel utilisateur sur ma machine et que l'application de test UWP était toujours installée sur l'autre utilisateur. Ce n'est pas autorisé (y Tho) et j'ai dû le désinstaller.
Pour savoir si l'application est installée, exécutez PowerShell en tant qu'administrateur et exécutez la commande suivante:
Get-AppPackage *YourTestAppNameHere* -AllUsers
S'il y a un résultat, cela signifie que l'application est installée. Vous pouvez ensuite le désinstaller avec cette commande:
Get-AppPackage *YourTestAppNameHere* -AllUsers | Remove-AppPackage -AllUsers
Exécutez à nouveau la première commande pour vérifier qu'elle a été désinstallée correctement.
Assurez-vous que votre paramètre Windows est défini pour 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 le résultat sera identique à celui décrit