Hospedar o ASP.NET Core no Windows com o IIS

  • Artigo

Observação

Esta não é a versão mais recente deste artigo. Para informações sobre a versão vigente, confira a Versão do .NET 8 deste artigo.

Aviso

Esta versão do ASP.NET Core não tem mais suporte. Para obter mais informações, confira .NET e a Política de Suporte do .NET Core. Para informações sobre a versão vigente, confira a Versão do .NET 8 deste artigo.

Importante

Essas informações relacionam-se ao produto de pré-lançamento, que poderá ser substancialmente modificado antes do lançamento comercial. A Microsoft não oferece nenhuma garantia, explícita ou implícita, quanto às informações fornecidas aqui.

Para informações sobre a versão vigente, confira a Versão do .NET 8 deste artigo.

O ISS (Serviços de Informações da Internet) é um Servidor Web flexível, seguro e gerenciável para hospedar aplicativos Web, incluindo o ASP.NET Core.

Plataformas com Suporte

Há suporte para os seguintes sistemas operacionais:

  • Windows 7 ou posterior
  • Windows Server 2012 R2 ou versões posteriores

Aplicativos publicados para implantação de 32 bits (x86) ou 64 bits (x64) têm suporte. Implantar um aplicativo de 32 bits com um SDK do .NET Core de 32 bits (x86), a menos que o aplicativo:

  • Exija o maior espaço de endereço de memória virtual disponível para um aplicativo de 64 bits.
  • Exija o maior tamanho de pilha do IIS.
  • Tenha dependências nativas de 64 bits.

Instalar o pacote de hospedagem/módulo do ASP.NET Core

Baixe o instalador mais recente usando o seguinte link:

Instalador de pacote de hospedagem do .NET Core atual (download direto)

Para obter instruções mais detalhadas de como instalar o Módulo do ASP.NET Core, ou de como instalar versões diferentes, confira Instalar o Pacote de Hospedagem do .NET Core.

Para baixar versões anteriores do pacote de hospedagem, confira este problema do GitHub.

Introdução

Para começar a hospedar um site no IIS, consulte nosso guia de introdução.

Para começar a hospedar um site nos Serviços de Aplicativo do Azure, consulte nosso guia de implantação no Serviço de Aplicativo do Azure.

Configuração

Para obter diretrizes de configuração, consulte Configuração avançada.

Recursos de implantação para administradores do IIS

Reciclagem sobreposta

Em geral, recomendamos o uso de um padrão como implantações azul-verde para implantações sem tempo de inatividade. Recursos como a reciclagem sobreposta ajudam, mas não garantem que você possa fazer uma implantação sem tempo de inatividade. Saiba mais neste tópico do GitHub.

Certificados do cliente opcionais

Para obter informações sobre aplicativos que precisam proteger um subconjunto do aplicativo com um certificado, consulte Certificados de cliente opcionais.

Recursos adicionais

Para ter uma experiência de tutorial sobre como publicar um aplicativo ASP.NET Core em um servidor do IIS, consulte Publicar um aplicativo ASP.NET Core no IIS.

Instalar o pacote de hospedagem do .NET Core

Sistemas operacionais compatíveis

Há suporte para os seguintes sistemas operacionais:

  • Windows 7 ou posterior
  • Windows Server 2012 R2 ou versões posteriores

O servidor HTTP.sys (anteriormente chamado de WebListener) não funciona em uma configuração de proxy reverso com o IIS. Use o servidor Kestrel.

Para obter informações sobre a hospedagem no Azure, consulte Implantar aplicativos ASP.NET Core no Serviço de Aplicativo do Azure.

Para obter diretrizes de solução de problemas, consulte Solucionar problemas e depurar projetos do ASP.NET Core.

Plataformas com Suporte

Aplicativos publicados para implantação de 32 bits (x86) ou 64 bits (x64) têm suporte. Implantar um aplicativo de 32 bits com um SDK do .NET Core de 32 bits (x86), a menos que o aplicativo:

  • Exija o maior espaço de endereço de memória virtual disponível para um aplicativo de 64 bits.
  • Exija o maior tamanho de pilha do IIS.
  • Tenha dependências nativas de 64 bits.

Aplicativos publicados para 32 bits (x86) devem ter a opção de 32 bits habilitada para os Pools de Aplicativos do IIS. Para obter mais informações, consulte a seção Criar o site do IIS.

Use um SDK do .NET Core de 64 bits (x64) para publicar um aplicativo de 64 bits. Um runtime de 64 bits deve estar presente no sistema host.

Modelos de hospedagem

Modelo de hospedagem em processo

Usando uma hospedagem em processo, um aplicativo ASP.NET Core é executado no mesmo processo que seu processo de trabalho do IIS. A hospedagem em processo oferece desempenho melhor em hospedagem fora do processo porque as solicitações não são transmitidas por proxy pelo adaptador de loopback, um adaptador de rede que retorna o tráfego de rede de saída para o mesmo computador. O IIS manipula o gerenciamento de processos com o WAS (Serviço de Ativação de Processos do Windows).

O Módulo do ASP.NET Core:

  • Executa a inicialização do aplicativo.
    • Carrega o CoreCLR.
    • Chama Program.Main.
  • Manipula o tempo de vida da solicitação nativa do IIS.

O diagrama a seguir ilustra a relação entre o IIS, o Módulo do ASP.NET Core e um aplicativo hospedado em processo:

Módulo do ASP.NET Core no cenário de hospedagem em processo

  1. A solicitação chega da Web para o driver do HTTP.sys no modo kernel.
  2. O driver roteia as solicitações nativas ao IIS na porta configurada do site, normalmente, a 80 (HTTP) ou a 443 (HTTPS).
  3. O Módulo do ASP.NET Core recebe a solicitação nativa e a passa para o Servidor HTTP do IIS (IISHttpServer). O servidor HTTP do IIS é uma implementação de servidor em processo do IIS que converte a solicitação de nativa para gerenciada.

Após o servidor HTTP do IIS processar a solicitação:

  1. A solicitação é enviada para o pipeline de middleware do ASP.NET Core.
  2. O pipeline do middleware manipula a solicitação e a passa como uma instância de HttpContext para a lógica do aplicativo.
  3. A resposta do aplicativo é retornada ao IIS por meio do Servidor HTTP do IIS.
  4. O IIS enviará a resposta ao cliente que iniciou a solicitação.

A hospedagem em processo é aceita para aplicativos existentes. Os modelos Web do ASP.NET Core usam o modelo de hospedagem em processo.

CreateDefaultBuilder adiciona uma instância de IServer chamando o método UseIIS para inicializar o CoreCLR e hospedar o aplicativo no processo de trabalho do IIS (w3wp.exe ou iisexpress.exe). Os testes de desempenho indicam que hospedar um aplicativo em processo do .NET Core oferece uma de taxa de transferência de solicitação significativamente mais elevada em comparação a hospedar o aplicativo fora do processo e enviar por proxy as solicitações para o Kestrel.

Aplicativos publicados como um único arquivo executável não podem ser carregados pelo modelo de hospedagem em processo.

Modelo de hospedagem de fora do processo

Como os aplicativos ASP.NET Core são executados em um processo separado do processo de trabalho do IIS, o Módulo do ASP.NET Core realiza o gerenciamento de processos. O módulo inicia o processo para o aplicativo ASP.NET Core quando a primeira solicitação chega e reinicia o aplicativo se ele é desligado ou falha. Isso é basicamente o mesmo comportamento que o dos aplicativos que são executados dentro do processo e são gerenciados pelo WAS (Serviço de Ativação de Processos do Windows).

O diagrama a seguir ilustra a relação entre o IIS, o Módulo do ASP.NET Core e um aplicativo hospedado de fora d processo:

Módulo do ASP.NET Core no cenário de hospedagem fora do processo

  1. As solicitações chegam da Web para o driver do HTTP.sys no modo kernel.
  2. O driver roteia as solicitações ao IIS na porta configurada do site. A porta configurada geralmente é 80 (HTTP) ou 443 (HTTPS).
  3. O módulo encaminha as solicitações para Kestrel em uma porta aleatória para o aplicativo. A porta aleatória não é a 80 nem a 443.

O Módulo do ASP.NET Core especifica a porta por meio de uma variável de ambiente na inicialização. A extensão UseIISIntegration configura o servidor a ser escutado em http://localhost:{PORT}. Outras verificações são executadas e as solicitações que não se originam do módulo são rejeitadas. O módulo não dá suporte ao encaminhamento de HTTPS. As solicitações são encaminhadas por HTTP, mesmo se forem recebidas pelo IIS por HTTPS.

Depois que o Kestrel coleta a solicitação do módulo, a solicitação é encaminhada ao pipeline do middleware do ASP.NET Core. O pipeline do middleware manipula a solicitação e a passa como uma instância de HttpContext para a lógica do aplicativo. O middleware adicionado pela integração do IIS atualiza o esquema, o IP remoto e pathbase para encaminhar a solicitação para o Kestrel. A resposta do aplicativo é retornada ao IIS, que a encaminha para o cliente HTTP que iniciou a solicitação.

Para obter diretrizes de configuração do Módulo do ASP.NET Core, consulte Módulo do ASP.NET Core (ANCM) para IIS.

Para saber mais sobre hospedagem, confira Host no ASP.NET Core.

Configuração de aplicativo

Habilitar os componentes de IISIntegration

Ao criar um host em CreateHostBuilder (Program.cs), chame CreateDefaultBuilder para habilitar a integração do IIS:

public static IHostBuilder CreateHostBuilder(string[] args) =>
    Host.CreateDefaultBuilder(args)
        ...

Para saber mais sobre CreateDefaultBuilder, confira Host Genérico .NET no ASP.NET Core.

Opções do IIS

Modelo de hospedagem em processo

Para configurar as opções do Servidor IIS, inclua uma configuração de serviço para IISServerOptions em ConfigureServices. O exemplo a seguir desabilita AutomaticAuthentication:

services.Configure<IISServerOptions>(options => 
{
    options.AutomaticAuthentication = false;
});
Opção Padrão Configuração
AutomaticAuthentication true Se true, o Servidor do IIS define o HttpContext.User autenticado pela Autenticação do Windows. Se false, o servidor fornecerá apenas uma identity para HttpContext.User e responderá a desafios quando explicitamente solicitado pelo AuthenticationScheme. A autenticação do Windows deve estar habilitada no IIS para que o AutomaticAuthentication funcione. Para obter mais informações, confira Autenticação do Windows.
AuthenticationDisplayName null Configura o nome de exibição mostrado aos usuários em páginas de logon.
AllowSynchronousIO false Se a E/S síncrona é permitida para o HttpContext.Request e o HttpContext.Response.
MaxRequestBodySize 30000000 Obtém ou define o tamanho máximo do corpo da solicitação para o HttpRequest. Observe que o próprio IIS tem o limite maxAllowedContentLength que será processado antes de MaxRequestBodySize definido no IISServerOptions. Alterar MaxRequestBodySize não afetará maxAllowedContentLength. Para aumentar maxAllowedContentLength, adicione uma entrada a web.config para definir maxAllowedContentLength como um valor mais alto. Para obter mais detalhes, confira Configuração.

Modelo de hospedagem de fora do processo

Para configurar opções do IIS, inclua uma configuração de serviço para IISOptions em ConfigureServices. O exemplo a seguir impede que o aplicativo preencha HttpContext.Connection.ClientCertificate:

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});
Opção Padrão Configuração
AutomaticAuthentication true Se true, o middleware de integração do IIS define o HttpContext.User autenticado pela Autenticação do Windows. Se false, o middleware fornecerá apenas uma identity para HttpContext.User e responderá a desafios quando explicitamente solicitado pelo AuthenticationScheme. A autenticação do Windows deve estar habilitada no IIS para que o AutomaticAuthentication funcione. Saiba mais no tópico Autenticação do Windows.
AuthenticationDisplayName null Configura o nome de exibição mostrado aos usuários em páginas de logon.
ForwardClientCertificate true Se true e o cabeçalho da solicitação MS-ASPNETCORE-CLIENTCERT estiverem presentes, o HttpContext.Connection.ClientCertificate será populado.

Servidor proxy e cenários de balanceador de carga

O Middleware de integração do IIS e o Módulo do ASP.NET Core estão configurados para encaminhar o:

  • Esquema (HTTP/HTTPS).
  • Endereço IP remoto em que a solicitação foi originada.

O Middleware de Integração do IIS configura o Middleware de Cabeçalhos Encaminhados.

Configuração adicional pode ser necessária para aplicativos hospedados atrás de servidores proxy adicionais e balanceadores de carga. Para obter mais informações, veja Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga.

Arquivo web.config

O arquivo web.config configura o Módulo do ASP.NET Core. A criação, a transformação e a publicação do arquivo web.config são tratadas por um destino do MSBuild (_TransformWebConfig) quando o projeto é publicado. Este destino está presente nos destinos do SDK da Web (Microsoft.NET.Sdk.Web). O SDK é definido na parte superior do arquivo de projeto:

<Project Sdk="Microsoft.NET.Sdk.Web">

Se um arquivo web.config não estiver presente no projeto, ele será criado com o processPath e o arguments corretos para configurar o Módulo do ASP.NET Core e será transferido para o resultado publicado.

Se um arquivo web.config estiver presente no projeto, ele será transformado com o processPath e o arguments para configurar o Módulo do ASP.NET Core e será transferido para o resultado publicado. A transformação não altera as definições de configuração do IIS no arquivo.

O arquivo web.config pode fornecer configurações adicionais do IIS que controlam módulos ativos do IIS. Para saber mais sobre os módulos do IIS que podem processar solicitações com aplicativos do ASP.NET Core, veja o tópico Módulos do IIS.

Para impedir que o SDK Web transforme o arquivo web.config, use a propriedade <IsTransformWebConfigDisabled> no arquivo do projeto:

<PropertyGroup>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Ao impedir que o SDK Web transforme o arquivo, o processPath e o argumentsdevem ser definidos manualmente pelo desenvolvedor. Para obter mais informações, confira Módulo do ASP.NET Core (ANCM) para o IIS.

Local do arquivo web.config

Para configurar o Módulo do ASP.NET Core corretamente, o arquivo web.config deve estar presente no caminho raiz do conteúdo (geralmente, o aplicativo base do caminho) do aplicativo implantado. Esse é o mesmo local que o caminho físico do site fornecido ao IIS. O arquivo web.config é necessário na raiz do aplicativo para habilitar a publicação de vários aplicativos usando a Implantação da Web.

Existem arquivos confidenciais no caminho físico do aplicativo, como {ASSEMBLY}.runtimeconfig.json, {ASSEMBLY}.xml (comentários da Documentação XML) e {ASSEMBLY}.deps.json, onde o espaço reservado {ASSEMBLY} é o nome do assembly. Quando o arquivo web.config estiver presente e o site for iniciado normalmente, o IIS não fornecerá esses arquivos confidenciais se eles forem solicitados. Se o arquivo web.config estiver ausente, for nomeado incorretamente ou se não for possível configurar o site para inicialização normal, o IIS poderá servir arquivos confidenciais publicamente.

O arquivo web.config deve estar presente na implantação em todos os momentos, nomeado corretamente e ser capaz de configurar o site para inicialização normal. Nunca remova o arquivo web.config de uma implantação de produção.

Transformação do Web.config

Se você precisar transformar web.config na publicação, consulte Transformar web.config. Talvez seja necessário transformar web.config na publicação para definir variáveis de ambiente com base na configuração, no perfil ou no ambiente.

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).

    A função de Servidor Web IIS é selecionada na etapa Selecionar funções de servidor.

  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.

    Os serviços de função padrão são selecionados na etapa Selecionar serviços de função.

    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.

O Console de Gerenciamento do IIS e os Serviços na World Wide Web estão selecionados em Recursos do Windows.

Instalar o pacote de hospedagem do .NET Core

Instale o pacote de hospedagem do .NET Core no sistema de hospedagem. O pacote instala o Runtime .NET Core, a Biblioteca do .NET Core e o Módulo do ASP.NET Core. O módulo permite que aplicativos do ASP.NET Core sejam executados por trás do IIS.

Importante

Se o pacote de hospedagem for instalado antes do IIS, a instalação do pacote deverá ser reparada. Execute o instalador do pacote de hospedagem novamente depois de instalar o IIS.

Se o pacote de hospedagem for instalado após a instalação da versão de 64 bits (x64) do .NET Core, os SDKs poderão parecer estar ausentes (Nenhum SDK do .NET Core foi detectado). Para resolver o problema, consulte Solucionar problemas e depurar projetos do ASP.NET Core.

Download direto (versão atual)

Baixe o instalador usando o seguinte link:

Instalador de pacote de hospedagem do .NET Core atual (download direto)

Versões anteriores do instalador

Para obter uma versão anterior do instalador:

  1. Navegue até a página Baixar o .NET Core.
  2. Selecione a versão desejada do .NET Core.
  3. Na coluna Executar aplicativos – runtime, localize a linha da versão de runtime do .NET Core desejada.
  4. Baixe o instalador usando o link Pacote de hospedagem.

Aviso

Alguns instaladores contêm versões de lançamento que atingiram o EOL (fim da vida útil) e não têm mais suporte da Microsoft. Para saber mais, confira a política de suporte.

Instalar o pacote de hospedagem

  1. Execute o instalador no servidor. Os parâmetros a seguir estão disponíveis ao executar o instalador por meio de um shell de comando do administrador:

    • OPT_NO_ANCM=1: ignorar a instalação do Módulo do ASP.NET Core.
    • OPT_NO_RUNTIME=1: ignorar a instalação do runtime do .NET Core. Usado quando o servidor hospeda apenas implantações autossuficientes (SCD).
    • OPT_NO_SHAREDFX=1: ignorar a instalação da Estrutura Compartilhada do ASP.NET (runtime do ASP.NET). Usado quando o servidor hospeda apenas implantações autossuficientes (SCD).
    • OPT_NO_X86=1: ignorar a instalação dos runtimes x86. Use esse parâmetro quando você souber que não hospedará aplicativos de 32 bits. Se houver uma possibilidade de hospedar aplicativos de 32 bits e 64 bits no futuro, não use esse parâmetro e instale ambos os runtimes.
    • OPT_NO_SHARED_CONFIG_CHECK=1: desabilite a verificação para usar uma Configuração Compartilhada do IIS quando a configuração compartilhada (applicationHost.config) estiver no mesmo computador do que a instalação do IIS. Disponível somente para instaladores do ASP.NET Core 2.2 ou Hosting Bundler posterior. Para obter mais informações, confira Módulo do ASP.NET Core (ANCM) para o IIS.

  2. A reinicialização do IIS identifica uma alteração no CAMINHO do sistema, que é uma variável de ambiente, realizada pelo instalador. Para reiniciar o servidor Web, interrompa o WAS (Serviço de Ativação de Processo do Windows) e reinicie o W3SVC (Serviço de Publicação na World Wide Web). Reinicie o sistema ou execute os seguintes comandos em um shell de comando com privilégios elevados:

    net stop was /y
net start w3svc

O ASP.NET Core não adota o comportamento de roll forward para versões de patch de pacotes de estrutura compartilhada. Depois de atualizar a estrutura compartilhada instalando um novo pacote de hospedagem, reinicie o sistema ou execute os seguintes comandos em um shell de comandos com privilégios elevados:

net stop was /y
net start w3svc

Observação

Para obter informações sobre a Configuração Compartilhada do IIS, consulte Módulo do ASP.NET Core com a Configuração Compartilhada do IIS.

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, use o WebPI (Web Platform Installer) ou confira Downloads do IIS: Implantação da Web. O método preferencial é usar o WebPI. O WebPI oferece uma instalação autônoma e uma configuração para provedores de hospedagem.

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:

    Forneça o Nome do site, o caminho físico e o Nome do host na etapa Adicionar Site.

    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:

    Defina Sem Código Gerenciado para a versão do CLR do .NET.

    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.

  7. ASP.NET Core 2.2 ou posterior:

    • 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 autocontida 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.

  8. 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) de 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.

Implantar o aplicativo

Implante o aplicativo na pasta caminho físico do IIS que foi estabelecida na seção Criar o site do IIS. Implantação da Web é o mecanismo recomendado para implantação, mas existem várias opções para mover o aplicativo da pasta publish do projeto para a pasta de implantação do sistema de hospedagem.

Implantação da Web com o Visual Studio

Consulte o tópico Perfis de publicação do Visual Studio para implantação de aplicativos ASP.NET Core para saber como criar um perfil de publicação para uso com a Implantação da Web. Se o provedor de hospedagem fornecer um Perfil de Publicação ou o suporte para a criação de um, baixe o perfil e importe-o usando a caixa de diálogo Publicar do Visual Studio:

Página de caixa de diálogo Publicar

Implantação da Web fora do Visual Studio

Também é possível usar a Implantação da Web fora do Visual Studio na linha de comando. Para obter mais informações, consulte Ferramenta de Implantação da Web.

Alternativas à Implantação da Web

Use qualquer um dos vários métodos para mover o aplicativo para o sistema host, como cópia manual, Xcopy, Robocopy ou PowerShell.

Para obter mais informações sobre a implantação do ASP.NET Core no IIS, consulte a seção Recursos de implantação para administradores do IIS.

Procurar no site

Depois de implantar o aplicativo no sistema de hospedagem, faça uma solicitação para um dos pontos de extremidade públicos do aplicativo.

No exemplo a seguir, o site está associado a um Nome do Host IIS de www.mysite.com na Porta80. É feita uma solicitação para http://www.mysite.com:

O navegador Microsoft Edge carregou a página de inicialização do IIS.

Arquivos de implantação bloqueados

Os arquivos na pasta de implantação são bloqueados quando o aplicativo está em execução. Os arquivos bloqueados não podem ser substituídos durante a implantação. Para liberar os arquivos bloqueados em uma implantação, interrompa o pool de aplicativos usando uma das abordagens a seguir:

  • Use a Implantação da Web e referencie Microsoft.NET.Sdk.Web no arquivo do projeto. Um arquivo app_offline.htm é colocado na raiz do diretório de aplicativo da Web. Quando o arquivo estiver presente, o módulo do ASP.NET Core apenas desligará o aplicativo e servirá o arquivo app_offline.htm durante a implantação. Para obter mais informações, consulte Referência de configuração do módulo do ASP.NET Core.

  • Manualmente interrompa o pool de aplicativos no Gerenciador do IIS no servidor.

  • Use o PowerShell para remover app_offline.htm (requer o PowerShell 5 ou posterior):

    $pathToApp = 'PATH_TO_APP'

# Stop the AppPool
New-Item -Path $pathToApp app_offline.htm

# Provide script commands here to deploy the app

# Restart the AppPool
Remove-Item -Path $pathToApp app_offline.htm

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 for 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 externo aos aplicativos. Para persistir as chaves de 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 de registro no registro HKLM que é acessível apenas para a 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 de proteção de dados não são criptografadas. Garanta que as permissões de arquivo de o compartilhamento de rede sejam limitadas à conta do Windows na qual 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. Veja Configurar a proteção de dados do ASP.NET Core para obter detalhes.

  • 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 ser 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 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, 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. Configure 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.

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.

Links de ativos estáticos dentro do subaplicativo devem usar a notação de sinal de til e barra (~/). 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.

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.

Configuração do IIS com web.config

A configuração do IIS é influenciada pela seção <system.webServer> do web.config para cenários do IIS que são funcionais para aplicativos ASP.NET Core com o Módulo do ASP.NET Core. Por exemplo, a configuração do IIS é funcional para a compactação dinâmica. Se o IIS for configurado no nível do servidor para usar a compactação dinâmica, o elemento <urlCompression> no arquivo web.config do aplicativo pode desabilitá-la para um aplicativo do ASP.NET Core.

Para Mais informações, consulte os seguintes tópicos:

Para definir variáveis de ambiente para aplicativos individuais executados em pools de aplicativos isolados (compatível com o IIS 10.0+ ou posterior), veja a seção comando AppCmd.exe do tópico Variáveis de ambiente <environmentVariables> na documentação de referência do IIS.

Seções que não são usadas pelo ASP.NET Core

As seções de configuração de aplicativos ASP.NET em web.config não são usadas por aplicativos ASP.NET Core para configuração:

  • <system.web>
  • <appSettings>
  • <connectionStrings>
  • <location>

Aplicativos ASP.NET Core são configurados para usar outros provedores de configuração. Para obter mais informações, consulte Configuração e Configuração de tempo de execução do .NET Core

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 do pool de aplicativos, verifique se Identity está definido para usar ApplicationPoolIdentity:

Caixa de diálogo Configurações avançadas do pool de aplicativos

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 IIS AppPool\{APP POOL NAME}, em que o espaço reservado {APP POOL NAME} é o nome do pool de aplicativos, na área Inserir 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.

    Selecione a caixa de diálogo de usuários ou grupos para a pasta do aplicativo: o nome do pool de aplicativos

  6. Selecione OK.

    Selecione a caixa de diálogo de usuários ou grupos para a pasta do aplicativo: depois de selecionar

  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 o DefaultAppPool como exemplo, o comando a seguir é usado:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F

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

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 é Falso. Defina Pré-carregamento Habilitado como Verdadeiro. Selecione OK.

  • Usando web.config, adicione o elemento <applicationInitialization> definindo doAppInitAfterRestart 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 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:

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

Recursos de implantação para administradores do IIS

Recursos adicionais

Para ter uma experiência de tutorial sobre como publicar um aplicativo ASP.NET Core em um servidor do IIS, consulte Publicar um aplicativo ASP.NET Core no IIS.

Instalar o pacote de hospedagem do .NET Core

Sistemas operacionais compatíveis

Há suporte para os seguintes sistemas operacionais:

  • Windows 7 ou posterior
  • Windows Server 2008 R2 ou posterior

O servidor HTTP.sys (anteriormente chamado de WebListener) não funciona em uma configuração de proxy reverso com o IIS. Use o servidor Kestrel.

Para obter informações sobre a hospedagem no Azure, consulte Implantar aplicativos ASP.NET Core no Serviço de Aplicativo do Azure.

Para obter diretrizes de solução de problemas, consulte Solucionar problemas e depurar projetos do ASP.NET Core.

Plataformas com Suporte

Aplicativos publicados para implantação de 32 bits (x86) ou 64 bits (x64) têm suporte. Implantar um aplicativo de 32 bits com um SDK do .NET Core de 32 bits (x86), a menos que o aplicativo:

  • Exija o maior espaço de endereço de memória virtual disponível para um aplicativo de 64 bits.
  • Exija o maior tamanho de pilha do IIS.
  • Tenha dependências nativas de 64 bits.

Use um SDK do .NET Core de 64 bits (x64) para publicar um aplicativo de 64 bits. Um runtime de 64 bits deve estar presente no sistema host.

O ASP.NET Core vem com o servidor Kestrel, um servidor HTTP padrão multiplataforma.

Ao usar o IIS ou o IIS Express, o aplicativo é executado em um processo separado do processo de trabalho do IIS (fora do processo) com o servidorKestrel.

Como os aplicativos ASP.NET Core são executados em um processo separado do processo de trabalho do IIS, o módulo realiza o gerenciamento de processos. O módulo inicia o processo para o aplicativo ASP.NET Core quando a primeira solicitação chega e reinicia o aplicativo se ele é desligado ou falha. Isso é basicamente o mesmo comportamento que o dos aplicativos que são executados dentro do processo e são gerenciados pelo WAS (Serviço de Ativação de Processos do Windows).

O diagrama a seguir ilustra a relação entre o IIS, o Módulo do ASP.NET Core e um aplicativo hospedado de fora d processo:

Módulo do ASP.NET Core

As solicitações chegam da Web para o driver do HTTP.sys no modo kernel. O driver roteia as solicitações ao IIS na porta configurada do site, normalmente, a 80 (HTTP) ou a 443 (HTTPS). O módulo encaminha as solicitações ao Kestrel em uma porta aleatória do aplicativo, que não seja a porta 80 ou 443.

O módulo especifica a porta por meio de uma variável de ambiente na inicialização e o middleware de integração do IIS configura o servidor para escutar em http://localhost:{port}. Outras verificações são executadas e as solicitações que não se originam do módulo são rejeitadas. O módulo não é compatível com encaminhamento de HTTPS, portanto, as solicitações são encaminhadas por HTTP, mesmo se recebidas pelo IIS por HTTPS.

Depois que o Kestrel coleta a solicitação do módulo, a solicitação é enviada por push ao pipeline do middleware do ASP.NET Core. O pipeline do middleware manipula a solicitação e a passa como uma instância de HttpContext para a lógica do aplicativo. O middleware adicionado pela integração do IIS atualiza o esquema, o IP remoto e pathbase para encaminhar a solicitação para o Kestrel. A resposta do aplicativo é retornada ao IIS, que a retorna por push para o cliente HTTP que iniciou a solicitação.

CreateDefaultBuilder configura o servidor Kestrel como o servidor Web e habilita a integração do IIS, configurando o caminho base e a porta para o Módulo do ASP.NET Core.

O Módulo do ASP.NET Core gera uma porta dinâmica a ser atribuída ao processo de back-end. CreateDefaultBuilder chama o método UseIISIntegration. UseIISIntegration configura o Kestrel para escutar na porta dinâmica no endereço IP do localhost (127.0.0.1). Se a porta dinâmica for 1234, o Kestrelescutará em 127.0.0.1:1234. Essa configuração substitui outras configurações de URL fornecidas por:

As chamadas a UseUrls ou à API Kestrel do Listen não são necessárias ao usar o módulo. Se UseUrls ou Listen for chamado, o Kestrel escutará na porta especificada somente durante a execução do aplicativo sem o IIS.

Para obter diretrizes de configuração do Módulo do ASP.NET Core, consulte Módulo do ASP.NET Core (ANCM) para IIS.

Para saber mais sobre hospedagem, confira Host no ASP.NET Core.

Configuração de aplicativo

Habilitar os componentes de IISIntegration

Ao criar um host em CreateWebHostBuilder (Program.cs), chame CreateDefaultBuilder para habilitar a integração do IIS:

public static IWebHostBuilder CreateWebHostBuilder(string[] args) =>
    WebHost.CreateDefaultBuilder(args)
        ...

Para saber mais sobre CreateDefaultBuilder, confira Host da Web do ASP.NET Core.

Opções do IIS

Opção Padrão Configuração
AutomaticAuthentication true Se true, o Servidor do IIS define o HttpContext.User autenticado pela Autenticação do Windows. Se false, o servidor fornecerá apenas uma identity para HttpContext.User e responderá a desafios quando explicitamente solicitado pelo AuthenticationScheme. A autenticação do Windows deve estar habilitada no IIS para que o AutomaticAuthentication funcione. Para obter mais informações, confira Autenticação do Windows.
AuthenticationDisplayName null Configura o nome de exibição mostrado aos usuários em páginas de logon.

Para configurar opções do IIS, inclua uma configuração de serviço para IISOptions em ConfigureServices. O exemplo a seguir impede que o aplicativo preencha HttpContext.Connection.ClientCertificate:

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});
Opção Padrão Configuração
AutomaticAuthentication true Se true, o middleware de integração do IIS define o HttpContext.User autenticado pela Autenticação do Windows. Se false, o middleware fornecerá apenas uma identity para HttpContext.User e responderá a desafios quando explicitamente solicitado pelo AuthenticationScheme. A autenticação do Windows deve estar habilitada no IIS para que o AutomaticAuthentication funcione. Saiba mais no tópico Autenticação do Windows.
AuthenticationDisplayName null Configura o nome de exibição mostrado aos usuários em páginas de logon.
ForwardClientCertificate true Se true e o cabeçalho da solicitação MS-ASPNETCORE-CLIENTCERT estiverem presentes, o HttpContext.Connection.ClientCertificate será populado.

Servidor proxy e cenários de balanceador de carga

O Middleware de integração do IIS, que configura o Middleware de cabeçalhos encaminhados, e o módulo do ASP.NET Core, são configurados para encaminhar o esquema (HTTP/HTTPS) e o endereço IP remoto de onde a solicitação foi originada. Configuração adicional pode ser necessária para aplicativos hospedados atrás de servidores proxy adicionais e balanceadores de carga. Para obter mais informações, veja Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga.

Arquivo web.config

O arquivo web.config configura o Módulo do ASP.NET Core. Criando, transformar e publicar o arquivo Web.config é tratado por um destino do MSBuild (_TransformWebConfig) quando o projeto é publicado. Este destino está presente nos destinos do SDK da Web (Microsoft.NET.Sdk.Web). O SDK é definido na parte superior do arquivo de projeto:

<Project Sdk="Microsoft.NET.Sdk.Web">

Se um arquivo web.config não estiver presente no projeto, o arquivo será criado com os argumentos processPath e corretos para configurar o Módulo ASP.NET Core e movido para saída publicada.

Se um arquivo web.config estiver presente no projeto, ele será transformado com o processPath e os argumentos corretos para configurar o Módulo do ASP.NET Core e será movido para o resultado publicado. A transformação não altera as definições de configuração do IIS no arquivo.

O arquivo web.config pode fornecer configurações adicionais do IIS que controlam módulos ativos do IIS. Para saber mais sobre os módulos do IIS que podem processar solicitações com aplicativos do ASP.NET Core, veja o tópico Módulos do IIS.

Para impedir que o SDK Web transforme o arquivo web.config, use a propriedade <IsTransformWebConfigDisabled> no arquivo do projeto:

<PropertyGroup>
  <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
</PropertyGroup>

Ao impedir que o SDK Web transforme o arquivo, o processPath e os argumentos devem ser definidos manualmente pelo desenvolvedor. Para obter mais informações, confira Módulo do ASP.NET Core (ANCM) para o IIS.

Local do arquivo web.config

Para configurar o Módulo do ASP.NET Core corretamente, o arquivo web.config deve estar presente no caminho raiz do conteúdo (geralmente, o aplicativo base do caminho) do aplicativo implantado. Esse é o mesmo local que o caminho físico do site fornecido ao IIS. O arquivo web.config é necessário na raiz do aplicativo para habilitar a publicação de vários aplicativos usando a Implantação da Web.

Existem arquivos confidenciais no caminho físico do aplicativo, como <assembly>.runtimeconfig.json, <assembly>.xml (comentários da Documentação XML) e <assembly>.deps.json. Quando o arquivo web.config estiver presente e o site for iniciado normalmente, o IIS não atenderá a esses arquivos confidenciais se eles forem solicitados. Se o arquivo web.config estiver ausente, nomeado incorretamente ou se não for possível configurar o site para inicialização normal, o IIS poderá servir arquivos confidenciais publicamente.

O arquivo web.config deve estar presente na implantação o tempo todo, nomeado corretamente e capaz de configurar o site para a inicialização normal. Nunca remova o arquivo web.config de uma implantação de produção.

Transformação do Web.config

Se você precisar transformar o Web.config em publicação (por exemplo, definir variáveis ​​de ambiente com base na configuração, no perfil ou no ambiente), consulte Transformar web.config.

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).

    A função de Servidor Web IIS é selecionada na etapa Selecionar funções de servidor.

  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.

    Os serviços de função padrão são selecionados na etapa Selecionar serviços de função.

    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.

O Console de Gerenciamento do IIS e os Serviços na World Wide Web estão selecionados em Recursos do Windows.

Instalar o pacote de hospedagem do .NET Core

Instale o pacote de hospedagem do .NET Core no sistema de hospedagem. O pacote instala o Runtime .NET Core, a Biblioteca do .NET Core e o Módulo do ASP.NET Core. O módulo permite que aplicativos do ASP.NET Core sejam executados por trás do IIS.

Importante

Se o pacote de hospedagem for instalado antes do IIS, a instalação do pacote deverá ser reparada. Execute o instalador do pacote de hospedagem novamente depois de instalar o IIS.

Se o pacote de hospedagem for instalado após a instalação da versão de 64 bits (x64) do .NET Core, os SDKs poderão parecer estar ausentes (Nenhum SDK do .NET Core foi detectado). Para resolver o problema, consulte Solucionar problemas e depurar projetos do ASP.NET Core.

Download

  1. Navegue até a página Baixar o .NET Core.
  2. Selecione a versão desejada do .NET Core.
  3. Na coluna Executar aplicativos – runtime, localize a linha da versão de runtime do .NET Core desejada.
  4. Baixe o instalador usando o link Pacote de hospedagem.

Aviso

Alguns instaladores contêm versões de lançamento que atingiram o EOL (fim da vida útil) e não têm mais suporte da Microsoft. Para saber mais, confira a política de suporte.

Instalar o pacote de hospedagem

  1. Execute o instalador no servidor. Os parâmetros a seguir estão disponíveis ao executar o instalador por meio de um shell de comando do administrador:

    • OPT_NO_ANCM=1: ignorar a instalação do Módulo do ASP.NET Core.
    • OPT_NO_RUNTIME=1: ignorar a instalação do runtime do .NET Core. Usado quando o servidor hospeda apenas implantações autossuficientes (SCD).
    • OPT_NO_SHAREDFX=1: ignorar a instalação da Estrutura Compartilhada do ASP.NET (runtime do ASP.NET). Usado quando o servidor hospeda apenas implantações autossuficientes (SCD).
    • OPT_NO_X86=1: ignorar a instalação dos runtimes x86. Use esse parâmetro quando você souber que não hospedará aplicativos de 32 bits. Se houver uma possibilidade de hospedar aplicativos de 32 bits e 64 bits no futuro, não use esse parâmetro e instale ambos os runtimes.
    • OPT_NO_SHARED_CONFIG_CHECK=1: desabilite a verificação para usar uma Configuração Compartilhada do IIS quando a configuração compartilhada (applicationHost.config) estiver no mesmo computador do que a instalação do IIS. Disponível somente para instaladores do ASP.NET Core 2.2 ou Hosting Bundler posterior. Para obter mais informações, confira Módulo do ASP.NET Core (ANCM) para o IIS.

  2. Reinicie o sistema ou execute os seguintes comandos em um shell de comando:

    net stop was /y
net start w3svc

    A reinicialização do IIS identifica uma alteração no CAMINHO do sistema, que é uma variável de ambiente, realizada pelo instalador.

Não é necessário interromper manualmente sites individuais no IIS ao instalar o Pacote de Hospedagem. Os aplicativos hospedados (sites do IIS) são reiniciados quando o IIS é reiniciado. Os aplicativos são iniciados novamente quando recebem a primeira solicitação, inclusive do Módulo de Inicialização de Aplicativo.

O ASP.NET Core adota o comportamento de roll forward para versões de patch de pacotes de estrutura compartilhada. Quando aplicativos hospedados pelo IIS são reiniciados com o IIS, eles são carregados com as versões de patch mais recentes de seus pacotes referenciados quando recebem a primeira solicitação. Se o IIS não for reiniciado, os aplicativos reiniciarão e exibirão o comportamento roll forward quando seus processos de trabalho forem reciclados e receberem sua primeira solicitação.

Observação

Para obter informações sobre a Configuração Compartilhada do IIS, consulte Módulo do ASP.NET Core com a Configuração Compartilhada do IIS.

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, use o WebPI (Web Platform Installer) ou os Downloads do IIS: Implantação da Web. O método preferencial é usar o WebPI. O WebPI oferece uma instalação autônoma e uma configuração para provedores de hospedagem.

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:

    Forneça o Nome do site, o caminho físico e o Nome do host na etapa Adicionar Site.

    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:

    Defina Sem Código Gerenciado para a versão do CLR do .NET.

    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.

  7. ASP.NET Core 2.2 ou posterior: para uma implantação autocontida de 64 bits (x64) que usa o modelo de hospedagem em processo, desabilite o pool de aplicativos para processos de 32 bits (x86).

    Na barra lateral Ações do Gerenciador do IIS >Pools de Aplicativos, selecione Definir Padrões do Pool de Aplicativos ou Configurações Avançadas. Localize Habilitar Aplicativos de 32 bits e defina o valor como False. Essa configuração não afeta os aplicativos implantados para a hospedagem fora do processo.

  8. 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) de 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.

Implantar o aplicativo

Implante o aplicativo na pasta caminho físico do IIS que foi estabelecida na seção Criar o site do IIS. Implantação da Web é o mecanismo recomendado para implantação, mas existem várias opções para mover o aplicativo da pasta publicar do projeto para a pasta de implantação do sistema de hospedagem.

Implantação da Web com o Visual Studio

Consulte o tópico Perfis de publicação do Visual Studio para implantação de aplicativos ASP.NET Core para saber como criar um perfil de publicação para uso com a Implantação da Web. Se o provedor de hospedagem fornecer um Perfil de Publicação ou o suporte para a criação de um, baixe o perfil e importe-o usando a caixa de diálogo Publicar do Visual Studio:

Página de caixa de diálogo Publicar

Implantação da Web fora do Visual Studio

Também é possível usar a Implantação da Web fora do Visual Studio na linha de comando. Para obter mais informações, consulte Ferramenta de Implantação da Web.

Alternativas à Implantação da Web

Use qualquer um dos vários métodos para mover o aplicativo para o sistema host, como cópia manual, Xcopy, Robocopy ou PowerShell.

Para obter mais informações sobre a implantação do ASP.NET Core no IIS, consulte a seção Recursos de implantação para administradores do IIS.

Procurar no site

Depois de implantar o aplicativo no sistema de hospedagem, faça uma solicitação para um dos pontos de extremidade públicos do aplicativo.

No exemplo a seguir, o site está associado a um Nome do Host IIS de www.mysite.com na Porta80. É feita uma solicitação para http://www.mysite.com:

O navegador Microsoft Edge carregou a página de inicialização do IIS.

Arquivos de implantação bloqueados

Os arquivos na pasta de implantação são bloqueados quando o aplicativo está em execução. Os arquivos bloqueados não podem ser substituídos durante a implantação. Para liberar os arquivos bloqueados em uma implantação, interrompa o pool de aplicativos usando uma das abordagens a seguir:

  • Use a Implantação da Web e referencie Microsoft.NET.Sdk.Web no arquivo do projeto. Um arquivo app_offline.htm é colocado na raiz do diretório de aplicativo da Web. Quando o arquivo estiver presente, o módulo do ASP.NET Core apenas desligará o aplicativo e servirá o arquivo app_offline.htm durante a implantação. Para obter mais informações, consulte Referência de configuração do módulo do ASP.NET Core.

  • Manualmente interrompa o pool de aplicativos no Gerenciador do IIS no servidor.

  • Use o PowerShell para remover app_offline.htm (requer o PowerShell 5 ou posterior):

    $pathToApp = 'PATH_TO_APP'

# Stop the AppPool
New-Item -Path $pathToApp app_offline.htm

# Provide script commands here to deploy the app

# Restart the AppPool
Remove-Item -Path $pathToApp app_offline.htm

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 for 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 externo aos aplicativos. Para persistir as chaves de 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 de registro no registro HKLM que é acessível apenas para a 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 de proteção de dados não são criptografadas. Garanta que as permissões de arquivo de o compartilhamento de rede sejam limitadas à conta do Windows na qual 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. Veja Configurar a proteção de dados do ASP.NET Core para obter detalhes.

  • 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 ser 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 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, 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. Configure 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.

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.

Um subaplicativo não deve incluir o módulo do ASP.NET Core como um manipulador. Se o módulo for adicionado como um manipulador em um arquivo web.config de um subaplicativo, quando tentar procurar o subaplicativo, você receberá um 500.19 Erro Interno do Servidor que referenciará o arquivo de configuração com falha.

O seguinte exemplo mostra um arquivo web.config publicado de um subaplicativo ASP.NET Core:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <aspNetCore processPath="dotnet" 
      arguments=".\MyApp.dll" 
      stdoutLogEnabled="false" 
      stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

Ao hospedar um subaplicativo não ASP.NET Core abaixo de um aplicativo ASP.NET Core, remova explicitamente o manipulador herdado no arquivo web.config do subaplicativo:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <handlers>
      <remove name="aspNetCore" />
    </handlers>
    <aspNetCore processPath="dotnet" 
      arguments=".\MyApp.dll" 
      stdoutLogEnabled="false" 
      stdoutLogFile=".\logs\stdout" />
  </system.webServer>
</configuration>

Links de ativos estáticos dentro do subaplicativo devem usar a notação de sinal de til e barra (~/). 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.

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.

Configuração do IIS com web.config

A configuração do IIS é influenciada pela seção <system.webServer> do web.config para cenários do IIS que são funcionais para aplicativos ASP.NET Core com o Módulo do ASP.NET Core. Por exemplo, a configuração do IIS é funcional para a compactação dinâmica. Se o IIS for configurado no nível do servidor para usar a compactação dinâmica, o elemento <urlCompression> no arquivo web.config do aplicativo pode desabilitá-la para um aplicativo do ASP.NET Core.

Para Mais informações, consulte os seguintes tópicos:

Para definir variáveis de ambiente para aplicativos individuais executados em pools de aplicativos isolados (compatível com o IIS 10.0+ ou posterior), veja a seção comando AppCmd.exe do tópico Variáveis de ambiente <environmentVariables> na documentação de referência do IIS.

Seções que não são usadas pelo ASP.NET Core

As seções de configuração de aplicativos ASP.NET 4.x em web.config não são usadas por aplicativos ASP.NET Core para configuração:

  • <system.web>
  • <appSettings>
  • <connectionStrings>
  • <location>

Aplicativos ASP.NET Core são configurados para usar outros provedores de configuração. Para obter mais informações, confira Configuração.

Pools de aplicativos

Ao hospedar vários sites em um servidor, é recomendável isolar os aplicativos uns dos outros, executando cada aplicativo em seu próprio pool de aplicativo. A caixa de diálogo Adicionar Site do IIS usa como padrão essa configuração. 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 do pool de aplicativos, verifique se Identity está definido para usar ApplicationPoolIdentity:

Caixa de diálogo Configurações avançadas do pool de aplicativos

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 IIS AppPool\<nome_pool_aplicativos> na área Inserir os nomes de objeto a serem selecionados. 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\<nome_pool_aplicativos> ao verificar o nome do objeto.

    Selecione a caixa de diálogo de usuários ou grupos para a pasta do aplicativo: o nome do pool de aplicativos

  6. Selecione OK.

    Selecione a caixa de diálogo de usuários ou grupos para a pasta do aplicativo: depois de selecionar

  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 o DefaultAppPool como exemplo, o comando a seguir é usado:

ICACLS C:\sites\MyWebApp /grant "IIS AppPool\DefaultAppPool":F

Para saber mais, veja o tópico icacls.

Suporte do HTTP/2

O HTTP/2 é compatível com implantações fora de processo que cumprem os seguintes requisitos básicos:

  • 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.
  • Estrutura de destino: não se aplica a implantações fora de processo, visto que a conexão HTTP/2 é manipulada inteiramente pelo IIS.
  • Conexão TLS 1.2 ou posterior

Se uma conexão HTTP/2 for estabelecida, HttpRequest.Protocol relatará HTTP/1.1.

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.

Recursos de implantação para administradores do IIS

Recursos adicionais