Hospede e implante ASP.NET Core Blazor

Este artigo explica como hospedar e implantar aplicativos Blazor.

Publicar o aplicativo

As aplicações são publicadas para implantação na configuração de lançamento.

Estúdio Visual

1. Selecione o comando Publish {APPLICATION} no menu Build, onde o {APPLICATION} representa o nome da aplicação.
2. Selecione o destino de publicação . Para publicar localmente, selecione Pasta. Selecione Seguinte.
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 arquivoExclua todos os arquivos existentes antes de publicar. Selecione Guardar.
5. Selecione o botão Publicar.

Código do Visual Studio e CLI do .NET

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 uma aplicação destinada ao .NET 7 ou anterior, passe a -c|--configuration opção para o comando com "Release" para publicar na configuração Release:

dotnet publish -c Release

A publicação da aplicação aciona uma restauração das dependências do projeto e compila o projeto antes de criar os recursos para a implantação. Como parte do processo de compilação, os métodos e assemblies não utilizados são removidos para reduzir o tamanho do 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 MSBuild ao arquivo de projeto do aplicativo (.csproj) sob o 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, onde o espaço reservado para {TARGET FRAMEWORK} é a estrutura de destino. Implante o conteúdo da pasta publish no host.
• Autônomo Blazor WebAssembly: o aplicativo é publicado na bin/Release/{TARGET FRAMEWORK}/publish pasta ou 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
  • Host ASP.NET Core no Windows utilizando o IIS
• Hospede e implante aplicativos do lado Blazor do servidor ASP.NET Core: Blazor Web Apps (.NET 8 ou posterior) e Blazor Server aplicativos (.NET 7 ou anterior) em execução no IIS, incluindo o IIS com Máquinas Virtuais (VMs) do Azure executando o sistema operacional Windows e o Serviço de Aplicativo do Azure.
• Hospede e implante 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 subaplicativos do IIS
  • Siga as orientações de caminho base do aplicativo antes de publicar o aplicativo. Os exemplos usam um caminho base de 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 subaplicativos em configuração avançada. O caminho da pasta do subaplicativo sob o site raiz torna-se o caminho virtual do subaplicativo. Para um caminho base da aplicação de /CoolApp, a aplicação Blazor é colocada em uma pasta chamada CoolApp no site raiz e a sub-aplicação 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 empacotador JavaScript

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

Para produzir saída de compilação compatível com JS bundlers durante a publicação, defina a WasmBundlerFriendlyBootConfig propriedade MSBuild como true no arquivo de projeto do aplicativo:

<WasmBundlerFriendlyBootConfig>true</WasmBundlerFriendlyBootConfig>

Importante

Esse recurso só produz a saída adequada para empacotadores quando o aplicativo é publicado.

A saída não pode ser executada diretamente no navegador, mas pode ser consumida por JS ferramentas para agrupar JS arquivos com o resto dos scripts fornecidos pelo desenvolvedor.

Quando WasmBundlerFriendlyBootConfig está habilitado, o JS produzido contém as diretivas import para todos os ativos no aplicativo, o que torna as dependências visíveis para o agrupador. 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 obter detalhes sobre como configurar o bundler, consulte a documentação do bundler.

Observação

A agregação de saída de compilação deve ser possível mapeando importações para locais de arquivos individuais usando um JS plug-in personalizado do bundler. Nós não fornecemos tal plugin no momento.

Observação

Substituindo o files plug-in pelo url, todos os ficheiros do aplicativo, incluindo o runtime JS-WebAssembly (codificado em base64 no Blazor), são agrupados na saída. O tamanho do ficheiro é significativamente maior (por exemplo, 300% maior) do que quando os ficheiros são curados com o plugin files, por isso não recomendamos utilizar o plugin url como prática geral ao produzir uma saída que seja compatível com o empacotador para processamento pelo bundler 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 em um aplicativo React (BlazorWebAssemblyReact) e .NET no WebAssembly em um aplicativo React (DotNetWebAssemblyReact) para .NET 10 ou posterior estão disponíveis nos exemplos do Blazor repositório GitHub (dotnet/blazor-samples).

Aspetos do Blazor WebAssembly cache se aplicam a Blazor Web Apps

Blazor O caching de pacotes e as diretrizes de caching HTTP no Blazor WebAssembly node concentram-se em aplicações autónomas Blazor WebAssembly, mas vários aspectos do caching do lado do cliente nestes artigos também se aplicam às Blazor Web App que adotam modos de renderização Interactive WebAssembly ou Interactive Auto. Se um Blazor Web App que renderiza conteúdo no lado do cliente encontrar um problema de cache de ativo estático ou de bundle, consulte as diretrizes nestes artigos para solucionar o problema.

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

Blazor Server MapFallbackToPage configuração

Esta secção aplica-se apenas a aplicações Blazor Server. MapFallbackToPage não é suportado nas aplicações Blazor Web Appe 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 armazenar 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 a partir da página raiz principal do aplicativo (Pages/_Host.cshtml). Não forneça uma diretiva @page na página Admin _Host.

• Adicione um layout à pasta da área (por exemplo, Pages/Admin/_Layout.razor). No layout da área separada, defina a etiqueta <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 Blazor( roteiro)

• Se a área deve ter a sua própria pasta de ficheiros estáticos, adicione a pasta e especifique a sua localização ao Middleware de Ficheiro Estático em Program.cs (por exemplo, app.UseStaticFiles("/Admin/wwwroot")).

• Os componentes Razor são adicionados na pasta da área. No mínimo, adicione um componente Index à pasta da área com a diretiva correta @page 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 Admin 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.

• No 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();