WeakReference: GC knows the Best
New* .NET 3.5 Feature: AddIn Framework ( Part 1 of 2 )

Dll heaven: Executing multiple versions of the same assembly

Everyone wants their application to be backward compatible and if the application is based on a plug-in based architecture then such a feature can be a nice addition. When can such a feature be useful? Suppose we have a plug-in subsystem which we have upgraded to newer plug-in system and we want to support older systems.

So if we want to load 2 different versions of a same assembly what do we need to do?First, each version needs to be loaded into 2 different AppDomains.

Why ?

Because when an assembly is loaded it cannot be unloaded so if we have 2 different assemblies once a type has been loaded from one of them, it will be reused each time we want to instantiate a type. But an assembly loaded into an AppDomain can be unloaded by unloading the AppDomain itself. I am going to demonstrate how to load 2 versions of the same assembly into same executable and run them simultaneously.

Example Step 1: In order to make it simple and avoid the reflection trouble I am going to create an interface and put it into a dll and reference the interface to the concrete dll. So here is code for the interface class in a simple dll that will be used to invoke methods.

namespace InterfaceLib
    public interface IExecute
        string Execute();

Example Step 2:I will build this into a single dll and then reference it to the interface. We need to make the class inherit from MarshalByRefObject since we want to communicate across AppDomains.

namespace AssemblyVersionTest
    public class SimpleClass : MarshalByRefObject,
        public string Execute()
            return "This is executed from version 1";

So we have a class that is referenced from MarshalByRefObject and implement our interface. Lets compile this dll and after doing so ... take the dll and rename it to AssemblyVersionTest1.dll

Lets now change this line

return "This is executed from version 1;


return "This is executed from version 2";

Then again compile the dll and rename it to AssemblyVersionTest2dll

Example Step 3:Now we come to our third application, the console executable. Lets put the 2 versions of the dll to the bin path of the console executable and use the following code

// Create an app domain
AppDomain appDomain1 = AppDomain.CreateDomain("Version1");
// Instantiate the object from the app doamin and the first version file
object obj= appDomain1.CreateInstanceFromAndUnwrap(
    AppDomain.CurrentDomain.BaseDirectory + "\\AssemblyVersionTest1.dll",
IExecute iex = (IExecute)obj;

// Instantiate the object from the app doamin and the second version file
AppDomain appDomain2 = AppDomain.CreateDomain("Version2");
object obj2 = appDomain2.CreateInstanceFromAndUnwrap(
    AppDomain.CurrentDomain.BaseDirectory + "\\AssemblyVersionTest2.dll",
IExecute iex2 = (IExecute)obj2;


Now observe that we have had renamed the different versions of the dlls and loaded them explicitly. The output of the above code should be ...

This is executed from version 1
This is executed from version 2

Now we can see that the domains have loaded 2 different versions of the same class in the same executable and executed them.

kick it on DotNetKicks.com



DLL Heaven? lol- nice title.
This is a nice blog entry but I was wondering that in real life the name of the assemblies also remain same only the build version will be different.
But in this example the assemblies has got different names, in that case do we really need to use another application domain? if the dlls names and namespaces are different then it is possible to load into the same domain. but if every thing is same only the build version is different then we need to use different application domain. Shiplu bhai correct me if I am wrong.
another thing, you blog now made me think about another problem. If really someday I have to write some kind of plugin based system, and consider the base could be a class rather than an interface, in such scenario how can we do this? I think this is a good thing I can do some brain storming....Shiplu bhai, let me know if you have any ready-made suggestions for this.
Anyway, good post !

Shafqat Ahmed

Actually the objective of the post is to show how to load different versions of the same assembly. The plugins are mantioned here so that I can show a prospective usage.

Now to answer your question, I must point out that cross app domain communication must be done either via remoting or via serialization. Here we are using remoting ... since serialization would not work with same class and thus load from the executing appdomain. You can test this by adding serializable and removing the MarshalByRef.

So if your base object is Marshaled I do not see why it cannot be done. Also if the plugin's access to the system is also done via a predefined interface that did not change or the change was only done by creating addtional interfaces like com then it should be simple and effective.
Usually plugins are provided with partial internal object model and if that model is provided via seperate interface assembly then it should be extensible. If the root is the executing domain and is marshalled then the plugin domain should work.

Kazi Manzur Rashid

Shiplu Bhai, It is really nice to see that someone is blogging the internals of .NET framework. Very helpful tip.

Shafqat Ahmed

Thank you very much for reading.


Very helpful article. Thanks.

The comments to this entry are closed.