ApplicationShutdownReason.BuildManagerChange and ApplicationPool restart in IISExpress

Question

We have a problem. We are using IISExpress 8.0 for Asp.net WebForm application(.net 4.0). Comupter is running under Windows 7 x64.

Sometimes without any reason ApplicationPool restarts. I know that it will restart after 15 aspx\ascx file changes. But in that case it restarts without any changes. On ApplicationEnd we found a reason of this restart. It's ApplicationShutdownReason.BuildManagerChange.

Search in the Internet won't give anything usefull details. Mostly all recomends to use IIS instead of IISExpress.

Do you know what could be a reason for it?

UPDATE:

Digging deeper into .Net 4 source code give two reasons of this shutdown. One of them is triggered when someone changed hash.web file from Temporary Asp.net folder. For example - "c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\app\a83dcad1\be4aa699\hash\hash.web"

Second reason is when BuildManager built some object and cached BuildResult in HttpCache. And then if it's expired it checks that this BuildResult require ShutdownAppDomainOnChange on cache expiration. And if it's require it, then it triggers BuildManagerChange shutdown.

UPDATE2

In our case restart was caused by hash.web change. Seems IISExpress updates it without any source code change, but why?

UPDATE3 Microsoft has an issue about it - https://connect.microsoft.com/VisualStudio/feedback/details/783440/microsoft-visualstudio-web-host-exe-touches-hash-web-and-should-not-be-running They say that they fixed it in Visual Studio 2012 Update 2.

Answer 1

This is not a full answer, so take whatever benefit from it you may take.

It seems like two things are happening: the hash.web change is probably because IIS uses the temporary location to store the application DLL that you build. When this file changes, IIS understands that you built a new version of the application, and need to restart it; that may explain the application pool reset.

For the cache expiration, it seems like IIS is trying to unload and reload something in a different app domain. There's no way (in .NET) to unload an assembly without unloading an app domain (I think) once it's been loaded, so this is "the usual" way to achieve this.

Maybe.