4

The Assembly Binding Log Viewer is rather buggy (for instance, more often than not it won't empty the log) and rather short on features (searching, ordering, filtering are all but available).

So I was wondering whether either

  • An existing alternative exists
  • Hooking the assemblyresolve events globally is somehow possible, so I can do this myself
  • Microsoft has published the source somewhere and we're allowed to fork it

Short of the second option, I know you can create a CLR Host implementation relatively simply (albeit non-trivially), but it seems overkill if all you need is a bit more finegrained control than the existing Fusion log viewer.

Note, I've seen this answer, but that doesn't seem to answer this question.

In answer to some of the comments:

I am aware of assembly redirecting, the AssemblyResolve and the AssemblyLoad events, but the first can only be used as a last resort (last in the probing chain) and the second will only fire after an assembly is loaded. Neither can be used on other processes than your own and neither can show the whole probing process.

I have noticed that using RyuJIT some bindings appear slightly different, in a different order as a result of a different way of compiling and loading the compiled IL. While I have been able to research and resolve the binding issues, I have come to very much dislike fuslogvw.exe as a time consuming (though one of a kind and helpful) tool. Hence I started a (rather fruitless) search for a better tool to monitor the probing process.

StayOnTarget
  • 11,743
  • 10
  • 52
  • 81
Abel
  • 56,041
  • 24
  • 146
  • 247
  • Is handling [`AppDomain.AssemblyLoad`](https://msdn.microsoft.com/en-us/library/system.appdomain.assemblyload%28v=vs.110%29.aspx) what you're looking for? This would give you the ability to inspect every assembly that gets loaded into the application domain. The `AppDomain.AssemblyResolve` event gives you all assemblies before they're loaded so it lets you determine assembly errors. – xxbbcc Dec 10 '15 at 19:10
  • @xxbbcc, Tx for the suggestion, but I use these already. They won't help resolving issues with these methods, besides, one failure means all will fail. I need an out of process method, like fusion, but preferably under my control. – Abel Dec 10 '15 at 19:53
  • I'm not sure I understand what you mean by "one failure means all will fail" - failing to load an assembly is the end of the process. What would the Fusion log viewer show differently? Your question seems very vague on what you need (other than that you need a different way to track assembly binding?) – xxbbcc Dec 10 '15 at 20:04
  • @xxbbcc, the events you mention serve as a way to resolve a limited set of cases from your own assembly, but can't be used with other assemblies in other processes. Also, there are cases that can be solved with `app.config` binding redirects, but not with `AssemblyResolve` (i.e., strong name redirect). Through managed code, afaik, there's no way to show the whole probing process, only `fuslogvw.exe` can show them, but that tool is archaic and terribly unhandy to use. I hope for a better way to monitor the probing process. I think I have to roll my own (and maybe share with community ;). – Abel Dec 10 '15 at 21:43
  • Ah, ok - if you're trying to monitor 3rd-party processes, you need a standalone tool. – xxbbcc Dec 10 '15 at 21:44
  • @xxbbcc not only that, it is also to monitor my own process. For instance, it differs when I bind the `AssemblyResolve` event at the `.cctor` (in which case Fusion fails because I fail) or at a more "normal" place in the code (in which case Fusion succeeds sometimes because it resolves it prior to me binding the event). It also fails or succeeds depending on host process (i.e. nUnit fails, NCrunch succeeds). Resolving issues like that, the Fusion Log Viewer is a necessary evil. I updated the question, hopefully it is a bit clearer now. – Abel Dec 10 '15 at 21:54
  • PS: I've found why nUnit runner fails and nCrunch does not, it has to do with the way they create shadow copies of the assemblies and how this results in Fusion not finding its references. But still, it is a painstaking process to locate these issues. So, anything better than fuslogvw is very welcome. – Abel Dec 10 '15 at 21:57
  • Yes, I understand your pain - I wrote (a while ago) an assembly resolver that tried to simulate the entire process of assembly resolution as closely as possible (including binding redirects, etc.) It was proprietary so I can't offer the source but I know how complicated and under-documented the binding process is. – xxbbcc Dec 10 '15 at 23:12
  • @xxbbcc if you managed to resolve the issue where you are trying to redirect a strongly named assembly to another strongly named assembly (in my case usually FSharp.Core 4.3 to 4.4) with the `AssemblyResolve` event then I'd love to hear from it (if disclosing that part is allowed). It works with `bindingRedirect` inside `app.config`, but in some cases I need it from code (when just the dll is loaded by another process it won't honor the `.config` settings). Non strongly-named assemblies I can bind to anything else, but Fusion prevents me from redirecting strongly named ones. – Abel Dec 10 '15 at 23:26
  • No, it wasn't done at runtime so I didn't use those events. This was part of a tool that analyzed IL and mapped out all type relationships so I had to find and load assemblies as if they were loaded at (their own) runtime. However, my tool actually imitated the binding process, not used it - I had to parse the config files, look up assemblies in the GAC and in local Bin folders and figure out which assemblies would be loaded at the end. It was a pretty involved process. – xxbbcc Dec 10 '15 at 23:46
  • It handled a number of fringe cases but I can't tell if it was correct or not because I never had definitive behavior to start with. It involved a lot of experimentation with different folder layouts and various binding redirects. – xxbbcc Dec 10 '15 at 23:47
  • @xxbbcc, sounds like a hard job! I know I can use our own clr host process (used for a total different purpose), but that will only make things harder and creates portability issues. Anyway, thanks for all the help and thinking along. If time permits I'll roll my own fusion logger. Currently I'll have to settle with the events, which are already in place, and I'll stick with the manual process of fixing edge cases. – Abel Dec 10 '15 at 23:55
  • You may be familiar with this already but this is what I used as base documentation when I worked on that project: https://msdn.microsoft.com/en-us/library/7wd6ex19%28v=vs.110%29.aspx – xxbbcc Dec 11 '15 at 18:39
  • @xxbbcc, tx, yes, I'm familiar with that, it explains the basics of assembly redirects. – Abel Dec 11 '15 at 18:50

1 Answers1

5

Might be late to the party but maybe some of you might be interested in a modern alternative to FUSLOGVW.exe I put on GitHub lately: Fusion++

Fusion++

It's super easy to use: Just click "Record" to capture assembly logs. If you are done, click "Stop" again and Fusion++ will parse all the log files for you.

Under the hood, it uses the same mechanisms as the good ol' FUSLOGVW.exe.

Waescher
  • 5,361
  • 3
  • 34
  • 51
  • Sounds awesome! I've been tinkering with that idea myself a few times, but FuslogVw uses undocumented API calls so a full rewrite proved difficult. I understand you're basically using the existing mechanism and display it in more meaningful way? – Abel Jun 14 '19 at 01:58
  • 1
    Also, this is the only answer in 4 years, and Microsoft hasn't done anything to improve, or open-source that FuslogVw.exe, so I'm quite happy with this attempt :) – Abel Jun 14 '19 at 02:00
  • Happy to help and yes, I'm just activating the default .NET logging via the Windows Registry (abstracting the settings and log paths away from the user, because why should he care?) and make sure everything's reverted after stopping a session. Then, Fusion++ parses the files and brings it to the UI to prevent you from scanning the file system by yourself. – Waescher Jun 14 '19 at 08:14