Hey Friends, do know you what is an Application Domain?
If the answer of the above question in NO, then you have ended up to a right place. In case it is yes, and still, you just want to recollect what it is, please read through.
The post will start on rather a theoretical note, but we will learn its use as well as discuss some of its applications also.
So, lets understand what it is.
Microsoft defines it as follows: An Application Domain is a logical container that allows multiple assemblies to run within a single process, but prevents them from directly accessing memory that belongs to other assemblies.
Well yes and an Assembly in simple terms is a DLL or an EXE.
In a bit more detail, Process is a unit of Execution for an Operating System, but talking in case of the applications that we develop using Dotnet Framework, we need to consider the Runtime Engine of Dotnet that actually deals with its execution. Yes, the Common Language Runtime (CLR), and for CLR, the unit of Execution is an Application Domain.
So, summarizing it, we can say, that an Operating System runs a Process within it (multiple processes actually), while a Process runs one or more Application Domains within it. It can be depicted by the below image:
Advantages of Application Domains:
- Application Domains, provide a very important benefit, that of providing isolation from runtime errors and unhandled exceptions, in such a way that if one such occurs in a running application, it will not affect any other applications (until they are dependent on that particular application.)
- We can provide different security levels to different application domains, to keep the machine secure in case we are running some unknown third party assemblies in our application.
- Another very important benefit, is that of running multiple assemblies in separate app domains, without the overhead of starting multiple processes. (A really big advantage!)
- Separate Memory spaces.
- Separate access to resources.
Important Features provided by Application Domains:
- Isolate tasks that might cause a process to terminate.
- If app domain state becomes unstable unexpectedly, it can be unloaded without affecting the process
- Very useful for two kinds of applications:
(a) Which should run for very long time without getting restarted
(b) Which should not share any data with third party assemblies.
- If an assembly is loaded in the default application domain, it cannot be unloaded from memory while the process is running. But, if you run it in a child app domain, you can load and unload as and when required, without affecting the main process plus having the added advantage of freeing up the unused resources.
Ok guys, enough of theory now, lets go see how to create our own app domain, load assemblies and unload application domains in our own code.
We make use of the AppDomain Class to play with the Application domains, in our applications.
- Creating an Application Domain:
We will use a method called CreateDomain, which is a static Method to create an application domain.
AppDomain myAppDomain = AppDomain.CreateDomain("VarunDomain");
- Loading Assemblies in an Application Domain:
For this, we will make use of an instance method called ExecuteAssembly or ExecuteAssemblyByName.
- Unloading an Application Domain:
For this, we make use of a static method called Unload.
Very simple! Isn’t it?
Finally, lets look at where can this be applied:
- Say you are creating an application where you provide your users with add-ins for their custom use, then you can make use of Application Domains, to load/unload those add-ins without restarting the Main Process.
- Say you are creating a very critical Information Management Application, but want to make use of some free third party assemblies available, then you can use them by providing some particular security levels, so that they do not tamper with your critical data in any case.
There can be many more cases, as many as you want to add to the list of two here, based on your own perspective!
Happy Application Domaining! :)