Alternative to Fusion Log Viewer?

Question

Are there any alternative Fusion Log Viewer programs, other than Fuslogvw.exe, or directing the Fusion log output to your own directory and then examining the tons of HTM files by hand?

My two main gripes are:

1. I'd like an overview that showed which assembly loads succeeded and which failed.

2. I'm unsure of the resolution of the timestamps on the logging files, so I'm unsure of which entry comes before another entry. For example, my program is apparently trying to load an assembly with both culture=da and culture=da-dk. It should only be trying to load da-dk, and in fact that load is successful. So why is it also (unsuccessfully) trying to load culture=da? It might help if I at least was sure of the order in which it is trying to do these loads, but Fuslogvw.exe displays the two entries randomly, and logging to a private directory isn't much better.

Disorganization

See here for a possible alternative (I haven't tried it myself): https://mcmap.net/q/53395/-how-to-enable-assembly-bind-failure-logging-fusion-in-net – Disorganization

Answer 1

Might be late to the party but I think Fusion++ is a pretty good match for your question.

It takes everything away from you - no more file hunting: Just click "Record" to capture assembly logs. If you are done, click "Stop" again and Fusion++ will parse all the log files for you.

Jeremie

I'm impressed that someone could be bothered answering an 8 year old question. :-) – Disorganization

Answer 2

All the Fusion Log Viewer does is flip some registry settings and examine the log files.

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion
Add:
DWORD ForceLog set value to 1
DWORD LogFailures set value to 1
DWORD LogResourceBinds set value to 1
String LogPath set value to folder for logs (e.g. C:\FusionLog\)

It might not be possible to determine exactly when each assembly is loaded based on the fusion loader's output. The fusion loader is somewhat of a black box in that respect.

Your best bet might be to step directly into your application with the debugger and watch the Modules window in Visual Studio. If you step carefully through the application, you should be able to see at which point each assembly gets loaded into memory.

Isabeau