Application vs. AppDomain

A question was asked on a forum that I frequent which I thought was worth writting a blog about.

Q: What is the difference between an application and an Appdomain?  I understand from my research so far that an Appdomain is a container within which ASPX runs and that Apppool is a process that starts the w3wp.exe worker process within which ASP applications run.

A: That's a good question.  Here are some key differences:

  • An application is an IIS term, but it's one that ASP.NET utilizes.  Essentially it creates a sandbox, or a set of boundaries to separate different sites, or parts of sites, from the others.
  • An AppDomain is a .NET term.  (In IIS7, AppDomains play a larger role within IIS, but for the most part it's an ASP.NET term)
  • An AppDomain contains InProc session state (the default session state mode).  So if an AppDomain is killed/recycled, all of your session state information will be lost. (if you are using the default InProc session state)
  • Applications can have multiple AppDomains in them although often times there is a one-to-one relationship between them.
  • In IIS6 and greater, there is the option of creating groups, or "pools" of applications that can be bundled together or separated; however the server administer decides.  These are called Application Pools.  Each app pool runs under its own w3wp.exe worker process. 
  • In IIS, it's easy to see an application.  A new website is a separate application and any subfolder can be marked as an application.  When they are, the icon beside the folder turnes 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 app pool they live under.
  • ASP.NET, on the other hand, doesn't 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.
  • You can recycle an application from IIS.  In IIS5, you can't 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.
  • You can recycle an AppDomain in ASP.NET through the 'touch trick'.  There are a few ways to do it, but the most straight forward 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.
  • Recycling an AppDomain will come pretty close to starting ASP.NET fresh again for that particular ASP.NET application, so although it doesn't recycle the apppool, it can give ASP.NET a fresh start in many situations.

25 Comments

  • In what cases are recycling the appDomain useful? When would you want to do this?

  • Hi Kelly,

    In a perfect world, nothing should be recycled unless a change is made. But, since it's not a perfect world, occasionally something breaks or doesn't work as expected and a recycle will give it a fresh start, causing it to work again. There have been certain bugs and situations over time that only a recycle of the app pool or AppDomain would fix it, and sometimes uploading new code changes will cause failures.

    For example, if a site is uploaded via FTP, key files could be uploaded last but before they are loaded, the site may try to run and cache an error. So, a recycle will cause everything to be loaded fresh again.

    Basically, you'll know. "If it ain't broke, don't fix it." But if it is broken, there are times when an AppDomain recycle is what is needed to get it working again.

  • Thanks Scott. I guess my real question is, when would you want to do an appdomain recycle, over an app pool recycle? When we make changes at our company, we do a an app pool recycle in order to copy in the new files. Doing it this way helps us to not affect the other websites on the servers as you would with an IISReset. I was just wondering if an appdomain recycle would be useful to us and an even lesser affect on our customers?

  • Hi Kelly. Ok, I see where you're coming from.

    If you only have a single site in your app pool, then an app pool and an AppDomain recycle will be quite similar. The app pool recycle will recycle the entire w3wp.exe process while the AppDomain will recycle the .NET AppDomain only, but since most of what that needs to be recycled lives in the AppDomain, they will achieve the same thing. It's just a matter of which is easier for you to do. But, if the AppDomain 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 AppDomain 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/AppDomain in the app pool.

  • Hi Scott，I have a question, How to make one Application with multiple AppDomains? thx

  • Hi Joe. For the most part you don't need to worry about that unless you have a specific reason to have separate AppDomains during development. It's very rare to need to create a separate AppDomain apart from what .NET already creates for you.

    Generally you can mark folders as applications and put them in a new or existing app pool. Each folder that is marked as an application is its own AppDomain.

    Not sure if that answers your question.

  • Scott, Thanks for your answer, it's what I want to know.

  • Hi Scott,

    we're doing a decent amount of caching on our Windows Azure hosted website. We use HttpContext.Cache and one of our requirement is to manually remove/expire some objects from the cache. We wrote some code to forward expiration requests to other Azure web instances, but i'm trying to find a way to clear the HttpContext.Cache across AppDomains. I read that HttpContext.Cache is linked to an appdomain and that IIS may create multiple appdomain for a given site; so I wonder if there's an easy way from one appdomain to fetch all other running appdomains for the current site and somehow trigger to custom operation on them.

    I know it's a bit off-subject in regard to your (very informative) blog post, but i was thinking you may know the answer off hand :)

    Thank you!

  • Hi Scott, I am just reading Pro ASP.NET CSharp 4.0 and i am bit confused. As far as my understanding goes, there can be anywhere between 1 to 100 AppDomains in an AppPool for single Web Application.

    Please tell if i am wrong ??

  • Hi Pankaj,

    It's possible to have multiple AppDomain's per application if the developer specifically programs it, but it's rare. It takes specific programming to do so. Generally there is just one per application boundary.

    What does Pro ASP.NET CSharp 4.0 say about multiple appdomains per application?

  • Hi Scott,
    How ApplicationDomains will get created in IIS? How to configure them?

  • Hi Bhavagna,

    They are mostly hidden, and they are specific to .NET. For the most part there is one AppDomain created automatically with each Application. Only if a programmer specifically creates an AppDomain would there be more.

  • Great writeup Scott--I appreciate it. It helped clarify several things for me. I am reading a .Net book and I wanted to share some information. Many people were asking about creating new ApplicationDomains. Technically any time you change a file in the virtual folder, ASP.NET will create a new Application Domain. The new one will handle all future requests while the existing application domain will stay alive long enough to finish handling any oustanding requests, including queued requests. So really you would not need to create any manually. If you already have several, then you probably have oustanding requests still being handled, or you are constantly updating your files.

    @Pankaj -- I read something similar to what you are asking. Maybe you are thinking of the Application class in ASP.NET. Basically ASP.NET will create a pool of Application objects when the application domain is first loaded. Then each incoming request will be served by one of those objects, before the object is returned to the pool to be reused. The number of objects/instances of the Application class typically ranges from 1 - 100 depending on the system and threads available.

    Hope that helps

  • Thanks Rob, great comments!

  • Info was very useful! Thanks

  • Hi Scott,
    I get a good understanding after reading this blog but Stiil I have some point to clear

    1)How many worker process could be in application pool.
    2)Is All the application in pull taget to the Same Wprkerprocess.

  • Hi Rahul,

    1) By default there is one worker process per app pool but you can change that in the app pool settings. Generally I recommend against changing it though: http://weblogs.asp.net/owscott/archive/2011/06/13/why-you-shouldn-t-use-web-gardens-in-iis-week-24.aspx

    2) If you have just have 1 worker process per app pool (default) then all appdomains will be in that one worker process. If you have web gardens enabled (more than 1 worker process per app pool) then there will be multiple copies of each appdomain within the multiple application pools.

  • Hi Scott,
    Your point gave very valuble thing. In one place i want to have some more clarification. You told that in case of web garden the multiple copies of appdomain will be availble for multiple apppool. I think it should be like muliple copies of appdomain will be available for each worker process within single app pool for that particular web garden. If i am wrong, forgive me. Also if you explain more about web garden with multiple app domain

  • Hi Jegadeesh,

    Thanks for the clarification. I believe that you are correct but I'm not positive that I understand correctly. I'll try to word it another way, which will hopefully confirm what you're thinking.

    If you are using web gardens for a particular application pool, then multiple worker processes (w3wp.exe) will be started for that application pool. Within each worker process, at least 1 AppDomain will be started. And, if you have folders marked as applications then there can be more than 1 AppDomain per worker process.

    And of course, if you have multiple sites, then there will be even more worker processes and AppDomains created.

  • Hi Scott,

    we use IIS6, windows 2003, Asp.net 4.0 with Ncache out-of-proc Session. We use multiple worker processes for 1 application pool.

    We have a unique issue in that sometimes 2 consecutive request from the same user hits different worker process and asp.net loads new app domain. In this specific case, the session values saved from 1st request (wp1- app domain 1) cannot be read from the 2nd request handled by wp2-app domain 2?

    The unique sessionID is generated by combining SiteID + 120bit random number. Do you know if MS includes App domain ID as well to generate SessionID which could cause this issue.

    or any other pointers would be great.

    Thanks,

    Gopi

  • Hi Gopi,

    For that question I would recommend contacting Alachisoft as they have probably worked through that already. It's dependent on how they determine if a session is for an existing request or if it's a new request.

    I'm not sure what the sessionId looks like in that context but even if it includes the AppDomain the session must be able to be determined by NCache because AppDomains are different between web servers too. I doubt the AppDomain is being used by NCache to determine session uniqueness. Something else is probably coming into play.

    As a side, I've never been a fan of web gardens. There is a time and place for it, but it's rare. Here's a video where I cover my reasons: http://weblogs.asp.net/owscott/archive/2011/06/13/why-you-shouldn-t-use-web-gardens-in-iis-week-24.aspx

  • ok, we are already in contact with MS Tech Support, will let u know how it turns out!

    SessionID is generated by Asp.Net process and handed over to Alachisoft! so they (already said!) nothing to do with current issue, and i'm positive it is not there issue as well.. will see.

    For the Web Garden setup, it is a huge plus for us, we have 24cpu / machine, using 1 Worker process doesn't scale well! (just 180 users) With 12 WP we now have 600 concurrent user / machine!

    Thx

  • IIS should use all CPUs unless you set CPU affinity, so even with a single worker process you can fully utilize a web server. However, there are exceptions, like if there is a blocking process. It sounds like the web garden is working well for you, in which case there's no need to change.

  • It turns out, Alachisoft has a SessionLockout property, which is set to false default, setting it to true fixed our issue!

    For the multi WP issue, during a Memory dump, we found that using 1 WP has 2GB address space limitation (not sure why it is happening in win2k 64 bit enterprise edition) which is causing frequent high GC's.

    Moving to multiple WP, each has its own 2GB space so that fixed our scaling issue.

  • Hi Gopi,

    Interesting situation. Glad to see that you got a good solution, and a valid reason to use web gardens. Thanks for the update.

Comments have been disabled for this content.