Load, Use and the Unload an Assembly at runtime

Question

4.33/5 (5 votes)

See more:

Hi,

I am working on a project where I have to load assemblies (lets call them tasks) at runtime, run the task and then be able to kill off the whole assembly so that the dll can be replaced without interupting the main application.

There are many of these tasks running within the main application, some run sequentially and some run in parallel. Occasionally one or to of these tasks need to be updated and then re-added to the queue. Currently we are stopping the entire application and interupting the other tasks at whatever stage they are at, which is not ideal.

I have figured out that I will have to load each assembly into a seperate AppDomain, but loading the assemblies in those domains is proving difficult, especially when I need to actually run the tasks and receive events from them. I have been looking into this problem for a couple of days and have still not managed to get a working proof-of-concept.

I have an Interface for the tasks which includes a 'run' and 'kill' method (subs) and a 'taskstep', 'complete' and 'killed' event. 'taskstep' returns an object to be cached later, 'complete' fires when the whole task is done and 'killed' fires when it is ready to be unloaded. There should also be a timeout on the whole process of two hours and a timeout of 2 minutes on the killed event incase it gets stuck, at which point I would like to be able to unload it, forcing any threads to terminate (which is what 'kill' should do anyway). Each assembly may contain several tasks, all of which should loadable be unloadable.

I have no problems loading these tasks as 'plugins' but am lost when trying to both use them and unload them. If I have to create some elaborate wrapper then so be it but is what I need even possible?

(PS. I wish I could do this in c# but I have been told that VB is preferable. If it is only possible in c# then all the better for me, but not so much for my boss ^_^)

Many thanks
Andy

Posted 1-Dec-11 0:54am

Andy Lanng

Add a Solution

Comments

Sergey Alexandrovich Kryukov 1-Dec-11 14:23pm

This is an interesting bunch of problems, my 5 for the question. I got considerable experience working with such things, some of it shared in my solution, please see.
--SA

BillWoodruff 1-Dec-11 22:01pm

+5 for your Excellent question ! A quite possibly dumb question: isn't this type of dynamic loading, execution, and unloading that MEF is designed for ? I once tried using the multiple-AppDomain based technique of loading "plug-ins:" getting objects passed back and forth between the main app and the plug-ins drove me nuts. Trying to give the plug-in access to, and freedom to change, some big data structure in the main app was what caused me to abandon ship on AppDomains.

5 solutions

Solution 2

Using COM objects for this is a very interesting solution and is part of the windows os for quite some time. You can create in process or out of process. Using Excel in an application is an example of usage of out of process (although Excel is not the best example because it is an interactive process and in that way not suitable for server applications). But the idea is about the same. You can request a COM object which will be loaded into memory by the COM server and can then be used. In your case you start a task. You can use an event sink for receiving events and when you are done you can simply discard it. The COM Object will stay in the pool for a while and after some time it is also discarded from memory. The COM server keeps it in a pool for a while just in case you need another quite soon. This means that you don't need to worry about it yourself. But why use this? Well, the most interesting part might be that you can also use transactions. Meaning that you can, for example, make a file delete object. You start a new transaction, create 3 file delete com objects for 3 different files and then commit. The 3 files are then only deleted if all 3 can be deleted. If one cannot be deleted, the transaction will fail and none of the files is deleted. Another nice feature is DCOM which makes it possible to create a COM object that is on another system. Even these objects can be part of a transaction giving you great control of the whole operation. It might be interesting enough to investigate.

http://msdn.microsoft.com/en-us/library/aa645736%28v=vs.71%29.aspx[^]

Good luck!

Posted 1-Dec-11 1:23am

E.F. Nijboer

Comments

Andy Lanng 1-Dec-11 7:49am

That sounds like a very interesting possability. I will try solution 1 first as I am more familiar with loading assemblies, but failing that I will try the DCOM thing. ^_^

Solution 3

Hello,

Have you looked at using reflection?

I few years ago, I had to load and use assemblies that were changing at runtime.

This is how I did it:

string pathToAssembly = Path.Combine(Application.StartupPath, "myAssemby.dll");
object[] parameters = null;
Assembly assembly = Assembly.LoadFile(pathToAssembly);
Type type = assembly.GetType("MyAssembly.Form1");
MethodInfo methodInfo = type.GetMethod("ShowDialog", Type.EmptyTypes);
object instance = Activator.CreateInstance(type);

methodInfo.Invoke(instance, parameters);

Valery.

Posted 1-Dec-11 1:31am

Valery Possoz

Comments

Andy Lanng 1-Dec-11 7:46am

Thanks for your solution but it doesn't entirely apply to the specifics of my problem

Solution 5

I provided detailed answers to close questions in near past. Please see:

Create WPF Application that uses Reloadable Plugins...[^],
AppDomain refuses to load an assembly[^],
code generating using CodeDom[^].

—SA

Posted 1-Dec-11 8:21am

Sergey Alexandrovich Kryukov

Updated 1-Dec-11 8:22am

v2

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Rob Philpott · Accepted Answer · 2011-12-01T01:19:00

I've done this sort of thing before a few times. As you say, the only way to unload an assembly is to ditch the whole appdomain it's in. The trick comes because appdomains are isolated from each other (the very purpose) so you need to marshall the data to and from them.

The exact way I've done this I'm struggling to remember, but you'll need to create a host class in each domain and make it inherit from MarshalByRefObject. In your calling (main) domain a proxy is created which mimics this. So this object needs to contain all the methods and things you need to communicate with the domain. Stick those in an interface shared by all domains.

Each domain can have its own seperate base folder containing the assemblies or can have them explicitly loaded. By pointing it at a folder to do resolution though helps with loading dependencies.

Mehdi Gholam · Accepted Answer · 2011-12-01T02:33:00

Solution 4

The best method if your assemblies are not very large (which will not be the case for plugins etc.) is to do the following :

C#

byte[] b = File.ReadAllBytes(filename);
Assembly a= Assembly.Load(b);
// cache the assembly if needed here

This will not lock your DLL files, and no marshaling is required.

Posted 1-Dec-11 2:33am

Mehdi Gholam

Updated 1-Dec-11 2:36am

v2

Comments

Andy Lanng 1-Dec-11 10:21am

I have been experimenting with this method and it works very well. I will try to combine it with solution 1 as I will still need to unload the assemblies from time to time or I will end up with a whole load of unused assemblies in the main appdomain. Thanks guys. I'll credit the answers when I get a prototype running

Barış Halıcı 3-Mar-21 3:58am

thanks, it helped me a lot

Load, Use and the Unload an Assembly at runtime

5 solutions

Solution 1

Solution 2

Solution 3

Solution 4

Solution 5

Add your solution here

Preview 0

Existing Members

...or Join us