Configuração avançada do ASP.NET Core Module e do IIS

Este artigo aborda opções de configuração avançadas e cenários para o ASP.NET Core Module e o IIS.

Modificar o tamanho da pilha

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

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

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

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

A configuração disallowRotationOnConfigChange destina-se a cenários azuis/verdes em que uma alteração na configuração global não deve fazer com que todos os sites sejam reciclados. Quando este indicador for verdadeiro, apenas as alterações relevantes para o próprio site farão com que ele se recicle. Por exemplo, um site recicla se as suas web.config mudarem ou se algo mudar que seja relevante para o caminho do site sob a perspetiva do IIS. Mas uma mudança geral no applicationHost.config não faria com que um aplicativo fosse reciclado. 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

Reduza a probabilidade de ocorrência do erro 503 durante a reciclagem de aplicativos

Por padrão, há um atraso de um segundo entre o momento em que o IIS é notificado de uma reciclagem ou desligamento e o instante em que o ANCM informa o servidor gerido para iniciar o desligamento. O atraso é configurável através 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 destina-se principalmente a reduzir a probabilidade de uma corrida em que:

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

Essa configuração não significa que as solicitações recebidas serão atrasadas por esse valor. A configuração indica que a instância antiga do aplicativo começará a ser desligada após o tempo limite expirar. Máquinas mais lentas ou com uso mais pesado da CPU podem precisar ajustar esse valor para reduzir a probabilidade de 503.

O exemplo a seguir define o atraso como 5 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

Aplica-se apenas à hospedagem fora do processo.

O proxy criado entre o ASP.NET Core Module e o Kestrel usa o protocolo HTTP. Não há risco de espionar o tráfego entre o módulo e o Kestrel a partir de um local fora do servidor.

Um token de emparelhamento é usado para garantir que as solicitações recebidas por Kestrel foram intermediadas pelo IIS e não vieram de outra fonte. 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 do 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 e rejeitada. A variável de ambiente de token de emparelhamento e o tráfego entre o módulo e o Kestrel não são acessíveis fora do servidor. Sem saber o valor do token de emparelhamento, um ciberinvasor não pode enviar solicitações que ignorem a verificação no middleware do IIS.

ASP.NET módulo principal com uma configuração compartilhada do IIS

O instalador do ASP.NET Core Module é 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 do IIS na mesma máquina que a instalação do IIS, execute o instalador do ASP.NET Core Hosting Bundle 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 estiver na mesma máquina que a instalação do IIS, siga estas etapas:

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

Proteção de dados

O stack de proteção de dados do ASP.NET Core é usado por vários middlewares do ASP.NET Core, incluindo o middleware usado na autenticação. Mesmo que as APIs de proteção de dados não sejam chamadas pelo código do usuário, a proteção de dados deve ser configurada com um script de implantação ou em código de usuário para criar um armazenamento 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 porta-chaves de Proteção de Dados estiver armazenado na memória quando a aplicação for reiniciada:

• Todos os tokens de autenticação baseados em cookiesão invalidados.
• Os usuários são obrigados a entrar novamente em sua próxima solicitação.
• Quaisquer dados protegidos com o porta-chaves já não podem ser desencriptados. Isso pode incluir tokens CSRF e cookies TempData do ASP.NET Core MVC .

Para configurar a proteção de dados no IIS para manter o anel de chaves, use uma das seguintes abordagens:

• Criar chaves do Registro de Proteção de Dados

  ASP.NET chaves principais de proteção de dados usadas pelos aplicativos ASP.NET Core são armazenadas no registro externo aos aplicativos. Para persistir as chaves de um determinado aplicativo, crie chaves do Registro para o pool de aplicativos.

  Para instalações autónomas do IIS que não sejam de webfarm, o script Data Protection Provision-AutoGenKeys.ps1 PowerShell pode ser usado para cada pool de aplicativos usado com um aplicativo ASP.NET Core. Esse script cria uma chave do Registro no registro HKLM que é acessível somente à conta do processo de trabalho do pool de aplicativos do aplicativo. As chaves são encriptadas em repouso usando DPAPI com uma chave a nível de máquina.

  Em cenários de web farm, um aplicativo pode ser configurado para usar um caminho UNC para armazenar seu conjunto de chaves 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 na qual o aplicativo é executado. Um certificado X509 pode ser usado para proteger chaves em repouso. Considere um mecanismo para permitir que os usuários carreguem certificados. Coloque certificados no armazenamento de certificados confiáveis do usuário e verifique se eles estão disponíveis em todas as máquinas em que o aplicativo do usuário é executado. Para mais informações, consulte Configurar a Proteção de Dados no ASP.NET Core.

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

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

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

  1. Navegue até 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, o que padroniza o valor como trueou defina explicitamente o valor do atributo como true.

• Use o sistema de arquivos como um armazenamento de chaves

  Ajuste o código da aplicação para que use o sistema de ficheiros como um armazenamento de chaves. Use um certificado X509 para proteger o porta-chaves e garantir que o certificado seja um certificado confiável. Se o certificado for autoassinado, coloque-o na loja de certificados raiz confiável.

  Ao usar o IIS em uma web farm:

  • Use um compartilhamento de arquivos que todas as máquinas possam acessar.
  • Implante um certificado X509 em cada máquina. Configure Proteção de Dados no código.

• Estabelecer uma política para o sistema inteiro de Proteção de Dados

  O sistema de Proteção de Dados tem suporte limitado para definir uma política padrão para a máquina inteira 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 Windows Server

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

1. Use o assistente Adicionar Funções e Recursos no menu Gerenciar ou no link Gerenciador do Servidor. Na etapa Funções de Servidor, marque a caixa de seleção para 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 seguintes nós: Web Server>Security. Selecione o recurso de Autenticação do Windows. Para obter mais informações, consulte <windowsAuthentication> e Configurar autenticação do Windows.

   WebSockets (Opcional)
   WebSockets é suportado com o ASP.NET Core 1.1 ou posterior. Para habilitar WebSockets, expanda os seguintes nós: Web Server>Application Development. Selecione o recurso WebSocket Protocol. Para obter mais informações, consulte WebSockets.

3. Prossiga através da etapa de Confirmação para instalar a função de servidor Web e os serviços. Uma reinicialização do servidor/IIS não é necessária após a instalação da função Servidor Web (IIS).

sistemas operativos de ambiente de trabalho Windows

Habilite a Consola de Gestão do IIS e os Serviços de Internet (World Wide Web).

1. Navegue até 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 verificação Console de Gestão do IIS.

4. Marque a caixa de seleção para World Wide Web Services.

5. Aceite os recursos padrão para Serviços de Internet ou personalize as funcionalidades do IIS (Serviços de Informação na Internet).

   Autenticação do Windows (opcional)
   Para habilitar a Autenticação do Windows, expanda os seguintes nós: World Wide Web Services>Security. Selecione o recurso de Autenticação do Windows. Para obter mais informações, consulte <windowsAuthentication> e Configurar autenticação do Windows.

   WebSockets (Opcional)
   WebSockets é suportado com o ASP.NET Core 1.1 ou posterior. Para habilitar WebSockets, expanda os seguintes nós: World Wide Web Services>Application Development Features. Selecione o recurso WebSocket Protocol. 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 do IIS não são suportados com aplicações ASP.NET Core. Um aplicativo pode ser hospedado como um subaplicativo.

Sub-applications

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

Os links de ativos estáticos dentro do subaplicativo devem usar a notação tilde-slash (~/) em MVC e Razor Pages. A notação tilde-slash aciona um Auxiliar de Tag para prefixar a base de caminho do subaplicativo ao link relativo renderizado. Para um subaplicativo no /subapp_path, uma imagem vinculada a src="~/image.png" é renderizada como src="/subapp_path/image.png". O middleware de ficheiros estáticos na aplicação principal não processa a solicitação de ficheiros estáticos. A solicitação é processada pelo middleware de arquivos estáticos do subaplicativo.

Se o atributo src de um ativo estático 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 arquivo estático do aplicativo raiz tenta servir o ativo a partir do raiz da Webdo aplicativo raiz, o 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 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) para .NET é inicializado para hospedar o aplicativo no processo de trabalho, não o CLR da área de trabalho (.NET CLR).

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

3. Clique com o botão direito do mouse na pasta do subaplicativo no Gerenciador do IIS e selecione Converter para Aplicação.

4. Na caixa de diálogo Adicionar Aplicação , use o botão Selecionar para o Grupo de Aplicações para atribuir o grupo de aplicações que criou para o subaplicativo. Selecione OK.

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

Para obter mais informações sobre o modelo de hospedagem em processo e a configuração do ASP.NET Core Module, consulte ASP.NET Core Module (ANCM) para IIS.

Pools de Aplicações

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: recomendamos isolar os aplicativos uns dos outros executando cada aplicativo em seu próprio pool de aplicativos.

A janela de diálogo IIS Adicionar Site é definida como padrão para um único pool de aplicativos por aplicativo. Quando um nome de site é fornecido, o texto é transferido automaticamente para a caixa de texto do pool de aplicações . Um novo pool de aplicativos é criado usando o nome do site quando o site é adicionado.

Pool de aplicativos Identity

Uma conta de identidade do pool de aplicativos permite que um aplicativo seja executado em uma conta exclusiva sem precisar criar e gerenciar domínios ou contas locais. No IIS 8.0 ou posterior, o IIS Admin Worker Process (WAS) cria uma conta virtual com o nome do novo pool de aplicativos e executa os processos de trabalho do pool de aplicativos sob essa conta por padrão. No Console de Gerenciamento do IIS, em Configurações Avançadas do pool de aplicativos, verifique se o Identity está definido 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 identidade. No entanto, essa identidade não é uma conta de usuário real e não aparece no Console de Gerenciamento de Usuários do Windows.

Se o processo de trabalho do IIS exigir acesso elevado ao aplicativo, modifique a Lista de Controle de Acesso (ACL) para o diretório que contém o aplicativo:

1. Abra o Windows Explorer e navegue até o diretório.

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

3. No separador de Segurança, selecione o botão Editar e, em seguida, o botão Adicionar.

4. Selecione o botão Localizações e certifique-se de que o sistema está selecionado.

5. Insira no formato IIS AppPool\{APP POOL NAME}, em que o espaço reservado {APP POOL NAME} é o nome do pool de aplicativos. Na área , digite os nomes dos objetos para selecionar a área. 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 objetos. Não é possível inserir o nome do pool de aplicativos diretamente na área de nomes de objetos. Use o formato IIS AppPool\{APP POOL NAME}, onde o marcador {APP POOL NAME} é o nome do pool de aplicações, ao verificar o nome do objeto.

   

6. Selecione OK.

   

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

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

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

Para obter mais informações, consulte o tópico icacls.

Suporte HTTP/2

HTTP/2 é suportado com o ASP.NET Core nos seguintes cenários de implantação do IIS:

• In-process
  • Windows Server 2016/Windows 10 ou posterior; IIS 10 ou posterior
  • Conexão TLS 1.2 ou posterior
• Out-of-process
  • Windows Server 2016/Windows 10 ou posterior; IIS 10 ou posterior
  • As conexões de servidor de borda voltadas para o público usam HTTP/2, mas a conexão de proxy reverso com 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 é estabelecida, HttpRequest.Protocol reporta HTTP/2. Para uma implantação fora do processo quando uma conexão HTTP/2 é estabelecida, HttpRequest.Protocol relata HTTP/1.1.

Para obter mais informações sobre os modelos de hospedagem em processo e fora de processo, consulte ASP.NET ANCM (Core Module) para IIS.

HTTP/2 é ativado por padrão. As conexões retornam para HTTP/1.1 se uma conexão HTTP/2 não for estabelecida. Para obter mais informações sobre a configuração HTTP/2 com implantações do IIS, consulte HTTP/2 no IIS.

Pedidos de pré-verificação CORS

Esta seção só se aplica a aplicativos ASP.NET Core destinados ao .NET Framework.

Para um aplicativo ASP.NET Core destinado ao .NET Framework, as solicitações OPTIONS não são passadas para o aplicativo por padrão no IIS. Para saber como configurar os manipuladores do IIS do aplicativo em web.config para encaminhar pedidos OPTIONS, consulte Habilitar pedidos de origem cruzada na API Web 2 ASP.NET: Como funciona o CORS.

Módulo de inicialização do aplicativo e tempo limite ocioso

Quando hospedado no IIS pelo ASP.NET Core Module versão 2:

• Application Initialization Module: As aplicações hospedadas em processo ou fora de processo podem ser configuradas para iniciar automaticamente numa reinicialização do processo de trabalho ou numa reinicialização do servidor.
• Tempo limite de inatividade: Aplicativos em processo podem ser configurados para não ocorrer tempo limite durante os períodos de inatividade.

Módulo de inicialização de aplicativos

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

de Inicialização de Aplicativo do 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 aciona o aplicativo para iniciar. Por padrão, o IIS emite uma solicitação para a URL raiz do aplicativo (/) para inicializar o aplicativo (consulte a de recursos adicionais para obter mais detalhes sobre a configuração).

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

Em sistemas de área de trabalho Windows 7 ou 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 Rede Mundial de Computadores>Recursos de Desenvolvimento de Aplicativos.
3. Marque a caixa de seleção para Application Initialization.

No Windows Server 2008 R2 ou posterior:

1. Abra o Assistente para Adicionar Funções e Recursos .
2. No painel Selecionar serviços de função, abra o nó Desenvolvimento de Aplicações.
3. Marque a caixa de seleção para Application Initialization.

Use uma das seguintes abordagens para habilitar o Módulo de Inicialização de Aplicativo para o site:

• Usando o Gerenciador do IIS:

  1. Selecione Grupos de Aplicações no painel de Ligaçõ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 Iniciar padrão é OnDemand. Defina o Modo Iniciar como AlwaysRunning. Selecione OK.
  4. Abra o nó Sites no painel Conexões.
  5. Clique com o botão direito do rato na aplicação e selecione Gerir Site>Definições Avançadas.
  6. A configuração padrão Preload Enabled é False. Defina Pré-carregamento Ativado para True. Selecione OK.

• Usando web.config, adicione o elemento <applicationInitialization> com doAppInitAfterRestart definido como true aos 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 Inatividade

Aplica-se apenas a aplicações alojadas em processo.

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

1. Selecione Grupos de Aplicações no painel de Ligaçõ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 ocioso padrão (minutos) é de 20 minutos. Defina o tempo limite de inatividade (em minutos) para 0 (zero). Selecione OK.
4. Recicle o processo de trabalho.

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

• Execute ping no aplicativo a partir 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.

Módulo de inicialização de aplicativos e recursos adicionais de tempo limite ocioso

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

Locais de módulos, esquemas e arquivos de configuração

Module

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

Schema

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

Configuration

IIS

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

IIS Express

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

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

Os arquivos podem ser encontrados procurando por aspnetcore no arquivo applicationHost.config.

Instalar o Web Deploy ao publicar com o Visual Studio

Ao implantar aplicativos em servidores com Web Deploy, instale a versão mais recente do Web Deploy no servidor. Para instalar o Web Deploy, consulte Downloads do IIS: Web Deploy.

Criar o site do IIS

1. No sistema de hospedagem, crie uma pasta para conter as pastas e arquivos 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 a pasta de implantação e o layout de arquivo de um aplicativo, consulte ASP.NET Estrutura de diretório principal.

2. No Gestor do IIS, abra o nó do servidor no painel Conexões. Clique com o botão direito do rato na pasta Sites. Selecione Adicionar site a partir do menu de contexto.

3. Forneça um Nome do site e defina o caminho físico para a pasta de implantação do aplicativo. Forneça a configuração do Binding e crie o website selecionando OK:

   

   Warning

   As ligações genéricas de nível superior (http://*:80/ e http://+:80) não devem ser usadas. As ligações curinga de nível superior podem abrir seu aplicativo para vulnerabilidades de segurança. Isso aplica-se tanto a curingas fortes como a fracos. Utilize nomes de host explícitos em vez de curingas. A vinculação de wildcard de subdomínio (por exemplo, *.mysub.com) não apresenta este risco de segurança caso tenha controle sobre todo o domínio pai (ao contrário de *.com, que é vulnerável). Consulte RFC 9110: Semântica HTTP (Seção 7.2: Host e :authority) para obter mais informações.

4. No nó do servidor, selecione Grupos de Aplicações.

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

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

   

   ASP.NET Core é executado em um processo separado e gerencia o tempo de execução. ASP.NET Core não depende do carregamento do CLR da plataforma desktop (.NET CLR). O Core Common Language Runtime (CoreCLR) para .NET é inicializado para hospedar o aplicativo no processo de trabalho. Definir a versão do .NET CLR como No Managed Code é opcional, mas recomendado.

   • Para uma implantação independente de 32 bits (x86) publicada com um SDK de 32 bits que utiliza o modelo de alojamento em processo, habilite o Pool de Aplicações para 32 bits. No Gerenciador do IIS, navegue até Pools de Aplicativos na barra lateral Conexões. Selecione o Pool de aplicativos do aplicativo. No menu lateral Ações, selecione Configurações avançadas. Defina Ative aplicações de 32 bits para True.

   • Para uma implantação autocontida de 64 bits (x64) que usa o modelo de hospedagem em processo, desative 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. No menu lateral Ações, selecione Configurações avançadas. Defina Ative aplicações de 32 bits para False.

7. Confirme se a identidade do modelo de processo tem as permissões adequadas.

   Se a identidade padrão do pool de aplicativos (Process Model>Identity) for alterada de ApplicationPoolIdentity para outra identidade, verifique se a nova identidade tem as permissões necessárias para acessar a pasta, o banco de dados e outros recursos necessários do aplicativo. Por exemplo, o pool de aplicativos requer acesso de leitura e gravação a pastas onde o aplicativo lê e grava arquivos.

Configuração de Autenticação do Windows (Opcional)
Para obter mais informações, consulte Configurar a autenticação do Windows.

<?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>