Rules are meant to be bro.. ahem expanded. Especially if everybody tells you not to do so ;-). The Assembly Loader Rules are for example a very strict set of rules. One rule of the loader is that you cannot load assemblies from directories above the directory where the executable is located. This can cause some headaches if you want to share some assemblies across applications which are not installed inside the GAC. You can bypass this restriction by using Assembly.LoadFrom. A very good article about the how and when of Assembly.LoadFrom can be found at GotDotNet. If you have to deal with plugin architectures and loosely coupled components you will soon end up in a situation where you need to expand the default assembly loader rules. You can configure the loader to some extent via your App.Config file but you cannot configure a probing path for directories above your application binary location. Lets suppose you have an application lets call it App.exe which references ClassLibrary1.Dll which in turn references ClassLibrary2.dll. Now you have to call Assembly.LoadFrom for ClassLibrary1.dll for some reason (e.g. it is a configured plugin). I have drawn the dependencies in the diagram below
What will happen to your application domain when you try to load the same dll with LoadFrom after it has already been loaded because it was
referenced by the application? The following code illustrates this:
class Program
{
static void Main(string[] args)
{
// Cause load of referenced ClassLibrary1.dll when entering this function
// which contains the type ClassLibrary1.Class1
ClassLibrary1.Class1 Instance = new ClassLibrary1.Class1();
// Load ClassLibrary1.dll from another directory a second time but does NOT load
// the referenced assembly ClassLibrary2.dll!
Assembly assembly = Assembly.LoadFrom(
@"C:\Source\LoadedAssemblies\ClassLibrary1\bin\Debug\ClassLibrary1.dll");
// Create another instance from the same type that is located in another assembly
object obj = assembly.CreateInstance("ClassLibrary1.Class1");
// Now we have ClassLibrary1.dll loaded two times into our AppDomain
// Types loaded from different assemblies (even identical) cannot be cast to each other!
// instance will always be null.
ClassLibrary1.Class1 instanceFromOtherAssembly = obj as ClassLibrary1.Class1;
}
}
The result is that ClassLibrary1.dll will be loaded into your AppDomain twice as you can easily check in the Debug->Windows->Modules window.
Loading the same assembly (same file size, same version, even binary identical) twice into an AppDomain is normally an error (at least I cannot think of a reason why you possible would like to do that). This can happen very easily when you have mis configured your plugins. These errors manifest in strange behavior and NullReferenceExceptions at weird places. The types from even binary identical assemblies are not the same for the CLR if the assembly is loaded multiple times into the same AppDomain. This results in the somewhat unexpected behavior of the following code fragment:
ClassLibrary1.Class1 instanceFromOtherAssembly = obj as ClassLibrary1.Class1; // instance will always be null.
Ok this is something that should be avoided. Luckily we can check very easy if our AppDomain is in a healthy state by checking for double loaded assemblies after we
did load our plugins or extensions. The following utility class does exactly this. Check you AppDomain for double/multi loaded assemblies:
Addenum: JMT (I do not know his real name) was so kind to point out that I had an error in my algorithm which could miss some double loads. I have updated the source now. Good work JMT.
LoadedAssemblyChecker.cs
using System;
using System.Collections.Generic;
using System.Text;
using System.Reflection;
namespace Microsoft.Practices.EnterpriseLibrary.Configuration.Console
{
/// <summary>
/// Check if assemblies are loaded multiple times into a application domain. This is
/// in most cases an error which is not so easy to find.
/// </summary>
public class LoadedAssemblyChecker
{
class AssemblyInfo
{
string myName;
public string Name
{
get { return myName; }
}
string myLocation;
public string Location
{
get { return myLocation; }
}
public AssemblyInfo(string name, string location)
{
myName = name;
myLocation = location;
}
}
/// <summary>
/// Check the current Application domain if there are assemblies loaded multiple times.
/// </summary>
/// <returns>Dictionary which contains as key the assembly name which is loaded multiple times and as key
/// as string list with the locations from where it was loaded.When no conflict has
/// been determined an emtpy list is returned.</returns>
public static IDictionary<string, IList<string>> GetConflictingAssemblies()
{
Assembly[] ass = AppDomain.CurrentDomain.GetAssemblies();
List<AssemblyInfo> TotalList = new List<AssemblyInfo>();
foreach (Assembly assembly in ass)
{
AssemblyInfo info = new AssemblyInfo(assembly.GetName().Name, assembly.CodeBase);
TotalList.Add(info);
}
Dictionary<string, IList<string>> ConflictingList = new Dictionary<string, IList<string>>();
AssemblyInfo curInfo;
AssemblyInfo secondInfo;
for (int i = 0; i < TotalList.Count; i++)
{
curInfo = TotalList[i];
for (int j = i + 1; j < TotalList.Count; )
{
secondInfo = TotalList[j];
if (String.Compare(curInfo.Name, secondInfo.Name, true) == 0)
{
if (!ConflictingList.ContainsKey(curInfo.Name))
{
List<string> Locations = new List<string>();
ConflictingList.Add(curInfo.Name, Locations);
ConflictingList[curInfo.Name].Add(curInfo.Location);
}
ConflictingList[curInfo.Name].Add(secondInfo.Location);
TotalList.Remove(secondInfo);
}
else j++;
}
}
return ConflictingList;
}
}
}
With this little helper class you can easily identify the conflicts and warn the user after you have loaded all avialiable plugins:
IDictionary<string, IList<string>> list = LoadedAssemblyChecker.GetConflictingAssemblies();
foreach (KeyValuePair<string,IList<string> > info in list)
{
Console.WriteLine("Detected multiple load of assembly {0} from ",info.Key);
foreach(string Location in info.Value)
{
Console.WriteLine("\t{0}", Location);
}
}
Expected Output:
Detected multiple load of assembly ClassLibrary1 from
file:///C:/Source/LoadedAssemblies/LoadedAssemblies/bin/Debug/ClassLibrary1.DLL
file:///C:/Source/LoadedAssemblies/ClassLibrary1/bin/Debug/ClassLibrary1.dll
This mechanism is employed in my extension to the Enterprise Library Configuration Tool which allows you to configure where the assembly loader should look for plugins and their dependent assemblies. Assembly loading can be a tricky business if you do not know the rules. I hope this explains at least some of the oddities that can happen to your application during development. This type of checker is very valuable to find debug/release mismatches where one half of your app uses the debug version of an assembly and the rest uses the release version. This little class can help you a lot to diagnose deployment errors at runtime inside your application.