Configuração avançada do Módulo ASP.NET Core e do IIS

Este artigo aborda as opções e cenários de configuração avançados para o Módulo ASP.NET Core e o IIS.

Modificar o tamanho da pilha

Aplica-se somente ao usar o modelo de hospedagem em processo.

Configure o tamanho da pilha gerenciada usando a configuração stackSize em bytes no arquivo web.config. O tamanho padrão é de 1.048.576 bytes (1 MB). O exemplo a seguir altera o tamanho da pilha para 2 MB (2.097.152 bytes):

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="stackSize" value="2097152" />
  </handlerSettings>
</aspNetCore>

Não permitir rotação na configuração

A configuração disallowRotationOnConfigChange destina-se a cenários azul/verde, em que uma alteração na configuração global não deve fazer com que todos os sites sejam reciclados. Quando esse sinalizador for true, somente as alterações relevantes para o próprio site farão com que ele seja reciclado. Por exemplo, um site é reciclado se seu web.config for alterado ou algo relevante para o caminho do site for alterado da perspectiva do IIS. Porém, uma alteração geral em noapplicationHost.config não provocaria a reciclagem de um aplicativo. O exemplo a seguir define essa configuração como true:

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="disallowRotationOnConfigChange" value="true" />
  </handlerSettings>
</aspNetCore>

Essa configuração corresponde à API ApplicationPoolRecycling.DisallowRotationOnConfigChange

Reduzir a probabilidade de 503 durante a reciclagem do aplicativo

Por padrão, há um atraso de um segundo entre o momento em que o IIS é notificado de uma reciclagem ou desligamento e o momento em que o ANCM informa ao servidor gerenciado para iniciar o desligamento. O atraso é configurável por meio da variável de ambiente ANCM_shutdownDelay ou definindo a configuração do manipulador de shutdownDelay. Ambos os valores estão em milissegundos. O atraso é principalmente para reduzir a probabilidade de uma corrida em que:

• O IIS não começou a enfileirar solicitações para o novo aplicativo.
• O ANCM começa a rejeitar novas solicitações que entram no aplicativo antigo.

Essa configuração não significa que as solicitações de entrada serão atrasadas por esse valor. A configuração indica que a instância de aplicativo antiga começará a ser desligada após a ocorrência do tempo limite. Os computadores mais lentos ou com maior uso da CPU talvez precisem ajustar esse valor para reduzir a probabilidade de 503.

O exemplo a seguir define o atraso para cinco segundos:

<aspNetCore processPath="dotnet"
    arguments=".\MyApp.dll"
    stdoutLogEnabled="false"
    stdoutLogFile="\\?\%home%\LogFiles\stdout"
    hostingModel="inprocess">
  <handlerSettings>
    <handlerSetting name="shutdownDelay" value="5000" />
  </handlerSettings>
</aspNetCore>

A configuração de proxy usa o protocolo HTTP e um token de emparelhamento

Só se aplica à hospedagem de fora do processo.

O proxy criado entre o módulo ASP.NET Core e o Kestrel usa o protocolo HTTP. Não há nenhum risco de interceptação do tráfego entre o módulo e o Kestrel em um local fora do servidor.

Um token de emparelhamento é usado para assegurar que as solicitações recebidas pelo Kestrel foram transmitidas por proxy pelo IIS e que não são provenientes de outra origem. O token de emparelhamento é criado e definido em uma variável de ambiente (ASPNETCORE_TOKEN) pelo módulo. O token de emparelhamento também é definido em um cabeçalho (MS-ASPNETCORE-TOKEN) em cada solicitação com proxy. O Middleware do IIS verifica cada solicitação recebida para confirmar se o valor de cabeçalho do token de emparelhamento corresponde ao valor da variável de ambiente. Se os valores do token forem incompatíveis, a solicitação será registrada em log e rejeitada. A variável de ambiente do token de emparelhamento e o tráfego entre o módulo e o Kestrel não são acessíveis em um local fora do servidor. Sem saber o valor do token de emparelhamento, um invasor cibernético não pode enviar solicitações que ignoram a verificação no Middleware do IIS.

Módulo do ASP.NET Core com uma configuração do IIS compartilhada

O instalador do módulo do ASP.NET Core é executado com os privilégios da conta TrustedInstaller. Como a conta do sistema local não tem permissão de modificação para o caminho de compartilhamento usado pela Configuração Compartilhada do IIS, o instalador lança um erro de acesso negado ao tentar definir as configurações do módulo no arquivo applicationHost.config no compartilhamento.

Ao usar uma configuração compartilhada de IIS no mesmo computador que a instalação do IIS, execute o instalador do pacote de hospedagem do ASP.NET Core com o parâmetro OPT_NO_SHARED_CONFIG_CHECK definido como 1:

dotnet-hosting-{VERSION}.exe OPT_NO_SHARED_CONFIG_CHECK=1

Quando o caminho para a configuração compartilhada não está no mesmo computador que a instalação do IIS, siga estas etapas:

1. Desabilite a configuração compartilhada de IIS.
2. Execute o instalador.
3. Exporte o arquivo applicationHost.config atualizado para o compartilhamento de arquivos.
4. Reabilite a Configuração Compartilhada do IIS.

Proteção de dados

A pilha Proteção de Dados do ASP.NET Core é usada por vários middlewares ASP.NET Core, incluindo aqueles usados na autenticação. Mesmo se as APIs de proteção de dados não forem chamadas pelo código do usuário, a proteção de dados deverá ser configurada com um script de implantação ou no código do usuário para criar um repositório de chaves criptográfico persistente. Se a proteção de dados não estiver configurada, as chaves serão mantidas na memória e descartadas quando o aplicativo for reiniciado.

Se o token de autenticação da Proteção de Dados estiver armazenado na memória quando o aplicativo for reiniciado:

• Todos os tokens de autenticação baseados em cookie serão invalidados.
• Os usuários precisam entrar novamente na próxima solicitação deles.
• Todos os dados protegidos com o token de autenticação não poderão mais ser descriptografados. Isso pode incluir os tokens CSRF e cookies TempData do MVC do ASP.NET Core.

Para configurar a proteção de dados no IIS para persistir o token de autenticação, use uma das seguintes abordagens:

• Criar chaves de registro de proteção de dados

  As chaves de Proteção de Dados usadas pelos aplicativos ASP.NET Core são armazenadas no registro fora dos aplicativos. Para manter as chaves de um determinado aplicativo, crie uma chave de registro para o pool de aplicativos.

  Para instalações autônomas do IIS não Web Farm, você pode usar o script Provision-AutoGenKeys.ps1 de Proteção de Dados do PowerShell para cada pool de aplicativos usado com um aplicativo ASP.NET Core. Esse script cria uma chave do Registro no registro HKLM, acessível apenas na conta do processo de trabalho do pool de aplicativos do aplicativo. As chaves são criptografadas em rest usando a DPAPI com uma chave para todo o computador.

  Em cenários de Web farm, um aplicativo pode ser configurado para usar um caminho UNC para armazenar seu token de autenticação de Proteção de Dados. Por padrão, as chaves não são criptografadas. Verifique se as permissões de arquivo para o compartilhamento de rede estão limitadas à conta do Windows em que o aplicativo é executado. Um certificado X509 pode ser usado para proteger chaves em rest. Considere um mecanismo para permitir aos usuários carregar certificados. coloque os certificados no repositório de certificados confiáveis do usuário e certifique-se de que eles estejam disponíveis em todos os computadores nos quais o aplicativo do usuário é executado. Para obter mais informações, confira Configurar a Proteção de Dados do ASP.NET Core.

• Configurar o pool de aplicativos do IIS para carregar o perfil do usuário

  Essa configuração está na seção Modelo de processo nas Configurações avançadas do pool de aplicativos. Defina Carregar Perfil do Usuário como True. Quando definido como True, as chaves são armazenadas no diretório do perfil do usuário e protegidas usando DPAPI com uma chave específica para a conta de usuário. As chaves são persistidas para a pasta %LOCALAPPDATA%/ASP.NET/DataProtection-Keys.

  O atributo setProfileEnvironment do pool de aplicativos também deve estar habilitado. O valor padrão de setProfileEnvironment é true. Em alguns cenários (por exemplo, um SO Windows), setProfileEnvironment é definido como false. Se as chaves não estiverem armazenadas no diretório do perfil do usuário como esperado:

  1. Navegue para a pasta %windir%/system32/inetsrv/config.
  2. Abra o arquivo applicationHost.config.
  3. Localize o elemento <system.applicationHost><applicationPools><applicationPoolDefaults><processModel>.
  4. Confirme se o atributo setProfileEnvironment não está presente, que tem como padrão o valor true, ou defina explicitamente o valor do atributo como true.

• Usar o sistema de arquivos como um repositório de tokens de autenticação

  Ajuste o código do aplicativo para usar o sistema de arquivos como um repositório de tokens de autenticação. Use um certificado X509 para proteger o token de autenticação e verifique se ele é um certificado confiável. Se o certificado for autoassinado, você deverá colocá-lo no repositório Raiz confiável.

  Ao usar o IIS em uma web farm:

  • Use um compartilhamento de arquivos que pode ser acessado por todos os computadores.
  • Implante um certificado X509 em cada computador. Configurar a Proteção de Dados no código.

• Definir uma política para todo o computador para Proteção de Dados

  O sistema de Proteção de Dados tem suporte limitado para a configuração da política de todo o computador padrão para todos os aplicativos que consomem as APIs de Proteção de Dados. Para obter mais informações, consulte Visão geral da Proteção de Dados do ASP.NET Core.

Configuração do IIS

Sistemas operacionais do Windows Server

Habilite a função Servidor Web (IIS) e estabeleça serviços de função.

1. Use o assistente Adicionar Funções e Recursos por meio do menu Gerenciar ou do link no Gerenciador do Servidor. Na etapa Funções de Servidor, marque a caixa de Servidor Web (IIS).

   

2. Após a etapa Recursos, a etapa Serviços de função é carregada para o servidor Web (IIS). Selecione os serviços de função do IIS desejados ou aceite os serviços de função padrão fornecidos.

   

   Autenticação do Windows (opcional)
   Para habilitar a Autenticação do Windows, expanda os nós a seguir: Servidor Web>Segurança. Selecione o recurso Autenticação do Windows. Saiba mais em Autenticação do Windows <windowsAuthentication> e Configurar autenticação do Windows.

   WebSockets (opcional)
   O WebSockets é compatível com o ASP.NET Core 1.1 ou posterior. Para habilitar o WebSockets, expanda os nós a seguir: Servidor Web>Desenvolvimento de Aplicativos. Selecione o recurso Protocolo WebSocket. Para obter mais informações, consulte WebSockets.

3. Continue para a etapa Confirmação para instalar os serviços e a função de servidor Web. Um comando server/IIS restart não será necessário após a instalação da função Servidor Web (IIS).

Sistemas operacionais Windows de área de trabalho

Habilite o Console de Gerenciamento do IIS e os Serviços na World Wide Web.

1. Navegue para Painel de Controle>Programas>Programas e Recursos>Ativar ou desativar recursos do Windows (lado esquerdo da tela).

2. Abra o nó Serviços de Informações da Internet. Abra o nó Ferramentas de Gerenciamento da Web.

3. Marque a caixa de Console de Gerenciamento do IIS.

4. Marque a caixa de Serviços na World Wide Web.

5. Aceite os recursos padrão dos Serviços na World Wide Web ou personalize os recursos do IIS.

   Autenticação do Windows (opcional)
   Para habilitar a Autenticação do Windows, expanda os nós a seguir: Serviços World Wide Web>Segurança. Selecione o recurso Autenticação do Windows. Saiba mais em Autenticação do Windows <windowsAuthentication> e Configurar autenticação do Windows.

   WebSockets (opcional)
   O WebSockets é compatível com o ASP.NET Core 1.1 ou posterior. Para habilitar o WebSockets, expanda os nós a seguir: Serviços World Wide Web>Recursos de Desenvolvimento de Aplicativos. Selecione o recurso Protocolo WebSocket. Para obter mais informações, consulte WebSockets.

6. Se a instalação do IIS exigir uma reinicialização, reinicie o sistema.

Diretórios virtuais

Diretórios virtuais IIS não são compatíveis com aplicativos ASP.NET Core. Um aplicativo pode ser hospedado como um subaplicativo.

Subaplicativos

Um aplicativo ASP.NET Core pode ser hospedado como um subaplicativo IIS (sub-app). A parte do caminho do subaplicativo se torna parte da URL raiz do aplicativo.

Os links de ativos estáticos no subaplicativo devem usar a notação de barra til (~/) no MVC e no Razor Pages. A notação de sinal de til e barra aciona um Auxiliar de Marca para preceder a base de caminho do subaplicativo ao link relativo renderizado. Para um subaplicativo no /subapp_path, uma imagem vinculada com src="~/image.png" é renderizada como src="/subapp_path/image.png". O Middleware de Arquivo Estático do aplicativo raiz não processa a solicitação de arquivo estático. A solicitação é processada pelo Middleware de Arquivo Estático do subaplicativo.

Observação

Razor componentes (.razor) não devem usar a notação de barra til. Para obter mais informações, consulte a Blazordocumentação do caminho base do aplicativo.

Se um atributo de ativo estático src for definido como um caminho absoluto (por exemplo, src="/image.png"), o link será renderizado sem a base de caminho do subaplicativo. O Middleware de Arquivos Estáticos do aplicativo raiz tenta fornecer o ativo do webroot da raiz do aplicativo, que resulta em uma resposta 404 – Não encontrado, a menos que o ativo estático esteja disponível no aplicativo raiz.

Para hospedar um aplicativo ASP.NET Core como um subaplicativo em outro aplicativo do ASP.NET Core:

1. Estabeleça um pool de aplicativos para o subaplicativo. Defina a versão do CLR do .NET como Sem Código Gerenciado porque o Core Common Language Runtime (CoreCLR) do .NET Core é inicializado para hospedar o aplicativo no processo de trabalho, não no CLR de Área de trabalho (CLR do .NET).

2. Adicione o site raiz no Gerenciador do IIS com o subaplicativo em uma pasta no site raiz.

3. Clique com o botão direito do mouse na pasta do subaplicativo no Gerenciador do IIS e selecione Converter em aplicativo.

4. Na caixa de diálogo Adicionar Aplicativo, use o botão Selecionar no Pool de Aplicativos para atribuir o pool de aplicativos que você criou ao subaplicativo. Selecione OK.

A atribuição de um pool de aplicativos separado para o subaplicativo é um requisito ao usar o modelo de hospedagem em processo.

Para obter mais informações sobre o modelo de hospedagem em processo e como configurar o módulo do ASP.NET Core, confira Módulo do ASP.NET Core para IIS.

Pools de aplicativos

O isolamento do pool de aplicativos é determinado pelo modelo de hospedagem:

• Hospedagem em processo: os aplicativos precisam ser executados em pools de aplicativos separados.
• Hospedagem fora do processo: é recomendável isolar os aplicativos uns dos outros, executando cada aplicativo no próprio pool de aplicativos.

A caixa de diálogo Adicionar Site do IIS usa como padrão um único pool de aplicativos por aplicativo. Quando um Nome de site é fornecido, o texto é transferido automaticamente para a caixa de texto Pool de aplicativos. Um novo pool de aplicativos é criado usando o nome do site quando você adicionar o site.

Pools de aplicativos Identity

Uma conta de identity do pool de aplicativos permite executar um aplicativo em uma conta exclusiva sem a necessidade de criar e gerenciar domínios ou contas locais. No IIS 8.0 ou posterior, o WAS (Processo de trabalho do administrador) do IIS cria uma conta virtual com o nome do novo pool de aplicativos e executa os processos de trabalho do pool de aplicativos nesta conta por padrão. No Console de Gerenciamento do IIS em Configurações Avançadas para o pool de aplicativos, verifique se Identity está definida para usar ApplicationPoolIdentity:

O processo de gerenciamento do IIS cria um identificador seguro com o nome do pool de aplicativos no Sistema de segurança do Windows. Os recursos podem ser protegidos usando essa identity. No entanto, essa identity não é uma conta de usuário real e não será mostrada no console de gerenciamento de usuários do Windows.

Se o processo de trabalho do IIS requerer acesso elevado ao aplicativo, modifique a ACL (lista de controle de acesso) do diretório que contém o aplicativo:

1. Abra o Windows Explorer e navegue para o diretório.

2. Clique com o botão direito do mouse no diretório e selecione Propriedades.

3. Na guia Segurança, selecione o botão Editar e, em seguida, no botão Adicionar.

4. Clique no botão Locais e verifique se o sistema está selecionado.

5. Insira o formato IIS AppPool\{APP POOL NAME}, em que o espaço reservado {APP POOL NAME} é o nome do pool de aplicativos, na área Insirerir os nomes de objeto para selecionar. Selecione o botão Verificar Nomes. Para o DefaultAppPool, verifique os nomes usando IIS AppPool\DefaultAppPool. Quando o botão Verificar Nomes é selecionado, um valor de DefaultAppPool é indicado na área de nomes de objeto. Não é possível inserir o nome do pool de aplicativos diretamente na área de nomes de objeto. Use o formato IIS AppPool\{APP POOL NAME}, em que o espaço reservado {APP POOL NAME} é o nome do pool de aplicativos, ao verificar o nome do objeto.

   

6. Selecione OK.

   

7. As permissões de leitura e execução devem ser concedidas por padrão. Forneça permissões adicionais conforme necessário.

O acesso também pode ser concedido por meio de um prompt de comando usando a ferramenta ICACLS. Usando DefaultAppPool como exemplo, o comando a seguir é usado para conceder permissões de leitura e execução para a pasta MyWebApp, subpastas e arquivos:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool:(OI)(CI)RX"

Para saber mais, veja o tópico icacls.

Suporte do HTTP/2

O HTTP/2 é compatível com ASP.NET Core nos seguintes cenários de implantação de IIS:

• Em processo
  • Windows Server 2016/Windows 10 ou posterior; IIS 10 ou posterior
  • Conexão TLS 1.2 ou posterior
• Fora do processo
  • Windows Server 2016/Windows 10 ou posterior; IIS 10 ou posterior
  • Conexões de servidor de borda voltadas para o público usam HTTP/2, mas a conexão de proxy reverso para o servidor Kestrel usa HTTP/1.1.
  • Conexão TLS 1.2 ou posterior

Para uma implantação em processo quando uma conexão HTTP/2 for estabelecida, o HttpRequest.Protocol relatará HTTP/2. Para uma implantação fora do processo quando uma conexão HTTP/2 for estabelecida, o HttpRequest.Protocol relatará HTTP/1.1.

Para saber mais sobre os modelos de hospedagem dentro e fora do processo, consulte Módulo do ASP.NET Core (ANCM) para IIS.

O HTTP/2 está habilitado por padrão. As conexões retornarão para HTTP/1.1 se uma conexão HTTP/2 não for estabelecida. Para obter mais informações sobre a configuração de HTTP/2 com implantações do IIS, consulte HTTP/2 no IIS.

Solicitações de simulação do CORS

Esta seção só se aplica a aplicativos ASP.NET Core com o .NET Framework como destino.

Para um aplicativo ASP.NET Core com o .NET Framework como destino, as solicitações OPTIONS não são passadas para o aplicativo por padrão no IIS. Confira como configurar os manipuladores IIS do aplicativo no web.config para passar as solicitações OPTIONS em Habilitar solicitações entre origens na ASP.NET Web API 2: como o CORS funciona.

Módulo de Inicialização de Aplicativo e Tempo Limite de Ociosidade

Quando hospedado no IIS pela versão 2 do Módulo do ASP.NET Core:

• Módulo de Inicialização de Aplicativo: aplicativos hospedados em processo ou fora do processo podem ser configurados para iniciar automaticamente em uma reinicialização do servidor ou do processo de trabalho.
• Tempo Limite Ocioso: aplicativos hospedados em processo podem ser configurados para não atingir o tempo limite durante períodos de inatividade.

Módulo de Inicialização de Aplicativo

Aplica-se a aplicativos hospedados em processo e fora de processo.

Inicialização de Aplicativo IIS é um recurso do IIS que envia uma solicitação HTTP para o aplicativo quando o pool de aplicativos é iniciado ou reciclado. A solicitação dispara a inicialização do aplicativo. Por padrão, o IIS emite uma solicitação para a URL raiz do aplicativo (/) para inicializar o aplicativo (confira mais detalhes sobre a configuração nos recursos adicionais).

Confirme se o recurso da função Inicialização de Aplicativo do IIS está habilitado:

No Windows 7 ou sistemas de área de trabalho posteriores, ao usar o IIS localmente:

1. Navegue até Painel de Controle>Programas>Programas e Recursos>Ativar ou desativar recursos do Windows (lado esquerdo da tela).
2. Abra Serviços de Informações da Internet>Serviços da World Wide Web>Recursos de Desenvolvimento de Aplicativos.
3. Marque a caixa de seleção Inicialização de Aplicativo.

No Windows Server 2008 R2 ou posterior:

1. Abra o Assistente de Adição de Funções e Recursos.
2. No painel Selecionar serviços de função, abra o nó Desenvolvimento de aplicativos.
3. Marque a caixa de seleção Inicialização de Aplicativo.

Use quaisquer das abordagens a seguir para habilitar o Módulo de Inicialização do Aplicativo para o site:

• Usando o Gerenciador do IIS:

  1. Selecione Pools de Aplicativos no painel Conexões.
  2. Clique com o botão direito do mouse no pool de aplicativos do aplicativo na lista e selecione Configurações Avançadas.
  3. O Modo de Inicialização padrão é OnDemand. Defina o Modo de Inicialização como AlwaysRunning. Selecione OK.
  4. Abra o nó Sites no painel Conexões.
  5. Clique com o botão direito do mouse no aplicativo e selecione Gerenciar Site>Configurações Avançadas.
  6. A configuração de Pré-carregamento Habilitado padrão é False. Defina Pré-carregamento Habilitado como True. Selecione OK.

• Usando web.config, adicione o elemento <applicationInitialization> com doAppInitAfterRestart definido como true nos elementos <system.webServer> no arquivo web.config do aplicativo:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <applicationInitialization doAppInitAfterRestart="true" />
      </system.webServer>
    </location>
  </configuration>
  

Tempo limite de ociosidade

Só se aplica a aplicativos hospedados em processo.

Para impedir que o aplicativo fique ocioso, defina o tempo limite de ociosidade do pool de aplicativos, usando o Gerenciador do IIS:

1. Selecione Pools de Aplicativos no painel Conexões.
2. Clique com o botão direito do mouse no pool de aplicativos do aplicativo na lista e selecione Configurações Avançadas.
3. O Tempo Limite de Ociosidade (minutos) é de 20 minutos. Defina o Tempo Limite de Ociosidade (minutos) como 0 (zero). Selecione OK.
4. Recicle o processo de trabalho.

Para impedir que aplicativos hospedados fora de processo atinjam o tempo limite, use uma das seguintes abordagens:

• Execute ping do aplicativo de um serviço externo para mantê-lo em execução.
• Se o aplicativo hospedar apenas serviços em segundo plano, evite a hospedagem do IIS e use um Serviço do Windows para hospedar o aplicativo ASP.NET Core.

Recursos adicionais do Módulo de Inicialização de Aplicativo e do Tempo Limite de Ociosidade

• Inicialização de Aplicativo do IIS 8.0
• Inicialização de Aplicativo <applicationInitialization>.
• Configurações de modelo de processo para um pool de aplicativos <processModel>.

Locais dos arquivos de módulo, de esquema e de configuração

Módulo

IIS (x86/amd64):

• %windir%\System32\inetsrv\aspnetcore.dll

• %windir%\SysWOW64\inetsrv\aspnetcore.dll

• %ProgramFiles%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll

• %ProgramFiles(x86)%\IIS\Asp.Net Core Module\V2\aspnetcorev2.dll

IIS Express (x86/amd64):

• %ProgramFiles%\IIS Express\aspnetcore.dll

• %ProgramFiles(x86)%\IIS Express\aspnetcore.dll

• %ProgramFiles%\IIS Express\Asp.Net Core Module\V2\aspnetcorev2.dll

• %ProgramFiles(x86)%\IIS Express\Asp.Net Core Module\V2\aspnetcorev2.dll

Esquema

IIS

• %windir%\System32\inetsrv\config\schema\aspnetcore_schema.xml

• %windir%\System32\inetsrv\config\schema\aspnetcore_schema_v2.xml

IIS Express

• %ProgramFiles%\IIS Express\config\schema\aspnetcore_schema.xml

• %ProgramFiles%\IIS Express\config\schema\aspnetcore_schema_v2.xml

Configuração

IIS

• %windir%\System32\inetsrv\config\applicationHost.config

IIS Express

• Visual Studio: {APPLICATION ROOT}\.vs\config\applicationHost.config

• CLI do iisexpress.exe: %USERPROFILE%\Documents\IISExpress\config\applicationhost.config

Os arquivos podem ser encontrados pesquisando aspnetcore no arquivo applicationHost.config.

Instalar a Implantação da Web durante a publicação com o Visual Studio

Ao implantar aplicativos para servidores com Implantação da Web, instale a versão mais recente da Implantação da Web no servidor. Para instalar a Implantação da Web, consulte Downloads do IIS: implantação da Web.

Criar o site do IIS

1. No sistema de hospedagem, crie uma pasta para conter arquivos e pastas publicados do aplicativo. Em uma etapa a seguir, o caminho da pasta é fornecido ao IIS como o caminho físico para o aplicativo. Para obter mais informações sobre o layout de arquivo e a pasta de implantação de um aplicativo, confira Estrutura de diretório do ASP.NET Core.

2. No Gerenciador do IIS, abra o nó do servidor no painel Conexões. Clique com botão direito do mouse na pasta Sites. Selecione Adicionar Site no menu contextual.

3. Forneça um Nome do site e defina o Caminho físico como a pasta de implantação do aplicativo. Forneça a configuração Associação e crie o site ao selecionar OK:

   

   Aviso

   Associações de curinga de nível superior (http://*:80/ e http://+:80) não devem ser usadas. Associações de curinga de nível superior podem abrir o aplicativo para vulnerabilidades de segurança. Isso se aplica a curingas fortes e fracos. Use nomes de host explícitos em vez de curingas. Associações de curinga de subdomínio (por exemplo, *.mysub.com) não têm esse risco de segurança se você controlar o domínio pai completo (em vez de *.com, o qual é vulnerável). Confira RFC 9110: Semântica HTTP (Seção 7.2: Host e :authority) para obter mais informações.

4. No nó do servidor, selecione Pools de Aplicativos.

5. Clique com o botão direito do mouse no pool de aplicativos do site e selecione Configurações Básicas no menu contextual.

6. Na janela Editar Pool de Aplicativos, defina a versão do CLR do .NET como Sem Código Gerenciado:

   

   O ASP.NET Core é executado em um processo separado e gerencia o runtime. O ASP.NET Core não depende do carregamento do CLR de área de trabalho (CLR do .NET). O Core Common Language Runtime (CoreCLR) para o .NET Core é inicializado para hospedar o aplicativo no processo de trabalho. Definir a versão do CLR do .NET como Sem Código Gerenciado é opcional, porém recomendado.

   • Para uma implantação autossuficiente de 32 bits (x86) publicada com um SDK de 32 bits que usa o modelo de hospedagem em processo, habilite o Pool de Aplicativos para 32 bits. No Gerenciador do IIS, navegue até Pools de Aplicativos na barra lateral Conexões. Selecione o Pool de Aplicativos do aplicativo. Na barra lateral Ações, selecione Configurações Avançadas. Defina Habilitar Aplicativos de 32 bits como True.

   • Para uma implantação autossuficiente de 64 bits (x64) que usa o modelo de hospedagem em processo, desabilite o pool de aplicativos para processos de 32 bits (x86). No Gerenciador do IIS, navegue até Pools de Aplicativos na barra lateral Conexões. Selecione o Pool de Aplicativos do aplicativo. Na barra lateral Ações, selecione Configurações Avançadas. Defina Habilitar Aplicativos de 32 bits como False.

7. Confirme se a identity do modelo de processo tem as permissões apropriadas.

   Se você alterar a identity padrão do pool de aplicativos (modelo de processo>Identity) em ApplicationPoolIdentity para outra identity, verifique se a nova identity tem as permissões necessárias para acessar a pasta do aplicativo, o banco de dados e outros recursos necessários. Por exemplo, o pool de aplicativos requer acesso de leitura e gravação às pastas nas quais o aplicativo lê e grava os arquivos.

Configuração de Autenticação do Windows (opcional)
Para saber mais, veja Configurar a Autenticação do Windows.

Cópia de sombra

A cópia de sombra dos assemblies de aplicativo para o ANCM (Módulo Principal do ASP.NET) para IIS podem fornecer uma melhor experiência do usuário final do que a interrupção do aplicativo com a implantação de um arquivo offline do aplicativo.

Quando um aplicativo ASP.NET Core está em execução no Windows, os binários são bloqueados para que não possam ser modificados ou substituídos. A cópia de sombra permite que os assemblies de aplicativo sejam atualizados enquanto o aplicativo está em execução fazendo uma cópia dos assemblies.

A cópia de sombra não se destina a habilitar a implantação de tempo de inatividade zero, portanto, é esperado que o IIS ainda recicle o aplicativo, e algumas solicitações poderão obter uma resposta 503 Serviço Indisponível. É recomendável usar um padrão como implantações azul-verde ou slots de implantação do Azure para implantações de tempo de inatividade zero. A cópia de sombra ajuda a minimizar o tempo de inatividade nas implantações, mas não pode eliminá-lo completamente.

A cópia de sombra é habilitada personalizando as configurações do manipulador ANCM no web.config:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="aspNetCore"/>
      <add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified"/>
    </handlers>
    <aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".logsstdout">
      <handlerSettings>
        <handlerSetting name="enableShadowCopy" value="true" />
        <!-- Ensure that the IIS ApplicationPool identity has permission to this directory -->
        <handlerSetting name="shadowCopyDirectory" value="../ShadowCopyDirectory/" />
      </handlerSettings>
    </aspNetCore>
  </system.webServer>
</configuration>