September 03, 2009

Loading Assemblies, Assembly.Load, Assembly.LoadFrom, Assembly.LoadFile, appDomain.Load

I always find this topic a great source of confusion each time I get back to it.
I've just across various Exceptions being thrown in my application, FileNotFoundException and AccessViolationException.
The first caused because the application cannot location a Type that one of my assemblies references and lives in another assembly.
The second is caused by that same file being found but it's locked by another process i.e. something else is reading or has read and not released the assembly.
Both of the above were caused by messy code which used a simple Assembly.LoadFile(...). Looks to me like you should never use this method, I'll explain more below.

There are many ways to create an Assembly instance.
Assembly.Load(assemblyName);
Assembly.LoadFile(assemblyName);
Assembly.LoadFrom(assemblyName);

or even
AppDomain.Load(assemblyName);

There are some subtelties however, some consequences which may later cause issues e.g. the assembly you've loaded is locked.

Assembly.LoadFile is the simplest but most crude solution, it simple reads an assembly, the assembly should be standalone, no references to Types other than the .NET. The file may have issues later too as it maybe locked until the application is shut down.

Assembly.LoadFrom is a bit more intelligent, it uses the current AppDomains settings, if there's an issue with references then the current AppDomain will try to find the Types using the it's settings.


The most complete solution but not the easiest to debug is the use of the AppDomain.Load. This in my experience is tricky until you get used to what all the properties on the AppDomain mean.
What you do is setup a new AppDomain, until you unload that AppDomain everthing that happens in the meantime is in the context of your new AppDomain's settings.
This will help you resolve references to your assembly in code, you can configure where the AppDomain should look when the Load fails to locate an Type.



No comments: