Zaki Mirza’s Blog


… About software and beyond!

Intro to Application Domains

.Net framework introduces a new concept called application domains that provides code isolation within a process enviornment. These domains contain objects/assemblies/threads that can be instantiated at runtime and unloaded at runtime. This allows for a more stable application which also providing a mechanism to load/unload plugable components without having to compromise application runtime. (or the runtime host, as these kind of applications that load other applications is called).

The AppDomain class is used to create, load and work with application domains in .Net framework. I setout to work on a project that requires loading assemblies and creating local/remote objects at runtime. These objects (also called agents..yes the DistributedComuting course project) are autonomous. they just require an execution enviornment and they will work themself. They can create threads to carry out the work they are programmed to work on. A single thread at application level is supposed to deal with these agents. These can be cloned, migrated , suspended and/or destroyed.

The problem arised when loading multi-threaded agents inside my application at runtime. An agent can create multiple threads and the runtime has no information about which threads were created by which agent. Unloading the agent normally (using the dispose function which shuts off the threads this agent created smartly) is an ideal way of doing this. (since the agent itself knows the threads it has made and can dispose them). But if there is some kind of mishap during this process (or agent falls sick, or well..anything), all threads might not get destroyed. The object will be removed from the memory leaving the poor threads confused hence comes down our application crashing. There can be ways to create a single thread for an agent at my application level and make sure that all the rest of the threads are its children and die when this thread dies/suspends etc (Thats hard to achieve and a lot of code will have to be written just to tackle this problem). Also unfortunately its not possible to create a parent/child relationship between managed (or for that matter unmanged) threads. Infact Windows does not have the facility of parent/child relationship of threads(though it does for processes. The reasons are out of scope of this page. Refer to Chapter 6 of Programming Application for Microsoft Windows by Jeffery ritcher for some internals on threading under windows.) Also, considering the suspension issue of a process, since windows does not schedule processes but it schedules threads, to suspend a procesd requires suspending all the contained threads (naive approach). In our problem, we might need to suspend a single Agent (remember agents can create multiple threads). Unless we have an architecture to do so, it will be hard to know which thread is working for which agent. One way is to create a seperate process for each agent, but the overhead of creating/destroying processes, suspending processes etc is a lot under windows though in unix enviornment that might be a feasible idea. Infact thats how its carried out in a lot of of the unix applications. Again, that might create zombie issues, issues with interprocess communication etc. But that, of course is the best alternative.). Also, in a server envionrment (atleast in windows) running applications (in our case, Agents) under a single process is more scalable.

In .Net, Application Domains solves this problem (and hence this article). MSDN introduces Application Domains as follows :

“Application domains provide a more secure and versatile unit of processing that the common language runtime can use to provide isolation between applications. You can run several application domains in a single process with the same level of isolation that would exist in separate processes, but without incurring the additional overhead of making cross-process calls or switching between processes. The ability to run multiple applications within a single process dramatically increases server scalability.”

Application domains are usually used by runtime hosts such as Internet explorer which load 3rd party plugins and addon applications within their process. IE creates application domains for each addon and when one fails, it (well…supposedly) does not bring down the whole process. (unless of course of the glitch happned in the IE core itself which is mostly the case).

Enough introduction to Application domains, lets come to the point. We need to create objects from the loaded assembly. These objects can create multiple threads and we need a way to isolate these threads from other objects’ threads within the same application so that they dont crash the application. Also we need to track which objects created which threads. So we create a seperate application domain for each of these objects. These application domains will serve the threads. We will load/unload these domains (consequently loading/unloading the objects and the threads they have created).

Starting off with the object itself,  I have a simple object that creates a thread and within that thread keeps printing which application domain it belongs to. (“Say my name!.. Say my name!!!….”). :p simple enough? He’re the code. Its not one of the best codes, but oh well bear with me.

using System;
using System.Collections.Generic;
using System.Text;
using System.Threading;

namespace ClassLibrary1
public class MyClass: MarshalByRefObject
public MyClass(){}
public void ThreadFunc()
while (true)
public void MyFunc()
Thread t = new Thread(new ThreadStart(ThreadFunc));

We compile this code to a dll called classLibrary1.dll. Now in my application ill load this dll using reflection. ill create two application domains and create two objects of this class in both application domains, shut down one application domain and we’ll see waht happens.

using System;
using ClassLibrary1;
using System.Threading;
using System.Reflection;

namespace ConsoleApplication2
class Program
static void Main(string[] args)
AppDomain appDomain1 = AppDomain.CreateDomain(“ad1”);
AppDomain appDomain2 = AppDomain.CreateDomain(“ad2”);

Assembly asm = Assembly.LoadFrom(“ClassLibrary1.dll”);
Type[] types = asm.GetTypes();

MyClass mc = (MyClass)appDomain1.CreateInstanceAndUnwrap(asm.FullName,types[0].FullName);

MyClass mc2 = (MyClass)appDomain2.CreateInstanceAndUnwrap(asm.FullName, types[1].FullName);


As you can see, the objects created within one Application domains create threads in that application domain and do not interfere with the other application domains. This is a very* simple program to show how application domains can be created and how threads work under application domains. We can improve on this furtur by creating a dictionary of objects and their application domains to keep track of which object instance is in which application domain etc. But i guess this will get you going. Ill blog soon about how to unload  faulty objects from the application without having to screw up the application itself. :p

Filed under: .net, Code, , , , ,

ASP.Net Misconfiguration Solution

Many time when creating ASP.Net Application or ASP.Net  XML Web services people get into error reports e.g. Server Application Error, Authentication error in web.config file and more. I can’t really list all the errors that lie under this solution, but most problems are rooted from this very issue. (Im not really a professional solution provider or a troubleshooter, this post happens to come from my own experience. )

The issue is about multiple versions of ASP.Net installed on you machine. For example, you were working with Visual Studio 2003 and then switched to Visual studio 2005 or vice verse. You installed .Net platform 2.0 and even 3.0., usually, is left unconfigured during this configuration and if your very unfortunate, get misconfigured. One of the major root of this problem is, when people install IIS after they install the .Net Framework, or uninstall and reinstall it. If you are having problems with ASP.Net configurations, try the following method.

To solve this problem, following the following simple steps:

navigate to you Windows installation folder. Ill assume its C:\Windows\

navigate to Microsoft.Net\Framework\[version] (depending on which version of you want with IIS.)

You will see that there are many utilities in that folder. (in my case, it is C:\Windows\Microsoft.NET\Framework\v2.0.50727). The utility that we require is aspnet_iisreg.exe. (for a more technical introduction to this utility, click here). This utility reconfigures this version of for IIS. This utility requires command line arguments. Here’s what microsoft has to say about it:

When multiple versions of ASP.NET are installed on a computer, ASP.NET is said to be running side-by-side. In this setup, Internet Information Services (IIS) needs to know which version of the ASP.NET ISAPI (aspnet_isapi.dll) should process a page in an ASP.NET application. The ASP.NET ISAPI version that is associated with an ASP.NET application determines which version of the CLR is used for the application. An ASP.NET application is associated with an ASP.NET ISAPI version using a script map in IIS. To simplify the configuration process for an ASP.NET application, each version of ASP.NET comes with a linked version of Aspnet_regiis.exe.

Goto start menu and click Run and type “cmd”. A terminal window should open. Drag this aspnet_iisreg.exe file onto the terminal window. The terminal window will now be showing this file’s name and a prompt after it. type -i after it. Basically we need to run the command “aspnet_regiis.exe -i”. This will reinstall this version of for iis. It will take some time to configure IIS.

If the above solution does not provide the adequate result, or creates any problems feel free to ask.

A very good online magazine to read for IT professionals is the microsoft TechNet. For more information about configuring versions for IIS refer to this article on TechNet. For more information about .Net Framework tools check this out.

I hope this helps some poor souls out there who are too exhausted having to post on forums and searching on google.

Filed under: .net, Troubleshooter, , , , , , , ,

Blog Stats

  • 104,198 landed here so far...
May 2017
« Jan    


Error: Twitter did not respond. Please wait a few minutes and refresh this page.

RSS Google Shared Items

  • An error has occurred; the feed is probably down. Try again later.

RSS Google Reader Starred Items

  • An error has occurred; the feed is probably down. Try again later.

Top Clicks

  • None