Scott Forsyth's Blog

Postings on IIS, ASP.NET, SQL Server, Webfarms and general system admin.

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.
Posted: Sep 02 2007, 07:21 AM by OWScott | with 7 comment(s)
Filed under:

Comments

Jason Haley said:

# September 3, 2007 10:51 AM

Kelly said:

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

# September 4, 2007 6:09 PM

OWScott said:

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.

# September 4, 2007 9:55 PM

Kelly said:

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?

# September 5, 2007 9:57 AM

Scott Forsyth said:

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.

# September 5, 2007 10:09 AM

Kelly said:

Thanks Scott!

# September 5, 2007 6:22 PM

Danni Afasyah said:

I've come to a case, where, in my application, i need to load the assembly dynamically. Its not a

# September 6, 2007 4:08 AM