Loading an Assembly on Demand

Introduction

In this article, I'll show you how to load an assembly dynamically on demand. Recently I worked on a project where I needed to load the same assembly from different code bases. Assemblies were located in different locations as per the environment (dev/qa/uat/prod). Also, I wanted to load them into a different application domain, so they will work in their domain and will not interfere with any of the other tasks. When I am done with the assembly, I can unload them.

Current AppDomain vs new AppDomain

The Current application domain is the AppDomain, where your current application is running. If you load assemblies in the same AppDomain, they will be locked, and cannot be unloaded. It will remain there until you exit from the application. This situation fails the requirement of loading multiple assemblies. If an assembly is loaded in a different AppDomain then it will allow us to unload the AppDomain at any point in time and release memory.

Instantiating Class

If an assembly is loaded into the same AppDomain, then the class can be instantiated in the usual way. But if an assembly is loaded into a different AppDomain then it can be instantiated using reflection. Another way is an interface. However, this interface should be implemented in the assembly which is being loaded dynamically. Here I am going over a second method where I created an interface in an assembly that is being referred to by both assemblies; the current appdomain assembly and the assembly which I want to load dynamically.

I wanted to create an add-in for Outlook that pushes meetings from Outlook to my application. I wanted to allow pushing the meeting to a different environment based on the option the user selects. These options are available based on the user's group. I am not going to discuss an Outlook add-in here. I will discuss that in another article dedicated to Outlook.

I created an assembly AddInCommon where I created an interface IMyAddIn and implemented it in a MyAddIn abstract class.

public interface IMyAddin
{
    void ShowMessage();
    void Increment();
}

public abstract class MyAddIn : MarshalByRefObject, IMyAddin
{
    public abstract void ShowMessage();
    public abstract void Increment();
}

This class will be inherited in the class of the dynamically loaded assembly.

[Serializable]
publicclassMyClass
{
publicintcounter=0;
publicstringShowMessage()
{
Console.WriteLine("AssembplyPath:"+Assembly.GetExecutingAssembly().CodeBase);
Console.WriteLine("MDLibOne.MyClass.ShowMessage");
return"AssembplyPath:"+Assembly.GetExecutingAssembly().CodeBase;
}

publicvoidIncrement()
{
Console.WriteLine("Counter:"+++counter);
}
}

MyClass is serializable because this class will be used in the currentAppDomain, while it is defined in its assembly. An object needs to be serialized and deserialized back in the current app domain. Both application domains have different memory allocations and can't share the object. Create an AppDomainSetup for each codebase you want to load. The following example creates the AppDomainSetup and stores them in a dictionary, so I don't do the setup again to create an application domain each time when we want to instantiate a class. This also allows me to unload.

AssemblyLoader class

This class is responsible for managing the lifetime of AppDomains.

AppDomainSetupdomainSetup=newAppDomainSetup();
domainSetup.ApplicationName=Path.GetFileNameWithoutExtension(file.Value.ToString());
domainSetup.ConfigurationFile=Path.GetFileName(file.Value.ToString())+".Config";
domainSetup.ApplicationBase=Path.GetDirectoryName(file.Value.ToString());
AppDomainappDomain=AppDomain.CreateDomain(domainSetup.ApplicationName,null,domainSetup);
_appDomains.Add(file.Key.ToString(),appDomain);
MyClassaddin=appDomain.CreateInstanceAndUnwrap(domainSetup.ApplicationName,domainSetup.ApplicationName+".MyClass")asMyClass;
_addIns.Add(file.Key,addin);

//CallingtheAddIn:
privatevoidbutton1_Click(objectsender,EventArgse){
MDLibOne.MyClassc=newMDLibOne.MyClass();
MessageBox.Show(c.ShowMessage());
AssemblyLoaderaddInLoader=newAssemblyLoader();
foreach(KeyValuePairaddIninaddInLoader.AddIns){
MessageBox.Show(addIn.Value.ShowMessage());
}
}

Wrapping Up

This example will show that it is loading from an appropriate location. But still, it has an issue that the object created has a short period. The object created with this method will soon expire and will throw an exception. The object will be timed out after some time. The lifetime will be decided by the source assembly. I am going to discuss this in my next article.