Aktivieren der Assembler-Fehlerprotokollierung (Fusion) in .NET

Question

Wie aktiviere ich die Protokollierung von Assemblerfehlern (Fusion) in .NET?

Answer 1

Es ist so viel falsch mit dem Assembly Binding Log Viewer (FUSLOGVW.exe), dass ich beschlossen habe, einen alternativen Viewer mit dem Namen Fusion++ und stellen es auf GitHub . Es verwendet intern dieselbe Mechanik sondern wertet die Protokolle für Sie aus. Sie müssen sich um keinerlei Einstellungen kümmern, nicht einmal um Protokollpfade

Sie erhalten die neueste Version von aquí oder über chocolatey ( choco install fusionplusplus ).

Ich hoffe, Sie und einige der Besucher hier können damit einige wertvolle Lebensminuten sparen.

Answer 2

El Skript zum Ändern der Einstellungen für den Fusion Log Viewer ist ohne Zweifel der beste Weg, dies zu tun.

Unter ASP.NET war es manchmal schwierig, dies richtig zu bewerkstelligen. Dieses Skript funktioniert großartig und wurde aufgeführt auf Scott Hanselman's Liste der Elektrowerkzeuge auch. Ich persönlich benutze es schon seit Jahren und es hat mich nie im Stich gelassen.

Answer 3

Anstatt eine unschöne Protokolldatei zu verwenden, können Sie das Fusion-Log auch über ETW/xperf durch Einschalten des privaten DotnetRuntime-Anbieters ( Microsoft-Windows-DotNETRuntimePrivate ) mit GUID 763FD754-7086-4DFE-95EB-C01A46FAF4CA et le FusionKeyword Schlüsselwort (0x4) ein.

@echo off
echo Press a key when ready to start...
pause
echo .
echo ...Capturing...
echo .

"C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xperf.exe" -on PROC_THREAD+LOADER+PROFILE -stackwalk Profile -buffersize 1024 -MaxFile 2048 -FileMode Circular -f Kernel.etl
"C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xperf.exe" -start ClrSession -on Microsoft-Windows-DotNETRuntime:0x8118:0x5:'stack'+763FD754-7086-4DFE-95EB-C01A46FAF4CA:0x4:0x5 -f clr.etl -buffersize 1024

echo Press a key when you want to stop...
pause
pause
echo .
echo ...Stopping...
echo .

"C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xperf.exe" -start ClrRundownSession -on Microsoft-Windows-DotNETRuntime:0x8118:0x5:'stack'+Microsoft-Windows-DotNETRuntimeRundown:0x118:0x5:'stack' -f clr_DCend.etl -buffersize 1024 

timeout /t 15

set XPERF_CreateNGenPdbs=1

"C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xperf.exe" -stop ClrSession ClrRundownSession 
"C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xperf.exe" -stop
"C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\xperf.exe" -merge kernel.etl clr.etl clr_DCend.etl Result.etl -compress
del kernel.etl
del clr.etl
del clr_DCend.etl

Wenn Sie nun die ETL-Datei in PerfView und schauen Sie unter der Tabelle Ereignisse nach, dort finden Sie die Fusionsdaten:

Answer 4

Für diejenigen, die ein bisschen faul sind, empfehle ich, dies als Bat-Datei auszuführen, wann immer Sie es aktivieren möchten:

reg add "HKLM\Software\Microsoft\Fusion" /v EnableLog /t REG_DWORD /d 1 /f
reg add "HKLM\Software\Microsoft\Fusion" /v ForceLog /t REG_DWORD /d 1 /f
reg add "HKLM\Software\Microsoft\Fusion" /v LogFailures /t REG_DWORD /d 1 /f
reg add "HKLM\Software\Microsoft\Fusion" /v LogResourceBinds /t REG_DWORD /d 1 /f
reg add "HKLM\Software\Microsoft\Fusion" /v LogPath /t REG_SZ /d C:\FusionLog\

if not exist "C:\FusionLog\" mkdir C:\FusionLog

Answer 5

Nur ein winziges bisschen Info, die anderen helfen könnte; wenn Sie etwas entlang der Linien der Suche alle Baugruppen in einigen Verzeichnis für Klassen, die erben/Implementieren Klassen/Schnittstellen tun, dann stellen Sie sicher, dass Sie veraltete Baugruppen bereinigen, wenn Sie diesen Fehler in Bezug auf eine Ihrer eigenen Baugruppen erhalten.

Das Szenario würde etwa so aussehen:

1. Baugruppe A lädt alle Baugruppen in einem Ordner
2. Baugruppe B in diesem Ordner ist veraltet, verweist aber auf Baugruppe C
3. Assembly C existiert, aber Namespaces, Klassennamen oder ein anderes Detail könnten sich in der Zeit, die vergangen ist, seit Assembly B veraltet ist, geändert haben (in meinem Fall wurde ein Namespace durch einen Refactoring-Prozess geändert)

Kurz gesagt: A ---lädt--> B (veraltet) ---verweist---> C

In diesem Fall ist das einzige verräterische Zeichen der Namespace und der Klassenname in der Fehlermeldung. Untersuchen Sie diese genau. Wenn Sie ihn nirgendwo in Ihrer Lösung finden können, versuchen Sie wahrscheinlich, eine veraltete Assembly zu laden.