Como evitar um reinício aplicação ASP.NET quando o web.config é modificado?

Question

Eu estou hospedando o tempo de execução ASP.NET através do método ApplicationHost.CreateApplicationHost. Quando eu modificar o web.config enquanto o aplicativo é executado, eu vejo um monte de primeiros ThreadAbortExceptions acaso jogados. Esta é reto diante de minha aplicação desaba. Estou assumindo que este é porque o tempo de execução detectou alterações na configuração e quer reiniciar.

Isto não é realmente um cenário com suporte para nós, então eu preferiria se eu pudesse desligar a recarga automática.

Alguém sabe como fazer isso?

Answer 1

Tanto quanto eu estou ciente não há nenhuma maneira para desativar esse comportamento, muda para a força webconfig o aplicativo seja reiniciado.

Update: é realmente possível, há uma série de métodos, bem documentados, como explicou nesta resposta *

resposta Original:

Há uma pergunta semelhante aqui apenas para outra referência. Eu encontrei informações adicionais que podem ser úteis.

alterações de configuração causar uma Restart do domínio da aplicação
Muda para definições de configuração no Web.config arquivos indiretamente causa a aplicação domínio para reiniciar. Esse comportamento ocorre por design. Você pode, opcionalmente, usar o atributo configSource para referência a arquivos de configuração externos que não causam uma reinicialização quando um alteração é feita. Para maiores informações, veja Atributos configSource em Geral Herdada pela Seção Elements.

A partir Este MSDN artigo

* ^{Disclaimer: Eu escrevi a outra resposta e, normalmente, não iria fazer uma auto-referência, mas encontrá-lo bastante relevante para link aqui desde 8 anos após este post é realmente muito diferente: a solução é muito fácil clicando através do IIS front-end, e existem soluções alternativas desde ASP.NET 1.0.}

Answer 2

Na verdade, as duas primeiras respostas estão incorretas. É é possível e muito fácil, para evitar essa reciclagem de acontecer, e esse recurso está disponível desde, pelo menos IIS6.

Método 1 (sistema de largura)

Alterar a definição de registo DWORD para HKLM\SOFTWARE\Wow6432Node\Microsoft\ASP.NET\FCNMode ao valor 1, que irá desativar todas notificações de alteração de arquivo.

Não pode ser confundido pela localização:. Wow6432Node tem, neste caso, qualquer influência sobre o número de bits do seu aplicativo web

Método 2 (.NET 4.5 +)

Se você estiver usando .NET 4.5, então agora é possível desativar isso em uma por site nível , basta usar o seguinte em seu web.config:

<httpRuntime fcnMode="Disabled"/> 

Método 3 (IIS6 +)

Por fim, e também (pelo menos) em torno desde IIS6, há uma configuração chamada DisallowRotationOnConfigChange como cenário para apenas o pool de aplicativos (pelo menos é o que eu acho que o texto na MSDN tenta dizer, mas eu não testei). Configurá-lo para true e muda para a configuração do pool de aplicativos não irá resultar em uma reciclagem imediata.

Esta última configuração pode também ser ajustado de Configurações Avançadas do pool de aplicativos:

Método 4 (ASP.NET 1.0 e 1.1)

Para (idade) sites usando ASP.NET 1.0 ou 1.1, há um bug confirmado que pode causar recicla rápidas e repetidas em alterações de arquivo. A solução na época era semelhante ao que MartinHN sugeriu sob a questão principal, ou seja, algo como o seguinte em sua web.config:

<compilation 
   debug="false"
   defaultLanguage="vb"
   numRecompilesBeforeAppRestart="5000">

Isto não desactiva a reciclagem, mas fá-lo apenas depois de 5000 recompilações ter ocorrido. Se este número é útil depende do tamanho de sua aplicação. A Microsoft não diz claramente o que um recompilação realmente é. O padrão, no entanto, é 15 .

Como um aparte: , independentemente da versão do .NET ou Windows, descobrimos que quando a aplicação é executada em um compartilhamento e usado em um ambiente com balanceamento de carga, que o site recicla continuamente. A única maneira de resolver isso foi adicionando essa configuração FNCMode ao registro (mas agora existem mais opções de grão fino).

Answer 3

Eu corri para um problema ainda maior ao longo das mesmas linhas - muda para qualquer arquivo ou sub-pasta na pasta de base AppDomain causa o ambiente de hospedagem para o desligamento. Este é um muito grande problema para a nossa aplicação, como nós estamos correndo um UI WPF no mesmo AppDomain e não podemos reiniciá-lo sem ser distruptive para o usuário.

Eu realmente queria evitar ter que executar um AppDomain separado para a parte web do aplicativo, então eu fiz alguma escavação com refletor. Descobri que o culpado foi o FileChangesMonitor classe interna.

Então, eu escrevi um hack horrível reflexão horrível para resolver o problema. Eu pensei que eu ia postar aqui como uma solução potencial para qualquer outra pessoa com o mesmo problema. Você só precisa HttpInternals.StopFileMonitoring() chamada para desativar desligamento no arquivo / pasta alterações.

internal static class HttpInternals
{
    private static readonly FieldInfo s_TheRuntime = typeof(HttpRuntime).GetField("_theRuntime", BindingFlags.NonPublic | BindingFlags.Static);

    private static readonly FieldInfo s_FileChangesMonitor = typeof(HttpRuntime).GetField("_fcm", BindingFlags.NonPublic | BindingFlags.Instance);
    private static readonly MethodInfo s_FileChangesMonitorStop = s_FileChangesMonitor.FieldType.GetMethod("Stop", BindingFlags.NonPublic | BindingFlags.Instance);

    private static object HttpRuntime
    {
        get
        {
            return s_TheRuntime.GetValue(null);
        }
    }

    private static object FileChangesMonitor
    {
        get
        {
            return s_FileChangesMonitor.GetValue(HttpRuntime);
        }
    }

    public static void StopFileMonitoring()
    {
        s_FileChangesMonitorStop.Invoke(FileChangesMonitor, null);
    }
}

Answer 4

Uma solução seria acrescentar seguinte elemento à seção web.config:

<httpRuntime
    waitChangeNotification="315360000"
    maxWaitChangeNotification="315360000"
/>

Answer 5

Como mencionado por jfburdet a solução é para usar waitChangeNotification e maxWaitChangeNotification.

Dito isto, você deve saber que eles não funcionam no IIS 7 se ASP.NET é executado no modo misto: http://forums.iis.net/t/1149344.aspx