When does an ASP.NET Website project recompile?

Question

As Maurico and codeka first stated, don't use the default InProc sessions if you don't want your sessions to be affected by website recompiles and application recycles.

A list of what causes whole website recompile:

1. By default, when any change is made to a top-level file in a Web site, the whole site is recompiled. Top-level files include the global.asax file and all files in the bin/ and App_Code/ folders.

2. modifying web.config

3. a configuration include file change, if the SectionInformation.RestartOnExternalChanges property is true

   <section name="MyAppSettings" type="System.Configuration.AppSettingsSection, System.Configuration, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" restartOnExternalChanges="true" requirePermission="false" />

Notes:

• If you want to be able to change top-level files without causing the whole site to be recompiled, you can set the optimizeCompilations attribute of the compilation element in the Web.config file to true

References:

• Understanding ASP.NET Dynamic Compilation

---

Where's the info that tells the kinds of changes and files which cause a website project (not web application project) to recompile itself?

The reason I'm asking is because we don't want users to lose their sessions. Therefore we want to update the live website with recompilable changes only in the very wee hours of the morning, but would prefer to make changes during the day to expedite them. We do promote to a staging server first and watch it there, but a definitive list would be nice in advance.

Answer 1

You'll lose sessions not just when your website is recompiled, but also when the IIS worker process is recycled. Technically, that can happen at any time (there are ways to minimise it, but I prefer to architect applications that can survive worker process recycles anyway), so if sessions are important then you really do need to be storing them out-of-process.

ASP.NET comes with a built-in "state server" which is just a windows service that stores session state. Another option is to use the SQL Server session state storage.

A lot of people will tell you that storing session state in SQL Server is a performance problem, but I disagree: losing sessions due to process recycles is more of a concern than the performance of SQL Server. Besidess the ASP.NET state server is faster if that's what you really need (and if you want to survive power cycles you could even write a custom provider that stores state in a NoSQL database!)