What is it?
The Application Domain, known as AppDomain, provides a sandbox for .NET applications. An AppDomain is a container, or secure boundary, for code and data used by the .NET runtime. It is analogous to an operating system process used for an application and its data. The code and data is securely isolated within the boundaries of an AppDomain.
The goal of an AppDomain is to isolate the applications within it from all other application domains. That is, applications are protected from being affected by other applications running in different application domains. It provides stability.
This isolation of AppDomains is achieved by making sure exactly one application occupies unique parts of memory and scopes the resources for the process or application domain using that address space. The .NET runtime enforces AppDomain isolation by controlling memory usage. Application domains run on a single Win32 process. All AppDomain memory is managed by the runtime to ensure no overlap in memory usage.
It may seem like there is one AppDomain for every application, but the .NET Common Language Runtime (CLR) allows multiple applications to run within a single AppDomain. The CLR also verifies that the user code in an AppDomain is type safe. An assembly must be loaded into an AppDomain before it can execute. By default, the CLR loads an assembly into the AppDomain containing the code that references it.
The CLR automatically creates a default AppDomain when a process that hosts the CLR is created. This default AppDomain exists as long as the host process is alive. A good example of hosting the CLR is IIS.
ASP.NET
When a request first enters an ASP.NET application, the IIS-managed engine module creates an application domain; then the application domain performs the necessary processing tasks for the application, such as authentication.
When dealing with multiple ASP.NET applications on a server, the ASP.NET worker process will host all of them, but each one will have its own. This ensures that each application is protected from problems in another application. In addition, each application has its own set of global variables. Even though the code for both of the applications resides inside the same process, the unit of isolation is the .NET AppDomain.
An interesting caveat with ASP.NET and application domains is the fact that ASP.NET applications run with full trust rights by default. Applications running with full trust can execute native code and circumvent all security checks by the .NET runtime, so the security boundary provided by the application domain is moot. You can override the default behavior and run applications with partial trust to overcome this issue.
It is easy to see the benefits of the AppDomain concept, as applications are protected from harming others. It is great for ASP.NET hosting providers to protect customer applications from each other. In addition, the .NET Framework provides programmatic access to the application domain concept.
Programmatic access
AppDomain class is in the base System namespace. The Microsoft documentation offers the following guidelines for using the AppDomain class:
* Use application domains to isolate tasks that might bring down a process. If the state of the AppDomain that’s executing a task becomes unstable, the AppDomain can be unloaded without affecting the process. This is important when a process must run for long periods without restarting. You can also use application domains to isolate tasks that should not share data.
* If an assembly is loaded into the default application domain, it cannot be unloaded from memory while the process is running. However, if you open a second application domain to load and execute the assembly, the assembly is unloaded when that application domain is unloaded. Use this technique to minimize the working set of long-running processes that occasionally use large DLLs.
The AppDomain class allows you to create and manipulate your own application domains based upon your needs. The CreateDomain method is available to create a new application domain. The following C# snippet creates a new application domain and executes an assembly within the new application domain.
AppDomain domain = AppDomain.CreateDomain("TestAppDomain");
domain.ExecuteAssembly("AssemblyName.exe", null, args);
Console.WriteLine(AppDomain.CurrentDomain.FriendlyName);
In addition to creating a new application domain, the AppDomain class provides methods and properties for working with new and existing application domains.
This comprehensive list of online samples show you how to work with the current application domain and interact with other application domains.
Protection
Application domains are an essential feature of the .NET platform because they isolate applications from each other; this prevents problems in one application from affecting others running on the same platform. In addition, the AppDomain class allows you to create your own application domains to isolate tasks for various reasons.
The Application Domain, known as AppDomain, provides a sandbox for .NET applications. An AppDomain is a container, or secure boundary, for code and data used by the .NET runtime. It is analogous to an operating system process used for an application and its data. The code and data is securely isolated within the boundaries of an AppDomain.
The goal of an AppDomain is to isolate the applications within it from all other application domains. That is, applications are protected from being affected by other applications running in different application domains. It provides stability.
This isolation of AppDomains is achieved by making sure exactly one application occupies unique parts of memory and scopes the resources for the process or application domain using that address space. The .NET runtime enforces AppDomain isolation by controlling memory usage. Application domains run on a single Win32 process. All AppDomain memory is managed by the runtime to ensure no overlap in memory usage.
It may seem like there is one AppDomain for every application, but the .NET Common Language Runtime (CLR) allows multiple applications to run within a single AppDomain. The CLR also verifies that the user code in an AppDomain is type safe. An assembly must be loaded into an AppDomain before it can execute. By default, the CLR loads an assembly into the AppDomain containing the code that references it.
The CLR automatically creates a default AppDomain when a process that hosts the CLR is created. This default AppDomain exists as long as the host process is alive. A good example of hosting the CLR is IIS.
ASP.NET
When a request first enters an ASP.NET application, the IIS-managed engine module creates an application domain; then the application domain performs the necessary processing tasks for the application, such as authentication.
When dealing with multiple ASP.NET applications on a server, the ASP.NET worker process will host all of them, but each one will have its own. This ensures that each application is protected from problems in another application. In addition, each application has its own set of global variables. Even though the code for both of the applications resides inside the same process, the unit of isolation is the .NET AppDomain.
An interesting caveat with ASP.NET and application domains is the fact that ASP.NET applications run with full trust rights by default. Applications running with full trust can execute native code and circumvent all security checks by the .NET runtime, so the security boundary provided by the application domain is moot. You can override the default behavior and run applications with partial trust to overcome this issue.
It is easy to see the benefits of the AppDomain concept, as applications are protected from harming others. It is great for ASP.NET hosting providers to protect customer applications from each other. In addition, the .NET Framework provides programmatic access to the application domain concept.
Programmatic access
AppDomain class is in the base System namespace. The Microsoft documentation offers the following guidelines for using the AppDomain class:
* Use application domains to isolate tasks that might bring down a process. If the state of the AppDomain that’s executing a task becomes unstable, the AppDomain can be unloaded without affecting the process. This is important when a process must run for long periods without restarting. You can also use application domains to isolate tasks that should not share data.
* If an assembly is loaded into the default application domain, it cannot be unloaded from memory while the process is running. However, if you open a second application domain to load and execute the assembly, the assembly is unloaded when that application domain is unloaded. Use this technique to minimize the working set of long-running processes that occasionally use large DLLs.
The AppDomain class allows you to create and manipulate your own application domains based upon your needs. The CreateDomain method is available to create a new application domain. The following C# snippet creates a new application domain and executes an assembly within the new application domain.
AppDomain domain = AppDomain.CreateDomain("TestAppDomain");
domain.ExecuteAssembly("AssemblyName.exe", null, args);
Console.WriteLine(AppDomain.CurrentDomain.FriendlyName);
In addition to creating a new application domain, the AppDomain class provides methods and properties for working with new and existing application domains.
This comprehensive list of online samples show you how to work with the current application domain and interact with other application domains.
Protection
Application domains are an essential feature of the .NET platform because they isolate applications from each other; this prevents problems in one application from affecting others running on the same platform. In addition, the AppDomain class allows you to create your own application domains to isolate tasks for various reasons.
Post a Comment