views:

140

answers:

2

I am trying to better understand appDomains. From my understanding Windows runs all applications in a process. each application is encapsulated in it's own object that resides within this process. This object also holds some global varibles which can not be shared. All objects that are in the process can not share any data with one another. An appDomain from my understanding is a special object that sits in the windows process. and all it does is keep a reference to all assemblies assigned to it. If anyone could elaborate more on that or correct me if I am wrong. Also any good resources will do as well.

+2  A: 

Look into this blog.

Doc Brown
+3  A: 

It sounds like what's happening here is that you are confusing the concept of an AppDomain with the implementation in .Net.

Let's start with the concept first. You can think of it conceptually as the same kind of thing as a thread or a process. Processes are fairly expensive to start up, but provide a high degree of protection/separation between the memory owned by individual processes. Threads are fairly cheap to start up, but there is less protection against cross-thread memory access. An AppDomain essentially brings some of the process-level protections to threads.

You can do some interesting things with this concept. For example, processes are not restricted to a single AppDomain, and so you could have multiple apps sharing one process and still be fairly sure that neither app will interfere with or crash the other. But the main reason has to do with the implementation.

.Net languages, being managed, are designed with a memory model such that the manager can be sure nothing from outside your app will inappropriately interfere with your app's memory. They're also designed using a separate thread for garbage collection, and this leads us to a place where your app is running as just one thread in a process. Even if you only use one thread, you could start up more, or load additional assemblies. So then, the purpose of an AppDomain is to encapsulate your app (and it's memory) within the process. It may be implemented as a object that keeps a reference to your assemblies, but that is separate from the concept.

Joel Coehoorn