ApplicationShutdownReason.BuildManagerChange e ApplicationPool restart in IISExpress

Abbiamo un problema. Stiamo usando IISExpress 8.0 per l'applicazione Asp.net WebForm (.net 4.0). Comupter è in esecuzione in Windows 7 x64.ApplicationShutdownReason.BuildManagerChange e ApplicationPool restart in IISExpress

A volte senza necessità, ApplicationPool si riavvia. So che verrà riavviato dopo 15 modifiche del file aspx \ ascx. Ma in quel caso si riavvia senza modifiche. Su ApplicationEnd abbiamo trovato un motivo per questo riavvio. È ApplicationShutdownReason.BuildManagerChange.

La ricerca su Internet non fornisce dettagli utili. Per lo più tutti consiglia di utilizzare IIS anziché IISExpress.

Sapete quale potrebbe essere una ragione per questo?

UPDATE:

Scavando più in profondità Net 4 codice sorgente indica due motivi di questo arresto. Uno di questi viene attivato quando qualcuno cambia il file hash.web dalla cartella Temporary Asp.net. Ad esempio: "c: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Temporary ASP.NET Files \ app \ a83dcad1 \ be4aa699 \ hash \ hash.web"

Seconda ragione è quando BuildManager ha creato alcuni oggetti e memorizzato nella cache BuildResult in HttpCache. E se è scaduto, controlla che questo BuildResult richieda ShutdownAppDomainOnChange alla scadenza della cache. E se lo richiede, attiva l'arresto di BuildManagerChange.

UPDATE2

Nel nostro caso il riavvio è stato causato dal cambiamento hash.web. Sembra che IISExpress lo aggiorni senza alcuna modifica del codice sorgente, ma perché?

Update3 Microsoft ha un problema su di esso - https://connect.microsoft.com/VisualStudio/feedback/details/783440/microsoft-visualstudio-web-host-exe-touches-hash-web-and-should-not-be-running Dicono che è stato risolto in Visual Studio 2012 Update 2.

fonte

2013-04-02 Sergey Litvinov

Se sei su Windows 7, perché non stai utilizzando IIS in piena regola? – ashes999

Perché la configurazione di un paio di progetti Web non è così semplice su IIS. Possiamo farlo, ma poi dobbiamo fare lo stesso per ogni sviluppatore. Quindi, l'approccio con IISExpress è più semplice, perché è configurato da uno e utilizzato da tutti gli altri. –

Dalla mia esperienza, IIS Express è orribile. La configurazione che menzioni è qualcosa che tutti gli sviluppatori devono fare - non c'è un aggiramento. A lungo termine, questo costo è molto più piccolo del costo della stranezza di IisExpress. – ashes999

Questa non è una risposta completa, in modo da prendere qualunque beneficio da esso si può prendere .

Sembra che stiano succedendo due cose: la modifica di hash.web è probabilmente dovuta al fatto che IIS utilizza la posizione temporanea per archiviare la DLL dell'applicazione che è stata creata. Quando questo file cambia, IIS comprende che hai creato una nuova versione dell'applicazione e devi riavviarla; questo potrebbe spiegare il reset del pool di applicazioni.

Per la scadenza della cache, sembra che IIS stia tentando di scaricare e ricaricare qualcosa in un dominio di app diverso. Non c'è modo (in. NET) per scaricare un assembly senza scaricare un dominio app (credo) una volta che è stato caricato, quindi questo è il "solito" modo per raggiungere questo obiettivo.

Forse.

fonte

2013-04-15 13:32:27 ashes999

Sì. A partire da .Net 4.0 esiste un modo per scaricare l'assembly, ma ha alcuni spigoli. Sto cercando di intercettare IISExpress con Process Monitor per verificare che cambi questo file. Ho trovato un articolo con un problema simile che Antivirus ha controllato questo file e questo riavvio attivato. Quindi, sto indagando per l'iniziatore di questo cambiamento –

ApplicationShutdownReason.BuildManagerChange e ApplicationPool restart in IISExpress

risposta

Problemi correlati