ApplicationShutdownReason.BuildManagerChange i ApplicationPool restart w IISExpress

Question

Mamy problem. Używamy IISExpress 8.0 do aplikacji Asp.net WebForm (.net 4.0). Comupter działa pod Windows 7 x64.

Czasami bez żadnego powodu ApplicationPool uruchamia się ponownie. Wiem, że uruchomi się ponownie po 15 zmianach w pliku aspx \ ascx. Ale w takim przypadku restartuje się bez żadnych zmian. Na ApplicationEnd znaleźliśmy przyczynę tego ponownego uruchomienia. Jest to ApplicationShutdownReason.BuildManagerChange.

Wyszukiwanie w Internecie nie daje żadnych użytecznych szczegółów. Głównie wszystkie polecają używać IIS zamiast IISExpress.

Czy wiesz, jaki może być tego powód?

UPDATE:

Kopiąc głębiej .Net 4 kodu źródłowego dać dwa powody tego wyłączenia. Jedna z nich jest wywoływana, gdy ktoś zmienił plik hash.web z folderu Temporary Asp.net. Na przykład - "c: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Tymczasowe pliki ASP.NET \ app \ a83dcad1 \ be4aa699 \ hash \ hash.web"

Drugi powód to sytuacja, gdy BuildManager zbudował jakiś obiekt i buforowany BuildResult w HttpCache. A jeśli wygasł, sprawdza, czy BuildResult wymaga ShutdownAppDomainOnChange na wygaśnięciu pamięci podręcznej. A jeśli jest to wymagane, uruchamia wyłączenie BuildManagerChange.

Update2

w naszym przypadku restartu została spowodowana zmianą hash.web. Wydaje się, że IISExpress aktualizuje go bez zmiany kodu źródłowego, ale dlaczego?

UPDATE3 Microsoft ma problemu o tym - https://connect.microsoft.com/VisualStudio/feedback/details/783440/microsoft-visualstudio-web-host-exe-touches-hash-web-and-should-not-be-running Mówią, że naprawił w Visual Studio 2012 Aktualizacja 2.

Answer 1

To nie jest pełna odpowiedź, więc podjąć wszelkie korzyści z niej mogą wziąć .

Wygląda na to, że dwie rzeczy się dzieją: zmiana hash.web jest prawdopodobnie spowodowana tym, że usługi IIS używają tymczasowej lokalizacji do przechowywania utworzonej biblioteki DLL aplikacji. Po zmianie tego pliku usługi IIS rozumieją, że została utworzona nowa wersja aplikacji i trzeba ją ponownie uruchomić; które mogą wyjaśniać reset puli aplikacji.

Po wygaśnięciu pamięci podręcznej wygląda na to, że program IIS próbuje zwolnić i ponownie załadować coś w innej domenie aplikacji. Nie ma sposobu (w .NET) na rozładowanie złożenia bez rozładowania domeny aplikacji (jak sądzę) po załadowaniu, więc jest to "zwyczajny" sposób na osiągnięcie tego.

Może.