Process Basics:
- There will be at least one thread executing instructions inside of the process, and in most cases there are multiple threads. If the program opens any files or other resources, those resources will belong to the process.
- aspnet_wp.exe is the ASP.NET worker process which hosts all the ASP.NET applications on Windows XP and Windows 2000, this process runs under the security context of the local ASPNET account
- w3wp.exe is the process runs under the NETWORK SERVICE account by default on Windows 2003 and Vista.
Why AppDomain?
- More efficient: Application domains are more efficient than processes, enabling multiple assemblies to be run in separate application domains without the overhead of launching separate processes.
- More reliable: Use application domains to isolate tasks that might cause a process to terminate. If the state of the application domain that’s executing a task becomes unstable, the application domain can be unloaded without affecting the process. This technique is important when a process must run for long periods without restarting.
- Unload assembly: If an assembly is loaded into the default application domain, the assembly 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 dynamic-link libraries (DLLs).
AppDomain Basics:
- The .NET runtime uses an AppDomain as a container for code and data, just like the operating system uses a process as a container for code and data.
- Application domain is not a secure boundary when the application runs with full trust. Applications running with full trust can execute native code and circumvent all security checks by the .NET runtime. ASP.NET applications run with full trust by default.
- An AppDomain is a great solution for the ISP who is hosting hundreds of applications. Each application can exist inside an isolated AppDomain, and many of these AppDomains can exist inside of a single process – a cost savings.
- In order to communicate or pass objects between AppDomains, you’ll need to look at techniques in .NET for communication across boundaries, such as .NET remoting or web services.
- If you copy an updated dll into an application’s bin subdirectory, the ASP.NET runtime recognizes there is new code to execute. Since ASP.NET cannot swap the dll into the existing AppDomain , it starts a new AppDomain. The old application domain is “drain stopped”, that is, existing requests are allowed to finish executing, and once they are all finished the AppDomain can unload. The new AppDomain starts with the new code and begins taking all new requests.
- Not only can you isolate entire applications from each other, but you can also isolate individual parts (assemblies) from the rest of your application.
- The runtime host usually determines when and if additional application domains are created. Runtime hosts are free to use different application domain strategies to suit their application execution model and security requirements.
- Application isolation ensures that one application cannot purposefully or inadvertently modify the memory, or access the resources owned by another.
Shadow Copies:
- Typically, when a dll loads into a process, the process locks the dll and you cannot overwrite the file on disk. However, AppDomains have a feature known as Shadow Copy that allows assemblies to remain unlocked and replaceable on disk.
- The runtime initializes ASP.NET with Shadow Copy enabled for the bin directory. The AppDomain will copy any dll it needs from the bin directory to a temporary location before locking and loading the dll into memory. Shadow Copy allows us to overwrite any dll in the bin directory during an update without taking the web application offline.
In summary:
- AppDomain is more efficient than process
- A single process can have many AppDomains
- An AppDomain can execute many assemblies
- An AppDomain cannot unload an assembly, you can create another AppDomain to load the assembly and after finish executing the assembly, you can unload the AppDomain in order to unload the assembly
- A change to the bin folder will cause the application to restart because the AppDomain cannot unload an assembly, so the AppDomain has to be unloaded first, then re-loaded to pick up the new assembly
- When create a IIS web application, you create an application domain for it.
- IIS web applications cannot share session objects because objects cannot be shared between AppDomains.
What ASP.NET Programmers Should Know About Application Domains
