Host ASP.NET Core no Windows com IIS

Note

Esta não é a versão mais recente deste artigo. Para a versão atual, consulte a versão .NET 10 deste artigo.

Warning

Esta versão do ASP.NET Core não é mais suportada. Para obter mais informações, consulte a Política de suporte do .NET e do .NET Core. Para a versão atual, consulte a versão .NET 10 deste artigo.

Os Serviços de Informações da Internet (IIS) são um servidor Web flexível, seguro e gerenciável para hospedar aplicativos Web, incluindo o ASP.NET Core.

Plataformas suportadas

São suportados os seguintes sistemas operativos:

Windows 7 ou posterior
Windows Server 2012 R2 ou posterior

Há suporte para aplicativos publicados para implantação de 32 bits (x86) ou 64 bits (x64). Implante um aplicativo de 32 bits com um SDK .NET de 32 bits (x86), a menos que o aplicativo:

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

Instale o ASP.NET Core Module/Hosting Bundle

Faça o download do instalador mais recente usando o seguinte link:

Instalador atual do .NET Hosting Bundle (download direto)

Para obter mais instruções detalhadas sobre como instalar o ASP.NET Core Module, ou instalar versões diferentes, consulte Instalar o .NET Hosting Bundle.

Para baixar versões anteriores do pacote de hospedagem, consulte 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.

Configuration

Para obter orientações 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. Para obter mais informações, consulte este problema do GitHub.

Certificados de cliente opcionais

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

Recursos adicionais

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

Instale o .NET Hosting Bundle

Sistemas operativos suportados

São suportados os seguintes sistemas operativos:

Windows 7 ou posterior
Windows Server 2012 R2 ou posterior

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

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

Para obter orientações sobre solução de problemas, consulte Solução de problemas e depuração em projetos ASP.NET Core.

Plataformas suportadas

Há suporte para aplicativos publicados para implantação de 32 bits (x86) ou 64 bits (x64). Implante um aplicativo de 32 bits com um SDK .NET de 32 bits (x86), a menos que o aplicativo:

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

Os aplicativos publicados para 32 bits (x86) devem ter 32 bits habilitados para seus pools de aplicativos do IIS. Para obter mais informações, consulte a seção Criar o site do IIS.

Use um SDK .NET de 64 bits (x64) para publicar um aplicativo de 64 bits. Um ambiente de execução de 64 bits deve estar presente no sistema host.

Modelos de hospedagem

Modelo de hospedagem em processo

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

O ASP.NET Módulo Principal:

Executa a inicialização do aplicativo.
- Carrega o CoreCLR.
- Chamadas Program.Main.
Administra o ciclo de vida da solicitação nativa do IIS.

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

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

Um pedido chega da web ao driver HTTP.sys em modo kernel.
O driver roteia a solicitação nativa para o IIS na porta configurada do site, geralmente 80 (HTTP) ou 443 (HTTPS).
O ASP.NET Core Module recebe a solicitação nativa e a passa para o IIS HTTP Server (IISHttpServer). O Servidor HTTP do IIS é uma implementação de servidor em processo para o IIS que converte a solicitação de nativa para gerenciada.

Depois que o servidor HTTP do IIS processa a solicitação:

A solicitação é enviada para o pipeline de middleware ASP.NET Core.
O pipeline de middleware lida com a solicitação e a transmite como uma instância HttpContext para a lógica da aplicação.
A resposta do aplicativo é passada de volta para o IIS por meio do Servidor HTTP do IIS.
O IIS envia a resposta para o cliente que iniciou a solicitação.

A hospedagem em processo é opcional para aplicações existentes. Os modelos da Web ASP.NET Core usam o modelo de hospedagem em processo.

CreateDefaultBuilder adiciona uma instância IServer chamando o método UseIIS para inicializar o CoreCLR e hospedar o aplicativo dentro do processo de trabalho do IIS (w3wp.exe ou iisexpress.exe). Os testes de desempenho indicam que hospedar uma aplicação .NET no processo interno oferece uma taxa de transferência de pedidos significativamente maior em comparação com hospedar a aplicação fora do processo e encaminhar os pedidos para Kestrel.

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

Modelo de alojamento fora do processo

Como os aplicativos ASP.NET Core são executados em um processo separado do processo de trabalho do IIS, o ASP.NET Core Module lida com 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 for desligado ou falhar. Esse é essencialmente o mesmo comportamento visto com aplicativos executados em processo gerenciados pelo Serviço de Ativação de Processos do Windows (WAS).

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

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

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

O ASP.NET Core Module especifica a porta por meio de uma variável de ambiente na inicialização. A UseIISIntegration extensão configura o servidor para escutar no http://localhost:{PORT}. Verificações adicionais são realizadas e solicitações que não são originadas do módulo são rejeitadas. O módulo não suporta encaminhamento HTTPS. As solicitações são encaminhadas por HTTP, mesmo se recebidas pelo IIS por HTTPS.

Depois Kestrel de pegar a solicitação do módulo, a solicitação é encaminhada para o pipeline de middleware do ASP.NET Core. O pipeline de middleware lida com a solicitação e a transmite como uma instância HttpContext para a lógica da aplicação. O middleware adicionado pela Integração do IIS atualiza o esquema, o IP remoto e a base de caminho para levar em conta o encaminhamento da solicitação para Kestrel. A resposta do aplicativo é passada de volta para o IIS, que a encaminha de volta para o cliente HTTP que iniciou a solicitação.

Para obter orientação sobre a configuração do Módulo Principal do ASP.NET Core, consulte ASP.NET Core Module (ANCM) para IIS.

Para obter mais informações sobre hospedagem, consulte Host no ASP.NET Core.

Configuração da aplicação

Ativar os componentes 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 obter mais informações sobre CreateDefaultBuilder, consulte Host Genérico .NET no ASP.NET Core.

Opções 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;
});

Option	Default	Setting
`AutomaticAuthentication`	`true`	Se `true`, o Servidor IIS define o `HttpContext.User` autenticado por de Autenticação do Windows. Se `false`, o servidor fornece apenas uma identidade para `HttpContext.User` e responde a desafios quando solicitado explicitamente pelo `AuthenticationScheme`. A Autenticação do Windows deve estar habilitada no IIS para que `AutomaticAuthentication` funcione. Para obter mais informações, consulte Autenticação do Windows.
`AuthenticationDisplayName`	`null`	Define o nome para exibição mostrado aos usuários nas páginas de login.
`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 que o `MaxRequestBodySize` definido no `IISServerOptions`. Alterar o `MaxRequestBodySize` não afetará o `maxAllowedContentLength`. Para aumentar `maxAllowedContentLength`, adicione uma entrada no `web.config` para definir `maxAllowedContentLength` para um valor mais alto. Para obter mais detalhes, consulte Configuration.

Modelo de hospedagem fora de processo

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

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});

Option	Default	Setting
`AutomaticAuthentication`	`true`	Se `true`, o middleware de integração do IIS define o `HttpContext.User` autenticado por Windows Authentication. Se `false`, o middleware só fornece uma identidade para `HttpContext.User` e responde a desafios quando explicitamente solicitado pelo `AuthenticationScheme`. A Autenticação do Windows deve estar habilitada no IIS para que `AutomaticAuthentication` funcione. Para obter mais informações, consulte o tópico Autenticação do Windows .
`AuthenticationDisplayName`	`null`	Define o nome para exibição mostrado aos usuários nas páginas de login.
`ForwardClientCertificate`	`true`	Se `true` e o cabeçalho da `MS-ASPNETCORE-CLIENTCERT` solicitação estiver presente, o `HttpContext.Connection.ClientCertificate` será preenchido.

Cenários de servidor proxy e balanceador de carga

O middleware de integração do IIS e o módulo principal do ASP.NET estão configurados para encaminhar:

Esquema (HTTP/HTTPS).
Endereço IP remoto de onde o pedido teve origem.

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 e balanceadores de carga adicionais. Para obter mais informações, consulte Configurar o ASP.NET Core para trabalhar com servidores proxy e balanceadores de carga.

arquivo `web.config`

O web.config arquivo configura o ASP.NET Core Module. Criar, transformar e publicar o web.config arquivo são processos conduzidos por um alvo MSBuild _TransformWebConfig quando o projeto é publicado. Esse 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 web.config arquivo não estiver presente no projeto, o arquivo é criado com o correto processPath e arguments para configurar o ASP.NET Core Module e movido para a saída publicada.

Se um web.config arquivo estiver presente no projeto, o arquivo é transformado com o correto processPath e arguments para configurar o ASP.NET Core Module e movido para a saída publicada. A transformação não modifica as definições de configuração do IIS no arquivo.

O web.config arquivo pode fornecer definições de configuração adicionais do IIS que controlam módulos ativos do IIS. Para obter informações sobre módulos do IIS capazes de processar solicitações com aplicativos ASP.NET Core, consulte o tópico Módulos do IIS .

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

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

Ao desabilitar o SDK da Web de transformar o arquivo, o processPath e arguments deve ser definido manualmente pelo desenvolvedor. Para obter mais informações, consulte ASP.NET ANCM (Core Module) para IIS.

`web.config` localização do ficheiro

Para configurar o ASP.NET Módulo Principal corretamente, o web.config arquivo deve estar presente no caminho raiz do conteúdo (normalmente o caminho base do aplicativo) do aplicativo implantado. Este é o mesmo local que o caminho físico do site fornecido ao IIS. O web.config ficheiro é necessário na raiz da aplicação para permitir a publicação de várias aplicações usando o Web Deploy.

Arquivos confidenciais existem no caminho físico da app, como {ASSEMBLY}.runtimeconfig.json, {ASSEMBLY}.xml (comentários da documentação XML) e {ASSEMBLY}.deps.json, onde o espaço reservado {ASSEMBLY} é o nome da assemblagem. Quando o web.config arquivo está presente e o site é iniciado normalmente, o IIS não atende esses arquivos confidenciais se eles forem solicitados. Se o web.config arquivo estiver ausente, nomeado incorretamente ou incapaz de configurar o site para inicialização normal, o IIS pode servir arquivos confidenciais publicamente.

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

Transforme web.config

Se você precisar transformar web.config ao publicar, 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 Windows Server

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

Use o assistente Adicionar Funções e Recursos no menu Gerenciar ou no link Gerenciador do Servidor. Na etapa Funções de Servidor, selecione a caixa de seleção para Servidor Web (IIS).
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.
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).

Navegue até Painel de Controle>Programas>Programas e Recursos>Ativar ou desativar recursos do Windows (lado esquerdo da tela).
Abra o nó Serviços de Informações da Internet. Abra o nó Ferramentas de Gerenciamento da Web.
Marque a caixa de verificação Console de Gestão do IIS.
Marque a caixa de seleção para World Wide Web Services.
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 Windows Authentication <windowsAuthentication> e Configure Windows authentication.

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.
Se a instalação do IIS exigir uma reinicialização, reinicie o sistema.

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

Instale o pacote de hospedagem do .NET

Instale o .NET Hosting Bundle no sistema de hospedagem. O pacote instala o .NET Runtime, a Biblioteca .NET e o ASP.NET Core Module. O módulo permite que os aplicativos ASP.NET Core sejam executados atrás do IIS.

Important

Se o Pacote de Hospedagem estiver instalado antes do IIS, a instalação do pacote deverá ser reparada. Execute o instalador do Hosting Bundle novamente após a instalação do IIS.

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

Download direto (versão atual)

Faça o download do instalador usando o seguinte link:

Instalador atual do .NET Hosting Bundle (download direto)

Versões anteriores do instalador

Para obter uma versão anterior do instalador:

Navegue até a página Download .NET .
Selecione a versão .NET desejada.
Na coluna Executar aplicativos - Tempo de execução , localize a linha da versão de tempo de execução do .NET desejada.
Faça o download do instalador usando o link Hosting Bundle .

Warning

Alguns instaladores contêm versões de lançamento que atingiram seu fim de vida útil (EOL) e não são mais suportadas pela Microsoft. Para obter mais informações, consulte a política de suporte.

Instale o pacote de hospedagem

Execute o instalador no servidor. Os seguintes parâmetros estão disponíveis ao executar o instalador a partir de um shell de comando do administrador:
- OPT_NO_ANCM=1: Ignore a instalação do ASP.NET Core Module.
- OPT_NO_RUNTIME=1: Omitir a instalação do runtime do .NET. Usado quando o servidor somente hospeda implantações autónomas (SCD).
- OPT_NO_SHAREDFX=1: Ignore a instalação do ASP.NET Shared Framework (ASP.NET tempo de execução). Usado quando o servidor somente hospeda implantações autónomas (SCD).
- OPT_NO_X86=1: Ignore a instalação de tempos de execução x86. Use esse parâmetro quando souber que não hospedará aplicativos de 32 bits. Se houver alguma chance de você hospedar aplicativos de 32 bits e 64 bits no futuro, não use esse parâmetro e instale ambos os tempos de execução.
- OPT_NO_SHARED_CONFIG_CHECK=1: Desative a verificação do uso de uma Configuração Compartilhada do IIS quando a configuração compartilhada (applicationHost.config) estiver na mesma máquina que a instalação do IIS. Disponível apenas para instaladores do ASP.NET Core 2.2 ou posterior do Hosting Bundler. Para obter mais informações, consulte ASP.NET ANCM (Core Module) para IIS.
A reinicialização do IIS pega uma alteração no PATH do sistema, que é uma variável de ambiente, feita pelo instalador. Para reiniciar o servidor Web, pare o Serviço de Ativação de Processos do Windows (WAS) e, em seguida, reinicie o Serviço de Publicação na World Wide Web (W3SVC). Reinicie o sistema ou execute os seguintes comandos em um shell de comando elevado:
```
net stop was /y
net start w3svc
```

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

net stop was /y
net start w3svc

Note

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

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, use o Web Platform Installer (WebPI) ou consulte Downloads do IIS: Web Deploy. O método preferido é usar o WebPI. O WebPI oferece uma configuração independente e uma configuração para provedores de hospedagem.

Criar o site do IIS

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.
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.
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 associações wildcard de nível superior podem abrir o 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.
No nó do servidor, selecione Grupos de Aplicações.
Clique com o botão direito do mouse no pool de aplicativos do site e selecione Configurações básicas no menu de contexto.
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.
ASP.NET Core 2.2 ou posterior:
- Para uma implantação autônoma 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. No menu lateral Ações, selecione Configurações avançadas. Defina Ative aplicações de 32 bits para True.
- Para uma implantação autônoma 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.
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.

Implantar o aplicativo

Implante o aplicativo na pasta de caminho físico do IIS que foi estabelecida na seção Criar o site do IIS . A Implantação da Web é o mecanismo recomendado para implantação, mas existem várias opções para mover o aplicativo da pasta do projeto publish 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 aplicações ASP.NET Core para saber como criar um perfil de publicação para utilização com o Web Deploy. Se o provedor de hospedagem fornecer um perfil de publicação ou suporte para criar um, baixe seu perfil e importe-o usando a caixa de diálogo Publicar do Visual Studio:

Página de diálogo Publicar

Implantação da Web fora do Visual Studio

Web Deploy também pode ser usado fora do Visual Studio a partir da 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 de hospedagem, 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.

Navegue no site

Após a aplicação ser implantada no sistema de hospedagem, faça uma solicitação a um dos pontos finais públicos da aplicação.

No exemplo a seguir, o site está vinculado a um nome de host do IIS de www.mysite.com on Port80. É feito um pedido a 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 arquivos bloqueados em uma implantação, pare o pool de aplicativos usando uma das seguintes abordagens:

Use o Web Deploy e referencie Microsoft.NET.Sdk.Web no ficheiro de projeto. Um app_offline.htm arquivo é colocado na raiz do diretório do aplicativo Web. Quando o arquivo está presente, o ASP.NET Core Module desliga normalmente o aplicativo e serve o app_offline.htm arquivo durante a implantação. Para obter mais informações, consulte a referência de configuração do ASP.NET Core Module.
Pare manualmente o pool de aplicativos no Gerenciador do IIS no servidor.

Use o PowerShell para soltar 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

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 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 de registo de proteção de dados

As chaves de proteção de dados utilizadas pelas aplicações ASP.NET Core são armazenadas no registo externo às aplicações. 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 no registo HKLM que é acessível somente à conta do processo de trabalho da pool de aplicações da aplicação. 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 de proteção de dados 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. Consulte Configurar o ASP.NET Core Data Protection para obter detalhes.
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 mantidas 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 a proteção de dados no código.
Definir uma política de proteção de dados em toda a máquina

O sistema de proteção de dados tem suporte limitado para definir uma política padrão em toda a máquina 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 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 (~/). 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:

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).
Adicione o site raiz no Gerenciador do IIS com o subaplicativo em uma pasta sob o site raiz.
Clique com o botão direito do mouse na pasta do subaplicativo no Gerenciador do IIS e selecione Converter para Aplicação.
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.

Configuração do IIS com web.config

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

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

Para definir variáveis de ambiente para aplicativos individuais executados em pools de aplicativos isolados (com suporte para o IIS 10.0 ou posterior), consulte a seção de comandoAppCmd.exe do tópico Environment Variables <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 de ASP.NET no web.config não são usadas pelos aplicativos ASP.NET Core para configuração:

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

ASP.NET aplicativos principais são configurados usando outros provedores de configuração. Para obter mais informações, consulte Configuração e definições de configuração em tempo de execução do .NET

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

caixa de diálogo de definiçõ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 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:

Abra o Windows Explorer e navegue até o diretório.
Clique com o botão direito do mouse no diretório e selecione Propriedades.
No separador de Segurança, selecione o botão Editar e, em seguida, o botão Adicionar.
Selecione o botão Localizações e certifique-se de que o sistema está selecionado.
Digite IIS AppPool\{APP POOL NAME}, onde o espaço reservado {APP POOL NAME} é o nome do pool de aplicativos, na área Digite os nomes dos objetos 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 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.
Selecione OK.
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 seguinte comando é usado:

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

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 preliminares 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: Aplicações hospedadas em processo podem ser configuradas para não expirarem 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:

Navegue até Painel de Controle>Programas>Programas e Recursos>Ativar ou desativar recursos do Windows (lado esquerdo da tela).
Abra Serviços de Informações da Internet>Serviços da Rede Mundial de Computadores>Recursos de Desenvolvimento de Aplicativos.
Marque a caixa de seleção para Application Initialization.

No Windows Server 2008 R2 ou posterior:

Abra o Assistente para Adicionar Funções e Recursos .
No painel Selecionar serviços de função, abra o nó Desenvolvimento de Aplicações.
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 Preload Enabled como True. Selecione OK.

Usando web.config, adicione o elemento <applicationInitialization> com doAppInitAfterRestart definido para true aos elementos <system.webServer> no ficheiro 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:

Selecione Grupos de Aplicações no painel de Ligações.
Clique com o botão direito do mouse no pool de aplicativos do aplicativo na lista e selecione Configurações avançadas.
O tempo limite de inatividade padrão (minutos) é de 20 minutos. Defina o tempo limite de inatividade (minutos) como 0 (zero). Selecione OK.
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

Recursos de implantação para administradores do IIS

Recursos adicionais

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

Instale o .NET Hosting Bundle

Sistemas operativos suportados

São suportados os seguintes sistemas operativos:

Windows 7 ou posterior
Windows Server 2008 R2 ou posterior

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

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

Para obter orientações sobre solução de problemas, consulte Solução de problemas e depuração em projetos ASP.NET Core.

Plataformas suportadas

Há suporte para aplicativos publicados para implantação de 32 bits (x86) ou 64 bits (x64). Implante um aplicativo de 32 bits com um SDK .NET de 32 bits (x86), a menos que o aplicativo:

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

Use um SDK .NET de 64 bits (x64) para publicar um aplicativo de 64 bits. Um ambiente de execução de 64 bits deve estar presente no sistema host.

ASP.NET Core vem com Kestrel servidor, um servidor HTTP padrão de plataforma cruzada.

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 Kestrel servidor.

Como ASP.NET aplicativos principais são executados em um processo separado do processo de trabalho do IIS, o módulo lida com 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 for desligado ou falhar. Esse é essencialmente o mesmo comportamento visto com aplicativos executados em processo gerenciados pelo Serviço de Ativação de Processos do Windows (WAS).

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

ASP.NET Módulo Core

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

O módulo especifica a porta por meio de uma variável de ambiente na inicialização e o de Middleware de Integração do IIS configura o servidor para escutar http://localhost:{port}. Verificações adicionais são realizadas e solicitações que não são originadas do módulo são rejeitadas. O módulo não oferece suporte ao encaminhamento HTTPS, portanto, as solicitações são encaminhadas por HTTP, mesmo se recebidas pelo IIS por HTTPS.

Após o Kestrel apanhar a solicitação do módulo, a solicitação é encaminhada para o pipeline intermediário do ASP.NET Core. O pipeline de middleware lida com a solicitação e a transmite como uma instância HttpContext para a lógica da aplicação. O middleware adicionado pela Integração do IIS atualiza o esquema, o IP remoto e a base de caminho para levar em conta o encaminhamento da solicitação para Kestrel. A resposta do aplicativo é passada de volta para o IIS, que a envia de volta para o cliente HTTP que iniciou a solicitação.

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

O ASP.NET Core Module gera uma porta dinâmica para atribuir ao processo de back-end. CreateDefaultBuilder chama o UseIISIntegration método. UseIISIntegration configura Kestrel para ouvir em qualquer porta dinâmica no endereço IP localhost (127.0.0.1). Se a porta dinâmica for 1234, Kestrel escuta em 127.0.0.1:1234. Esta configuração substitui outras configurações de URL fornecidas por:

UseUrls
KestrelListen API
Configuração (ou opção de linha de comando --urls)

Chamadas para a API do UseUrls de Kestrel ou Listen não são necessárias ao usar o módulo. Se UseUrls ou Listen for chamado, Kestrel escuta na porta especificada somente ao executar o aplicativo sem o IIS.

Para obter orientação sobre a configuração do Módulo Principal do ASP.NET Core, consulte ASP.NET Core Module (ANCM) para IIS.

Para obter mais informações sobre hospedagem, consulte Host no ASP.NET Core.

Configuração da aplicação

Ativar os componentes 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 obter mais informações sobre CreateDefaultBuilder, consulte ASP.NET Core Web Host.

Opções IIS

Option	Default	Setting
`AutomaticAuthentication`	`true`	Se `true`, o Servidor IIS define o `HttpContext.User` autenticado por de Autenticação do Windows. Se `false`, o servidor fornece apenas uma identidade para `HttpContext.User` e responde a desafios quando solicitado explicitamente pelo `AuthenticationScheme`. A Autenticação do Windows deve estar habilitada no IIS para que `AutomaticAuthentication` funcione. Para obter mais informações, consulte Autenticação do Windows.
`AuthenticationDisplayName`	`null`	Define o nome para exibição mostrado aos usuários nas páginas de login.

services.Configure<IISOptions>(options => 
{
    options.ForwardClientCertificate = false;
});

Option	Default	Setting
`AutomaticAuthentication`	`true`	Se `true`, o middleware de integração do IIS define o `HttpContext.User` autenticado por Windows Authentication. Se `false`, o middleware só fornece uma identidade para `HttpContext.User` e responde a desafios quando explicitamente solicitado pelo `AuthenticationScheme`. A Autenticação do Windows deve estar habilitada no IIS para que `AutomaticAuthentication` funcione. Para obter mais informações, consulte o tópico Autenticação do Windows .
`AuthenticationDisplayName`	`null`	Define o nome para exibição mostrado aos usuários nas páginas de login.
`ForwardClientCertificate`	`true`	Se `true` e o cabeçalho da `MS-ASPNETCORE-CLIENTCERT` solicitação estiver presente, o `HttpContext.Connection.ClientCertificate` será preenchido.

Cenários de servidor proxy e balanceador de carga

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

ficheiro web.config

O arquivo web.config configura o ASP.NET Core Module. Criar, transformar e publicar o arquivo web.config é manipulado por um destino MSBuild (_TransformWebConfig) quando o projeto é publicado. Esse 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 o processPath e argumentos corretos para configurar o módulo principal ASP.NET e movido para a saída publicada.

Se um arquivo web.config estiver presente no projeto, o arquivo será transformado com o processPath e argumentos corretos para configurar o módulo principal ASP.NET e movido para a saída publicada. A transformação não modifica as definições de configuração do IIS no arquivo.

O arquivo web.config pode fornecer definições de configuração adicionais do IIS que controlam módulos ativos do IIS. Para obter informações sobre módulos do IIS capazes de processar solicitações com aplicativos ASP.NET Core, consulte o tópico Módulos do IIS .

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

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

Ao desabilitar o SDK da Web de transformar o arquivo, o processPath e os argumentos devem ser definidos manualmente pelo desenvolvedor. Para obter mais informações, consulte ASP.NET ANCM (Core Module) para IIS.

localização do arquivo web.config

Para configurar o ASP.NET Módulo Principal corretamente, o arquivo deweb.config deve estar presente no caminho raiz do conteúdo (normalmente o caminho da base do aplicativo) do aplicativo implantado. Este é o mesmo local que o caminho físico do site fornecido ao IIS. O ficheiro web.config é necessário na raiz da aplicação para permitir a publicação de várias aplicações usando o Web Deploy.

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 está presente e o site é iniciado normalmente, o IIS não atende esses arquivos confidenciais se eles forem solicitados. Se o arquivo web.config estiver ausente, nomeado incorretamente ou incapaz de configurar o site para inicialização normal, o IIS pode servir arquivos confidenciais publicamente.

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

Transforme web.config

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

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.

Use o assistente Adicionar Funções e Recursos no menu Gerenciar ou no link Gerenciador do Servidor. Na etapa Funções de Servidor, selecione a caixa de seleção para Servidor Web (IIS).
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 Windows Authentication <windowsAuthentication> e Configure Windows authentication.

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

Navegue até Painel de Controle>Programas>Programas e Recursos>Ativar ou desativar recursos do Windows (lado esquerdo da tela).
Abra o nó Serviços de Informações da Internet. Abra o nó Ferramentas de Gerenciamento da Web.
Marque a caixa de verificação Console de Gestão do IIS.
Marque a caixa de seleção para World Wide Web Services.
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 Windows Authentication <windowsAuthentication> e Configure Windows authentication.

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.
Se a instalação do IIS exigir uma reinicialização, reinicie o sistema.

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

Instale o pacote de hospedagem do .NET

Important

Se o Pacote de Hospedagem estiver instalado antes do IIS, a instalação do pacote deverá ser reparada. Execute o instalador do Hosting Bundle novamente após a instalação do IIS.

Download

Navegue até a página Download .NET .
Selecione a versão .NET desejada.
Na coluna Executar aplicativos - Tempo de execução , localize a linha da versão de tempo de execução do .NET desejada.
Faça o download do instalador usando o link Hosting Bundle .

Warning

Instale o pacote de hospedagem

Execute o instalador no servidor. Os seguintes parâmetros estão disponíveis ao executar o instalador a partir de um shell de comando do administrador:
- OPT_NO_ANCM=1: Ignore a instalação do ASP.NET Core Module.
- OPT_NO_RUNTIME=1: Omitir a instalação do runtime do .NET. Usado quando o servidor somente hospeda implantações autónomas (SCD).
- OPT_NO_SHAREDFX=1: Ignore a instalação do ASP.NET Shared Framework (ASP.NET tempo de execução). Usado quando o servidor somente hospeda implantações autónomas (SCD).
- OPT_NO_X86=1: Ignore a instalação de tempos de execução x86. Use esse parâmetro quando souber que não hospedará aplicativos de 32 bits. Se houver alguma chance de você hospedar aplicativos de 32 bits e 64 bits no futuro, não use esse parâmetro e instale ambos os tempos de execução.
- OPT_NO_SHARED_CONFIG_CHECK=1: Desative a verificação do uso de uma Configuração Compartilhada do IIS quando a configuração compartilhada (applicationHost.config) estiver na mesma máquina que a instalação do IIS. Disponível apenas para instaladores do ASP.NET Core 2.2 ou posterior do Hosting Bundler. Para obter mais informações, consulte ASP.NET ANCM (Core Module) para IIS.
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 pega uma alteração no PATH do sistema, que é uma variável de ambiente, feita pelo instalador.

Não é necessário parar 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 do Aplicativo.

ASP.NET Core adota o comportamento roll-forward para versões de patch de pacotes de estrutura compartilhados. Quando os aplicativos hospedados pelo IIS são reiniciados com o IIS, os aplicativos 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 também serão reiniciados e apresentarão comportamento de avanço contínuo quando os seus processos de trabalho forem reciclados e eles receberem a sua primeira solicitação.

Note

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

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, utilize o Web Platform Installer (WebPI) ou os downloads do IIS para Web Deploy. O método preferido é usar o WebPI. O WebPI oferece uma configuração independente e uma configuração para provedores de hospedagem.

Criar o site do IIS

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.
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.
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 associações wildcard de nível superior podem abrir o 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.
No nó do servidor, selecione Grupos de Aplicações.
Clique com o botão direito do mouse no pool de aplicativos do site e selecione Configurações básicas no menu de contexto.
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 área de trabalho (.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.
ASP.NET Core 2.2 ou posterior: para uma implantação autônoma de 64 bits (x64) que usa o modelo de hospedagem em processo, desative o pool de aplicativos para processos de 32 bits (x86).

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

Implantar o aplicativo

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

Implantação da Web com o Visual Studio

Página de diálogo Publicar

Implantação da Web fora do Visual Studio

Web Deploy também pode ser usado fora do Visual Studio a partir da 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 de hospedagem, 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.

Navegue no site

Após a aplicação ser implantada no sistema de hospedagem, faça uma solicitação a um dos pontos finais públicos da aplicação.

No exemplo a seguir, o site está vinculado a um nome de host do IIS de www.mysite.com on Port80. É feito um pedido a http://www.mysite.com:

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

Arquivos de implantação bloqueados

Use o Web Deploy e referencie Microsoft.NET.Sdk.Web no ficheiro de projeto. Um app_offline.htm arquivo é colocado na raiz do diretório do aplicativo Web. Quando o arquivo está presente, o ASP.NET Core Module desliga normalmente o aplicativo e serve o app_offline.htm arquivo durante a implantação. Para obter mais informações, consulte a referência de configuração do ASP.NET Core Module.
Pare manualmente o pool de aplicativos no Gerenciador do IIS no servidor.

Use o PowerShell para soltar 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

Se o porta-chaves 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 de registo de proteção de dados

As chaves de proteção de dados utilizadas pelas aplicações ASP.NET Core são armazenadas no registo externo às aplicações. 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 no registo HKLM que é acessível somente à conta do processo de trabalho da pool de aplicações da aplicação. 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 de proteção de dados 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. Consulte Configurar o ASP.NET Core Data Protection para obter detalhes.
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 mantidas 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 a proteção de dados no código.
Definir uma política de proteção de dados em toda a máquina

O sistema de proteção de dados tem suporte limitado para definir uma política padrão em toda a máquina 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 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.

Um subaplicativo não deve incluir o ASP.NET Core Module como manipulador. Se o módulo for adicionado como um manipulador no arquivo web.config de um subaplicativo, um erro interno do servidor 500.19 fazendo referência ao arquivo de configuração defeituoso será recebido ao tentar navegar no subaplicativo.

O exemplo a seguir mostra um arquivo deweb.config publicado para 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 non-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>

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

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).
Adicione o site raiz no Gerenciador do IIS com o subaplicativo em uma pasta sob o site raiz.
Clique com o botão direito do mouse na pasta do subaplicativo no Gerenciador do IIS e selecione Converter para Aplicação.
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.

Configuração do IIS com web.config

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

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

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

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

ASP.NET aplicativos principais são configurados usando outros provedores de configuração. Para obter mais informações, consulte Configuração.

Pools de Aplicações

Ao hospedar vários sites em um servidor, recomendamos isolar os aplicativos uns dos outros executando cada aplicativo em seu próprio pool de aplicativos. A caixa de diálogo Adicionar Site do IIS assume como padrão essa configuração. 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

caixa de diálogo de definições avançadas do pool de aplicativos

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:

Abra o Windows Explorer e navegue até o diretório.
Clique com o botão direito do mouse no diretório e selecione Propriedades.
No separador de Segurança, selecione o botão Editar e, em seguida, o botão Adicionar.
Selecione o botão Localizações e certifique-se de que o sistema está selecionado.
Digite IIS AppPool\<app_pool_name> na área Digite os nomes dos objetos a 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 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> ao verificar o nome do objeto.
Selecione OK.
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 seguinte comando é usado:

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

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

Suporte HTTP/2

HTTP/2 é suportado para implantações fora do processo que atendem aos seguintes requisitos básicos:

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.
Estrutura de destino: Não aplicável a implantações fora do processo, uma vez que a conexão HTTP/2 é tratada inteiramente pelo IIS.
Conexão TLS 1.2 ou posterior

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

Pedidos preliminares 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 permitir a passagem de solicitações OPTIONS, consulte Habilitar solicitações de origem cruzada na API Web ASP.NET 2: Como o CORS funciona no ASP.NET.

Partilhar via

Host ASP.NET Core no Windows com IIS

Plataformas suportadas

Instale o ASP.NET Core Module/Hosting Bundle

Introdução

Configuration

Recursos de implantação para administradores do IIS

Reciclagem sobreposta

Certificados de cliente opcionais

Recursos adicionais

Sistemas operativos suportados

Plataformas suportadas

Modelos de hospedagem

Modelo de hospedagem em processo

Modelo de alojamento fora do processo

Configuração da aplicação

Ativar os componentes IISIntegration

Opções IIS

Cenários de servidor proxy e balanceador de carga

arquivo web.config

web.config localização do ficheiro

Transforme web.config

Configuração do IIS

Instale o pacote de hospedagem do .NET

Download direto (versão atual)

Versões anteriores do instalador

Instale o pacote de hospedagem

Instalar o Web Deploy ao publicar com o Visual Studio

Criar o site do IIS

Implantar o aplicativo

Implantação da Web com o Visual Studio

Implantação da Web fora do Visual Studio

Alternativas à implantação da Web

Navegue no site

Arquivos de implantação bloqueados

Proteção de dados

Diretórios Virtuais

Sub-applications

Configuração do IIS com web.config

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

Pools de Aplicações

Pool de aplicativos Identity

Suporte HTTP/2

Pedidos preliminares CORS

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

Módulo de inicialização de aplicativos

Tempo Limite de Inatividade

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

Recursos de implantação para administradores do IIS

Recursos adicionais

Sistemas operativos suportados

Plataformas suportadas

Configuração da aplicação

Ativar os componentes IISIntegration

Opções IIS

Cenários de servidor proxy e balanceador de carga

ficheiro web.config

localização do arquivo web.config

Transforme web.config

Configuração do IIS

Instale o pacote de hospedagem do .NET

Download

Instale o pacote de hospedagem

Instalar o Web Deploy ao publicar com o Visual Studio

Criar o site do IIS

Implantar o aplicativo

Implantação da Web com o Visual Studio

Implantação da Web fora do Visual Studio

Alternativas à implantação da Web

Navegue no site

Arquivos de implantação bloqueados

Proteção de dados

Diretórios Virtuais

Sub-applications

Configuração do IIS com web.config

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

Pools de Aplicações

Pool de aplicativos Identity

Suporte HTTP/2

Pedidos preliminares CORS

arquivo `web.config`

`web.config` localização do ficheiro