What is an application domain?
An AppDomain can be thought of as a lightweight process. Multiple AppDomains can exist inside a Win32 process. The primary purpose of the AppDomain is to isolate applications from each other, and so it is particularly useful in hosting scenarios such as ASP.NET. An AppDomain can be destroyed by the host without affecting other AppDomains in the process. Win32 processes provide isolation by having distinct memory address spaces. This is effective, but expensive. The .NET runtime enforces AppDomain isolation by keeping control over the use of memory – all memory in the AppDomain is managed by the .NET runtime, so the runtime can ensure that AppDomains do not access each other’s memory. One non-obvious use of AppDomains is for unloading types. Currently the only way to unload a .NET type is to destroy the AppDomain it is loaded into. This is particularly useful if you create and destroy types on-the-fly via reflection. Microsoft have an AppDomain FAQ.
An application domain (often AppDomain) is a virtual process that serves to isolate an application. All objects created within the same application scope (in other words, anywhere along the sequence of object activations beginning with the application entry point) are created within the same application domain. Multiple application domains can exist in a single operating system process, making them a lightweight means of application isolation.
The basic theory was that each running application was loaded into a separate process that automatically isolated each application from others. If for example, an error occurred in a single application, that wouldn’t affect the others running on the system. Essentially, a process defined a security boundary that also prevented applications from talking directly with each other. This actually worked quite well and helped to solve the perpetual tug of war that existed between scalability and fault tolerant systems. With the advent of the .NET runtime this concept was enhanced to include a new type of entity called the Application Domain.
Application domain is a construct in the CLR that is the unit of isolation for an application. The isolation guarantees the following: An application can be independently stopped. An application cannot directly access code or resources in another application. A fault in an application cannot affect other applications. Configuration information is scoped by application. This means that an application controls the location from which code is loaded and the version of the code that is loaded.
An application domain (often AppDomain) is a virtual process that serves to isolate an application. All objects created within the same application scope (in other words, anywhere along the sequence of object activations beginning with the application entry point) are created within the same application domain. Multiple application domains can exist in a single operating system process, making them a lightweight means of application isolation. An OS process provides isolation by having a distinct memory address space. While this is effective, it is also expensive, and does not scale to the numbers required for large web servers. The Common Language Runtime, on the other hand, enforces application isolation by managing the memory use of code running within the application domain. This ensures that it does not access memory outside the boundaries of the domain. It is important to note that only type-safe code can be managed in this way (the runtime cannot guarantee isolation when unsafe
Related Questions
- I have submitted a new domain registration/transfer request to SingNet. How do I know when my application has been processed?
- Under the Research Ethics approval system, what is a research domain and how does it affect my application?
- What is the meaning and application of the different domain extensions?
