Unable to load assembly

Unable to load assembly

With the beautiful late binding of .net .dlls there has been introduced a load of problems related to assemblies fitting together – or not. Difficulty in detecting whether assemblies are compiled for 32 or 64 bit doesn’t really help at all.

When one gets a typically very non-descriptive message that the application had problems loading a specific assembly one often sees little more than a few question marks popping up before the internal eye. I will try to remove at least a few of those.

Fusion Log Viewer

A good place to start is the Fusion Log Viewer which is included with most Win SDK installations. Starting it, one gets a few options (->Settings) to enable different logging variations. All of those can be manually set via registry editing (HKLMSoftwareMicrosoftFusionLogPath) – a GUI typically is a bit more user friendly and doesn’t have you google all the options.

Once logging is enabled, the failure message becomes (only a little) more meaningful. More helpful are the files that can be found on disk after enabling the „Log bind failures to disk“ option. The generated logs are .html files.

Typical Problems

32/64 bit issues

One of my personal favourites: mixing 32 and 64 bit assemblies. This of course is (if you built them yourself) a problem with how your projects are set up. Most often, this can be avoided by not building assemblies for specific versions, but by just choosing „Any CPU“ as a build target platform. In the cases where this cannot be avoided, check that your target platform is correctly set, and also that the output path is correct, that not one configuration e. g. writes to the output directory of another configuration.

Bad References

A pretty nasty to find problem can be a bad build reference. E. g. you still have an old version of an assembly lying around somewhere and this is in a reference path that is first in order before the reference path where your current assembly lies. You only notice this (if your project still builds) when you actually deploy to a different directory.

Typically, reference paths are problematic, e. g. since it is not easy enough to change them for different build configurations like Release, Debug, x86 or x64. Most often the best way is to use no specific reference paths and simply use the output directory to store all assemblies that belong together and get their reference from there as well. Also note, that there is a specific order in which paths are searched for references. (Also, by editing the .csproj.user file, you can set references for specific configurations, but you will lose the ability to (properly) edit this using the IDE.)

Use a Debugger

Sometimes, only the Debugger can help. Most often, this only tells you something you would have found out just by using the Fusion Logs, but.. a Debugger might be a lot more familiar than reading Fusion Logs.

How to avoid all of this

Set up your projects well. Straightforward builds that produce files that are easily deployed make your development a lot more fun.

If you target several platforms, make sure that you have a system behind your builds and settings that helps making things easier and not more difficult.

Simple always wins. (Well, very often at least.)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.