vstest.console.exe mit / EnableCodeCoverage nur "hängt" ... wie debuggen, und wie zu beheben?

8

Ich verwende vstest.console.exe (VS2012), um Tests mit / EnableCodeCoverage auszuführen, und mit .runsettings, die einen DataCollector "Code Coverage" definieren (siehe CodeCoverage.runsettings im Codeblock unten).

Ich laufe von einem Powershell-Build-Skript, das Folgendes aufruft:

vstest.console.exe / inIsolation / Logger: trx / EnableCodeCoverage / Settings: CodeCoverage.runsettings / TestCaseFilter: "TestCategory = Kunden" bin \ Release \ Sdm.Test.IntegTest.dll

Früher funktionierte dieser Befehl, aber ein neues Projekt, das einen alten Legacy-Code integriert hat, hat eine Menge neuer Abhängigkeiten / DLLs mit sich gebracht.

Was ich sehe, ist, dass der Befehl einfach "hängt" und niemals einen der Tests ausführt. Wenn ich den SysInternals Process Explorer verwende, sehe ich einige Aktivitäten in vstest.executionengine.exe ... Meine beste Vermutung ist, dass es versucht, eine ganze Reihe von DLLs zu instrumentieren, die meine .runsettings-Datei sagt, sollte ausgeschlossen werden. Aber das ist nur eine Vermutung.

Jede Hilfe, um herauszufinden, wie das Problem zu diagnostizieren ist, wird geschätzt.

CodeCoverage.runsettings unten:

%Vor%     
Dan Haywood 01.07.2014, 17:11
quelle

1 Antwort

14

Der einzige Hinweis, den ich finden konnte, führte schließlich zu einer Lösung in der Ereignisanzeige, nämlich:

%Vor%

Das hat mich letztendlich zu einer Lösung geführt, die hinzuzufügen ist:

%Vor%

an vstest.executionengine.exe.config (wenn 64bit ausgeführt wird) oder vstest.executionengine.x86.exe.config (wenn 32bit ausgeführt wird).

Dies funktioniert sowohl unter VS (wenn von devenv.exe erzeugt) als auch über die Befehlszeile (wenn von vstest.console.exe erzeugt)

Hier sind einige Hinweise, die mich zu dieser Lösung gebracht haben:

Die neuen DLLs, auf die verwiesen wird, enthalten einige ziemlich alten Code, der gegen .NET 2.0 erstellt wurde. Nach langem Suchen habe ich folgendes zusammengestellt:

  • vstest.executionengine.exe verwendet die .NET 4-Profiling-Funktionen für die Instrumentierung der dynamischen Codeabdeckung
  • Die Fehlermeldung der Ereignisanzeige ist ein obskurer Hinweis darauf, dass vstest.executionengine.exe den .NET 2.0 Profiler nicht starten kann
  • Wie oben erwähnt, besteht die Fehlerbehebung darin, die Datei .config zu aktualisieren (dh vstest.executionengine.exe.config).

Es ist nicht möglich, dieses Zeug zur app.config des Projekts hinzuzufügen, das die Tests enthält; Es muss in die Konfiguration von vstest.executionengine gehen (weil die exe gerade läuft).

Andere Dinge, die ich ausprobierte (von denen letztlich nichts half):

Diagnose in der Registrierung

%Vor%
  • EnableTracing DWORD = 1
  • TraceLevel DWORD = 4

Diagnose in den * .config-Dateien

für vstest.console.exe, vstest.discoveryengine. *. exe, vstest.executionengine. *. exe

%Vor%

hinzugefügt:

%Vor%

... dadurch werden Protokolldateien in% TEMP%

geschrieben

Red Hering: Erprobte Einstellungen für Umgebungsvariablen zum Deaktivieren

%Vor%

... versuchte den .NET 2 Profiler zu deaktivieren, tat aber nichts.

Weitere Untersuchungen (mit procexp.exe) haben gezeigt, dass vstest.executionengine.exe immer COR_ENABLE_PROFILING = 1 unabhängig von env var.

setzt

Außerdem ist COR_PROFILER auf guid gesetzt

  • war für mich COR_PROFILER = {B19F184A-CC62-4137-9A6F-AF0F91730165}
  • über regedit, HKEY_LOCAL_MACHINE \ SOFTWARE \ Klassen \ CLSID {B19F184A-CC62-4137-9A6F-AF0F91730165} \ InprocServer32
  • entspricht "C: \ Programme (x86) \ Microsoft Visual Studio 11.0 \ Common7 \ IDE \ CommonExtensions \ Microsoft \ IntelliTrace \ 11.0.0 \ x64 \ Microsoft.IntelliTrace.Profiler.11.0.0.dll"

Mit Blick auf die Ereignisanzeige habe ich Info-Nachrichten gesehen, dass der .NET 4 Profiler erfolgreich gestartet wurde:

%Vor%

Die Protokolldateien in% TEMP% haben ebenfalls keine Probleme vorgeschlagen.

Red Hering: Versucht, in die andere Richtung zu gehen und via env vars zu aktivieren:

%Vor%

hat auch keinen Unterschied gemacht.

Andere rote Heringe

  • gelegentliche Nachrichten in der Ereignisanzeige des Formulars:

    engine :: notify_process_attach ist mit Ausnahme fehlgeschlagen: Die Sitzung "MTM_7d145e0c-1c26-44b0-89e5-acc448aaae6d" existiert nicht.

  • vstest.discoveryengine.TpTrace.log ... der Fehler "AddProcess: Failed to AddProcess 5" scheint ebenfalls irrelevant zu sein.

    'System.EventHandler'1 [Microsoft.VisualStudio.TestTools.Execution.SessionStartEventArgs]' auf 'Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector' I, 2800, 11, 01.07.2014, 10: 59: 11,875, PCKMA0419 \ vstest.discoveryengine.exe, Gestarteter Vangaurd-Prozess mit Befehlszeile unregister / Platzhalter / Sitzung: MTM_ * I, 2800, 11, 01.07.2014, 10: 59: 11.880, PCKMA0419 \ vstest.discoveryengine.exe, Vangaurd-Prozess zum Projektobjekt hinzufügen W, 2800, 11, 01.07.2014, 10: 59: 11.882, PCKMA0419 \ vstest.discoveryengine.exe, AddProcess: Fehler beim AddProcess 5 I, 2800, 11, 2014.07.01, 10: 59: 11,882, PCKMA0419 \ vstest.discoveryengine.exe, Started Vangaurd Prozess mit Befehlszeile sammeln / session: MTM_64f33307-c936-469e-b068-482ec0ea45cf / Ausgabe: "C : \ Users \ danhaywood \ AppData \ Local \ Temp \ MTM_64f33307-c936-469e-b068-482ec0ea45cf \ c44e78af-2475-4747-99f3-e0fc3ca41d51 \ DanHaywood_PCKMA0419 2014.07.01 10_59_11.coverage“/ config:

"C: \ Benutzer \ danhaywood \ AppData \ Local \ Temp \ MTM_64f33307-c936-469e-b068-482ec0ea45cf \ CodeCoverage.config" ~~~

Unterwegs konsultierte Blogs:

Dan Haywood 01.07.2014, 17:11
quelle

Tags und Links

Django: Verwenden von Annotate, Count und Distinct in einem Queryset So fügen Sie wöchentliche Zeittasks in Bezug auf Sommerzeitzonen hinzu