クライアントプロキシの初期化に失敗しました：vstest.discoveryengine.x86.exeに接続できませんでした
以前は、Visual Studio 2013で特定のプロジェクトの単体テストを問題なく実行できました。これは最近プロジェクトに大きな変更を加えることなく動作を停止しました。ただし、プロジェクト自体への変更は最小限であり（1つまたは2つの新しい方法）、 構成ファイルの変更または同様に頻繁に報告される問題 は含まれていません。むしろ、Visual Studioの変更（おそらく最近の更新）、プラグイン、またはサードパーティのソフトウェアが次の問題を引き起こしていると思います。
プロジェクトの読み込み中、1分後に出力ウィンドウの「テスト」出力に次のように表示されます。
------検出テストが開始されました------
クライアントプロキシの初期化に失敗しました：テストプロセス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です。
同じことが、最後の行がI, 8232, 1, 2014/12/22, 01:46:13.942, 63486587413, vstest.discoveryengine.exe, ServiceMain: Started the service Host 8232である検出エンジンにも当てはまります。
誰かが同様の問題に遭遇しましたか？これに最もよく取り組む方法は？管理者としてVisual Studioを常に実行していることが適切なソリューションであるとは思いません。
Windows 10でVisual Studio 2015を使用して同じ問題が発生しました。多くのデバッグを行った後、問題は別のプログラムにあることがわかりました。
個別のvstest実行可能ファイルは、名前付きパイプ（net.pipeプロトコル、net.pipe://machinename/vstest.discoveryengine/12345などのエンドポイントURL）を介してWCFを使用して（Visual StudioまたはVSTestコンソールで実行される）メインエンジンと通信します。結局のところ、特権アカウントで実行されているアプリケーションが別のURLのプレフィックスであるnet.pipe URLをリッスンするときはいつでも、他の非特権アカウントは長いURLをリッスンできません（管理者として実行している場合のみ）。
そして、結局のところ、管理者またはローカルシステムがnet.pipe://localhost/をリッスンして実行するさまざまなアプリケーションがあります。その場合、非特権ユーザーで実行されているVSTestプロセスを含むWCFアプリケーションは、名前付きパイプでサーバーを実行できません。 netpipesで実行する最小限のWCFの例を作成してみてください 。その簡単な例でさえ、私のマシンで管理者として実行された場合にのみ機能しました（そうでない場合、「net.pipe：//…でリッスンするエンドポイントはありませんでした」が続いた）。
私はSysinternals Process Explorer、Ctrl + Fを使用して「net.pipe」を検索し、ネットパイプが開いているプロセスを見つけました。私の場合は、ローカルシステムサービスとして実行されている「net.pipe：// localhost /」の直下にエンドポイントがあるWCFサーバーを保持するRazerの「RzWizardService」でした。サービスを停止すると、すべてが正常に動作し始めました。
VS 2015とVS 2017でも同じ問題に直面していました。いくつかの方法（WASの無効化、VS 2015の再インストール、SubInACLツールの起動、セーフモードでのVS 2015の起動など）を確認した後、次のことがわかりました。
- VS 2015をAdmnistratorとして実行すると問題が解決し、テストエクスプローラーで再びテストが表示されます。ただし、これは単なる回避策であり、最終的な解決策ではありません。
- そのため、いくつかのグーグルの後で、現在のユーザーの書き込み/変更権限を「％ProgramData％\ Package Cache」フォルダーに追加することからなる別の解決策を見つけました。詳細はこちら link をご覧ください。現在、私のユーザーアカウントでVS 2015を起動すると、テストエクスプローラーがすべてのテストをすばやく検出し、エラーメッセージが表示されなくなりました。
Visual StudioやSLNを閉じるなどの作業をせずに以前機能していたコーディングセッション中にこのエラーが発生した場合は、SLNからテストプロジェクトを削除してから再度追加できるかどうかを確認してください。
できない場合（または少なくとも回避策がない場合）、SLNファイルを削除して再作成することを検討してください。それが私がブロックされなかった方法です。他には何も機能しませんでしたが、TBH私はnet.pipeを探すのが面倒でした。私は扱いにくい自動化の問題だと考え、そのルートを追求することに興味がなかったからです。
最近同じ問題が発生しました。あなたが言ったように、それは別のサードパーティのライブラリからのいくつかの干渉である可能性があります。私の場合、VS-plugin Emmet をアンインストールしてみました。これは私のために働いた。再起動後、テストが再発見されました。
私の問題は、自分のマシンに新しいユーザーを作成し、UWPテストアプリがまだ他のユーザーにインストールされていることでした。これは許可されていません（そうです）。アンインストールする必要がありました。
アプリがインストールされているかどうかを確認するには、管理者としてPowerShellを実行し、次のコマンドを実行します。
Get-AppPackage *YourTestAppNameHere* -AllUsers
結果がある場合は、アプリがインストールされていることを意味します。その後、次のコマンドでアンインストールできます。
Get-AppPackage *YourTestAppNameHere* -AllUsers | Remove-AppPackage -AllUsers
最初のコマンドを再度実行して、正しくアンインストールされたことを確認します。
Windows設定が開発者向けに設定されていることを確認してください-この設定に変更すると、開発者向けのパッケージが自動的にインストールされ、UWP C＃ユニットテストが実行されます。