Не удалось инициализировать клиентский прокси: не удалось подключиться к vstest.discoveryengine.x86.exe

Раньше я мог нормально запускать модульные тесты конкретного проекта в Visual Studio 2013. Недавно это перестало работать без существенных изменений в проекте, и, к сожалению, я не помню, когда он работал в последний раз, и что изменилось с тех пор. Однако любые изменения в самом проекте были минимальными (один или два новых метода) и не включали каких-либо изменений в файле конфигурации или аналогичных часто сообщаемых проблем. Скорее, я полагаю, что изменение в Visual Studio (возможно, недавнее обновление) или в подключаемых модулях или стороннем программном обеспечении вызывает следующую проблему.

При загрузке проекта через минуту вывод "Тесты" в окне вывода показывает:

------ Обнаружение теста началось ------
Не удалось инициализировать клиентский прокси: не удалось подключиться к процессу тестирования vstest.discoveryengine.x86.exe.
========== Обнаружение теста завершено: 0 найдено (0: 00: 59.8853102) ==========

Подобно ранее сообщавшейся проблеме, когда перестала работать только отладка, запуск Visual Studio от имени администратора, похоже, "решил" проблему. Однако это просто признак того, что проблема может иметь отношение к правам доступа.

Я нашел связанный отчет об ошибке Microsoft Connect, который также намекает на проблему, вызванную сторонним приложением. Очевидно, vstest.discoveryengine.x86.exe использует именованные каналы для связи с devenv.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)

Механизм выполнения, кажется, запускается правильно и ожидает входящих запросов. Последняя запись: 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.

То же самое касается механизма обнаружения, последняя строка которого: I, 8232, 1, 2014/12/22, 01:46:13.942, 63486587413, vstest.discoveryengine.exe, ServiceMain: Started the service host 8232

Кто-нибудь сталкивался с подобными проблемами? Как лучше всего заняться этим? Я не считаю постоянно работающую Visual Studio администратором подходящим решением.

Ответы

Ответ 1

У меня была такая же проблема с использованием Visual Studio 2015 в Windows 10. После многого отладки выяснилось, что проблема была в другой программе:

Отдельные исполняемые файлы vstest взаимодействуют с основным движком (работающим в Visual Studio или в VSTest Console) с использованием WCF по именованным каналам (протокол net.pipe с URL-адресом конечной точки, например net.pipe://machinename/vstest.discoveryengine/12345). Как оказалось, всякий раз, когда приложение, работающее под привилегированной учетной записью, прослушивает URL-адрес net.pipe, который является префиксом другого URL-адреса, никакая другая непривилегированная учетная запись не может прослушивать более длинный URL-адрес (только при запуске под управлением администратора).

И, как оказалось, есть различные приложения, которые запускаются как администратор или локальная система прослушивания на net.pipe://localhost/. В этом случае никакое приложение WCF, включая процессы VSTest, работающие под непривилегированным пользователем, вообще не может запускать сервер по именованным каналам. Вы можете попробовать создать минимальный пример WCF, запущенный на netpipes. Даже этот тривиальный пример работал на моей машине только при запуске как администратор (в противном случае "Не было прослушивание конечной точки в net.pipe://..." ).

Я использовал Sysinternals Process Explorer, Ctrl + F и искал "net.pipe", чтобы найти процессы с открытыми netpipes. В моем случае Razers "RzWizardService" поддерживал сервер WCF с конечной точкой непосредственно под "net.pipe://localhost/", работающим как локальная системная служба. Когда я остановил службу, все стало нормально работать.

Ответ 2

Я столкнулся с той же проблемой в VS 2015 и VS 2017. После проверки нескольких методов (отключение WAS, переустановка VS 2015, запуск инструмента SubInACL, запуск VS 2015 в безопасном режиме,..), я обнаружил, что:

• Выполнение VS 2015 как Admenistrator разрешает проблему, и мой тестовый исследователь снова показывает тесты! Хотя, я думаю, что это всего лишь обходное решение, а не окончательное решение.
• Итак, после некоторого поиска в Google я нашел другое решение, которое состоит из добавления разрешения на запись/изменение для текущего пользователя в папку "% ProgramData%\Package Cache". Подробнее см. Ссылку . Теперь, когда вы запускаете VS 2015 под учетной записью пользователя, Test Explorer быстро обнаруживает все мои тесты и сообщение об ошибке исчезает.

Ответ 3

Недавно я получил ту же проблему. Как вы сказали, это может быть некоторая помеха от другой 3-й партийной библиотеки. В моем случае я попытался удалить VS-плагин Emmet. Этот работал у меня. После перезапуска тесты заново открылись.

Ответ 4

Убедитесь, что ваш параметр Windows установлен для разработчика - пакет для разработчика будет автоматически установлен при изменении этого параметра, а затем запустится UWP С# unittest, в противном случае он выдаст ошибку, аналогичную описанной вами.

Ответ 5

Если эта ошибка возникает во время сеанса кодирования, где он ранее работал, не делая ничего, например, закрывая Visual Studio или ваш SLN, посмотрите, можете ли вы удалить тестовый проект из SLN, а затем повторно добавьте его.

Если вы не можете (или, по крайней мере, не без обходных путей), тогда подумайте об удалении файла SLN и его повторном создании. Вот как меня разблокировали. Ничто другое не сработало, но мне было лень искать net.pipe, так как я считал, что это неразрешимая проблема автоматизации, и не интересовался этим маршрутом.