Application pool and App-domain , both of them can provide isolation's, but use different approaches. Application pool use the process to isolate the applications which works without .NET. But App-domain is another isolation methods provided by .NET. If your server host thousands of web sites, you wont use thousands of the application pool to isolate the web sites, just because, too many processes running will kill the OS. However, sometime you need application pool. One of the advantages for application pool is that you can config the identity for application pool. Also you have more flexible options to recycle the application pool. At least right now, IIS didn't provide explicit options to recycle the app-domain.If you only have a single site in your app pool, then an app pool and an App-domain recycle will be quite similar. The app pool recycle will recycle the entire w3wp.exe process while the App-domain will recycle the .NET App-domain only, but since most of what that needs to be recycled lives in the App-domain, they will achieve the same thing. It's just a matter of which is easier for you to do. But, if the App-domain recycle doesn't do the trick, then try a full app pool recycle. This will depend on your situation. If you have multiple sites in the app pool, then an App-domain is preferred because it won't touch any of the other sites or applications in the app pool and is isolated to just the single application/App-domain in the app pool.
Please see my answer below for the differences between appdomain and application pool...1. Basically, an application is an IIS term, which will create a sandbox, or a set of boundaries in order to separate different sites, or parts of sites, from the others.
2. AppDomain is a .NET term, which contains InProc session state so that if an AppDomain is killed or recycled, all of your session state information will be lost.
3. Applications can have multiple AppDomains in them, although most of the time there is a one-to-one relationship between them.
4. In IIS6 and greater, there is the option of creating groups or "pools" of applications that can be bundled together or separated, however, it will decide by server administer. These are called Application Pools. Each application pool runs under its own w3wp.exe worker process.
5. In IIS, it is easy to see an application. A new website is a separate application and any sub-folder can be marked as an application. When they are, the icon beside the folder turns into a picture of some gears. By right-clicking on the folder, you have the option of marking a folder as an application or removing it as an application, if it already is one. Also, in IIS6, in the Application Pools section, you can see all of the applications and which application pool they live under.
6. On the other hand, ASP.NET does not give much visibility into AppDomains, at least not from any visual tools. This is done behind the scenes. Programmatically, you can create them, tear them down or see a list of all running AppDomains.
7. You can recycle an application from IIS. In IIS5, you cannot do it directly unless you recycle the entire web server, but in IIS6 and greater, you can recycle the application pool that the application lives under. It will gracefully die off and a new application will start up to replace it. Or, to word it another way, another w3wp.exe worker process will be started and then the old one will die off after it completes any currently running page requests.
8. You can recycle an AppDomain in ASP.NET through the "touch trick". There are some ways to do it, but the most straightforward is to edit your web.config file in notepad and add a space to an insignificant place. Then save the file. This will cause the AppDomain to recycle. This does not touch the IIS application though.
9. Recycling an AppDomain will come pretty close to starting ASP.NET freshly again for that particular ASP.NET application, so although it does not recycle the application pool, it can give ASP.NET a fresh start in many situations.
C# Corner. All contents are copyright of their authors.