Hospedar e implantar o ASP.NET Core Blazor

Este artigo explica como hospedar e implantar aplicativos Blazor.

Publicar o aplicativo

Os aplicativos são publicados para implantação na configuração de versão.

Visual Studio

1. Selecione o comando Publicar {APPLICATION} no menu Compilar, em que o espaço reservado {APPLICATION} é o nome do aplicativo.
2. Selecione o botão destino de publicação. Para publicar localmente, selecione Pasta. Selecione Próximo.
3. Ao publicar localmente, aceite o local da pasta padrão ou especifique um local diferente. Selecione Concluir para salvar o perfil. Selecione Fechar.
4. Para limpar a pasta de publicação do destino antes de publicar o aplicativo, selecione Mostrar todas as configurações. Selecione Configurações>Opções de Publicação de Arquivo>Excluir todos os arquivos existentes antes da publicação. Clique em Salvar.
5. Selecione o botão Publicar.

Visual Studio Code e .NET CLI

Abra um shell de comando no diretório raiz do projeto.

Use o dotnet publish comando para publicar o aplicativo:

dotnet publish

Antes do .NET 8, a configuração de publicação padrão é Debug. Ao publicar um aplicativo que tem como alvo o .NET 7 ou anterior, passe a opção -c|--configuration ao comando com "Release" para publicar na configuração Release.

dotnet publish -c Release

Publicar o aplicativo dispara uma restauração das dependências do projeto e compila o projeto antes de criar os ativos para implantação. Como parte do processo de build, os assemblies e métodos não usados são removidos para reduzir o tamanho de download do aplicativo e os tempos de carregamento.

Esvaziar a pasta de publicação de destino

Ao usar o dotnet publish comando em um shell de comando para publicar um aplicativo, o comando gera os arquivos necessários para implantação com base no estado atual do projeto e coloca os arquivos na pasta de saída especificada. O comando não limpa automaticamente a pasta de destino antes de publicar o aplicativo.

Para esvaziar a pasta de destino automaticamente antes que o aplicativo seja publicado, adicione o seguinte destino do MSBuild ao arquivo de projeto do aplicativo (.csproj) no elemento raiz <Project> :

<Target Name="_RemovePublishDirBeforePublishing" BeforeTargets="BeforePublish">
  <RemoveDir Directories="$(PublishDir)" Condition="'$(PublishDir)' != ''" />
</Target>

Locais de publicação padrão

• Blazor Web App: O aplicativo é publicado na pasta /bin/Release/{TARGET FRAMEWORK}/publish, em que o {TARGET FRAMEWORK} espaço reservado é a estrutura de destino. Implante o conteúdo da pasta publish no host.
• Autônomo Blazor WebAssembly: o aplicativo é publicado na pasta bin/Release/{TARGET FRAMEWORK}/publish or bin/Release/{TARGET FRAMEWORK}/browser-wasm/publish. Para implantar o aplicativo como um site estático, copie o conteúdo da pasta wwwroot para o host do site estático.

IIS

Para hospedar um aplicativo Blazor no IIS, consulte os seguintes recursos:

• Hospedagem do IIS
  • Publicar um aplicativo ASP.NET Core no IIS
  • Hospedar o ASP.NET Core no Windows com o IIS
• Hospede e implante aplicativos ASP.NET Core no lado Blazor do servidor: Blazor Web Apps (.NET 8 ou posterior) e Blazor Server aplicativos (.NET 7 ou anteriores) em execução no IIS, incluindo o IIS com VMs (Máquinas Virtuais) do Azure executando o sistema operacional Windows e o Serviço de Aplicativos do Azure.
• Hospedar e implantar ASP.NET Core Blazor WebAssembly com IIS: aplicativos autônomos Blazor WebAssembly (todas as versões do .NET) e aplicativos hospedados Blazor WebAssembly (.NET 7 ou anterior).
• Hospedagem de subaplicação do IIS
  • Siga as diretrizes do caminho base do aplicativo antes de publicar o aplicativo. Os exemplos usam um caminho base do aplicativo de /CoolApp e mostram como obter o caminho base das configurações do aplicativo ou de outros provedores de configuração.
  • Siga as diretrizes de configuração de subaplicação em Configuração avançada. O caminho da pasta do subaplicativo no site raiz torna-se o caminho virtual do subaplicativo. Para um caminho base de aplicativo /CoolApp, o aplicativo Blazor é colocado em uma pasta chamada CoolApp no site raiz e o subaplicativo assume um caminho virtual de /CoolApp.

Não há suporte para o compartilhamento de um pool de aplicativos entre aplicativos ASP.NET Core, inclusive para aplicativos Blazor. Use um pool de aplicativos por aplicativo ao hospedar com o IIS e evite o uso dos diretórios virtuais do IIS para hospedar vários aplicativos.

Suporte ao bundler JavaScript

O runtime do Blazor utiliza arquivos JavaScript (JS), o runtime .NET compilado em código WebAssembly e de assemblies gerenciados agrupados como arquivos WebAssembly. Quando um Blazor aplicativo é criado, o Blazor tempo de execução depende desses arquivos provenientes de diferentes locais de compilação. Devido a essa restrição, a saída de build de Blazor não é compatível com os empacotadores JS, como Gulp, Webpack e Rollup.

Para produzir uma saída de build compatível com empacotadores JSdurante a publicação, defina a WasmBundlerFriendlyBootConfig propriedade MSBuild como true no arquivo de projeto do aplicativo:

<WasmBundlerFriendlyBootConfig>true</WasmBundlerFriendlyBootConfig>

Importante

Este recurso gera a saída compatível com empacotadores apenas ao publicar o aplicativo.

A saída não é executável diretamente no navegador, mas pode ser utilizada por ferramentas de JS para agrupar arquivos JS com os demais scripts fornecidos pelo desenvolvedor.

Quando o WasmBundlerFriendlyBootConfig está ativado, o JS gerado contém diretivas import para todos os ativos no aplicativo, tornando as dependências visíveis para o empacotador. Muitos dos ativos não são carregáveis pelo navegador, mas os empacotadores geralmente podem ser configurados para reconhecer os ativos por seu tipo de arquivo para lidar com o carregamento. Para detalhes sobre como configurar seu empacotador, consulte a documentação do empacotador.

Observação

A saída de build de agrupamento deve ser possível ao mapear as importações para locais individuais de arquivos com um plug-in personalizado do empacotador JS. Não fornecemos esse plug-in no momento.

Observação

A substituição do plug-in files por url faz com que todos os arquivos do aplicativo JS, incluindo o runtime Blazor-WebAssembly (codificado em base64 no JS), sejam agrupados na saída. O tamanho do arquivo é significativamente maior (por exemplo, 300% a mais) do que quando os arquivos são curados com o plugin files, portanto, não recomendamos usar o plugin url como prática geral ao produzir uma saída compatível com o processamento do empacotador JS.

Os aplicativos de exemplo a seguir são baseados no Rollup. Conceitos semelhantes se aplicam ao usar outros JS bundlers.

Aplicativos de exemplo de demonstração para Blazor WebAssembly um aplicativo React (BlazorWebAssemblyReact) e .NET no WebAssembly em um aplicativo React (DotNetWebAssemblyReact) para .NET 10 ou posterior estão disponíveis no Blazor repositório GitHub de exemplos (dotnet/blazor-samples).

Aspectos do Blazor WebAssembly cache se aplicam a Blazor Web Apps

Blazor O cache de pacotes e as Blazor WebAssembly diretrizes de cache HTTP no nó se concentram em aplicativos autônomos Blazor WebAssembly , mas vários aspectos do cache do lado do cliente nestes artigos também se aplicam a Blazor Web Apps que adotam modos interativos de webassembly ou renderização automática interativa. Se um Blazor Web App que renderiza conteúdo no lado do cliente encontrar um problema de cache de ativo estático ou pacote, veja as orientações nestes artigos para solucionar o problema:

• falhas de verificação de integridade e cache do ASP.NET Core Blazor WebAssembly
• Evitar problemas de cache HTTP ao atualizar aplicativos do ASP.NET Core Blazor

Blazor Server MapFallbackToPage configuração

Esta seção só se aplica a aplicativos Blazor Server. MapFallbackToPage não é compatível em Blazor Web Apps e aplicativos Blazor WebAssembly.

Em cenários em que um aplicativo requer uma área separada com recursos personalizados e componentes Razor:

• Crie uma pasta dentro da pasta Pages do aplicativo para manter os recursos. Por exemplo, uma seção de administrador de um aplicativo é criada em uma nova pasta chamada Admin (Pages/Admin).

• Crie uma página raiz (_Host.cshtml) para a área. Por exemplo, crie um arquivo Pages/Admin/_Host.cshtml na página raiz principal do aplicativo (Pages/_Host.cshtml). Não forneça uma diretiva @page na página _Host do Administrador.

• Adicione um layout à pasta da área (por exemplo, Pages/Admin/_Layout.razor). No layout da área separada, defina a marca <base>href para corresponder à pasta da área (por exemplo, <base href="/Admin/" />). Para fins de demonstração, adicione ~/ aos recursos estáticos na página. Por exemplo:

  • ~/css/bootstrap/bootstrap.min.css
  • ~/css/site.css
  • ~/BlazorSample.styles.css (o namespace do aplicativo de exemplo é BlazorSample)
  • ~/_framework/blazor.server.js (script Blazor)

• Se a área deve ter a própria pasta de ativo estático, adicione a pasta e especifique seu local para o Middleware de Arquivo Estático em Program.cs (por exemplo, app.UseStaticFiles("/Admin/wwwroot")).

• Componentes Razor são adicionados à pasta da área. No mínimo, adicione um componente Index à pasta da área com a diretiva @page correta para a área. Por exemplo, adicione um arquivo Pages/Admin/Index.razor com base no arquivo Pages/Index.razor padrão do aplicativo. Indique a área do Administrador como o modelo de rota na parte superior do arquivo (@page "/admin"). Adicione componentes adicionais conforme necessário. Por exemplo, Pages/Admin/Component1.razor com uma diretiva @page e um modelo de rota de @page "/admin/component1.

• Em Program.cs, chame MapFallbackToPage para o caminho de solicitação da área imediatamente antes do caminho da página raiz de fallback para a página _Host:

  ...
  app.UseRouting();
  
  app.MapBlazorHub();
  app.MapFallbackToPage("~/Admin/{*clientroutes:nonfile}", "/Admin/_Host");
  app.MapFallbackToPage("/_Host");
  
  app.Run();