Hospede e implante ASP.NET Core Blazor WebAssembly

Este artigo explica como hospedar e implantar aplicativos Blazor WebAssembly.

Com o modelo de hospedagem Blazor WebAssembly:

• O aplicativo Blazor, suas dependências e o tempo de execução do .NET são baixados para o navegador em paralelo.
• O aplicativo é executado diretamente no thread da interface do usuário do navegador.

Este artigo refere-se ao cenário de implantação em que o aplicativo Blazor é colocado em um servidor Web de hospedagem estática ou serviço, o .NET não é usado para servir o aplicativo Blazor. Essa estratégia é abordada na seção Implantação autônoma e em outros artigos neste nó para páginas do IIS, serviços do Azure, Apache, Nginx e GitHub.

Hospedagem de subdomínio e subaplicativo do IIS

A hospedagem de subdomínio não requer configuração especial do aplicativo. Você não precisa configurar o caminho base da aplicação (a etiqueta <base> em wwwroot/index.html) para hospedar a aplicação em um subdomínio.

A hospedagem de subaplicações do IIS requer que seja definido o caminho base da aplicação. Para obter mais informações e hiperligações para orientações adicionais sobre o alojamento de subaplicações do IIS, consulte Host e implantar ASP.NET Core Blazor.

Reduzir o tamanho máximo do heap para alguns navegadores em dispositivos móveis

Ao criar uma aplicação Blazor que é executada no cliente (projeto.Client de uma aplicação Blazor Web App ou aplicação independente Blazor WebAssembly) e que tem como alvo navegadores de dispositivos móveis, especialmente o Safari no iOS, pode ser necessário reduzir a memória máxima para a aplicação, utilizando a propriedade MSBuild EmccMaximumHeapSize. O valor padrão é 2.147.483.648 bytes, o que pode ser muito grande e resultar na falha do aplicativo se o aplicativo tentar alocar mais memória com o navegador falhando em concedê-lo. O exemplo a seguir define o valor como 268.435.456 bytes no arquivo Program:

<EmccMaximumHeapSize>268435456</EmccMaximumHeapSize>

Para obter mais informações sobre as propriedades e alvos do Mono/WebAssembly MSBuild, consulte dotnet/runtime ( repositório GitHub).

Formato de empacotamento Webcil para conjuntos .NET

Webcil é um formato de empacotamento amigável para a Web para assemblies .NET projetado para permitir o uso de Blazor WebAssembly em ambientes de rede restritivos. Os arquivos Webcil utilizam um invólucro WebAssembly padrão, em que os assemblies são implantados como arquivos WebAssembly que utilizam a extensão de arquivo padrão .wasm.

Webcil é o formato de empacotamento padrão quando você publica um aplicativo Blazor WebAssembly. Para desabilitar o uso do Webcil, defina a seguinte propriedade MSBuild no arquivo de projeto do aplicativo:

<PropertyGroup>
  <WasmEnableWebcil>false</WasmEnableWebcil>
</PropertyGroup>

Personalizar como os recursos de inicialização são carregados

Personalize como os recursos de inicialização são carregados usando a API loadBootResource. Para obter mais informações, consulte ASP.NET Core Blazor startup.

Compressão

Quando um aplicativo Blazor WebAssembly é publicado, a saída é compactada estaticamente durante a publicação para reduzir o tamanho do aplicativo e remover a sobrecarga para compactação em tempo de execução. Os seguintes algoritmos de compressão são usados:

• Brotli (nível mais alto)
• Gzip

Blazor depende do host para servir os arquivos compactados apropriados. Ao hospedar um aplicativo autônomo Blazor WebAssembly, pode ser necessário trabalho adicional para garantir que os arquivos compactados estaticamente sejam servidos:

• Para a configuração de compactação do IIS web.config, consulte a seção IIS: Brotli e Gzip compression.
• Ao hospedar em soluções de hospedagem estática que não suportam negociação de conteúdo de arquivo compactado estaticamente, considere configurar o aplicativo para buscar e decodificar arquivos compactados Brotli:

Obtenha o decodificador JavaScript Brotli do repositório google/brotli GitHub. O arquivo decodificador minificado é chamado decode.min.js e encontrado na pasta js do repositório.

Observação

Se a versão minificada do script decode.js (decode.min.js) falhar, tente usar a versão não minificada (decode.js) em vez disso.

Atualize o aplicativo para usar o decodificador.

No arquivo wwwroot/index.html, defina autostart como false na tag Blazor do <script>:

<script src="_framework/blazor.webassembly.js" autostart="false"></script>

Depois da tag Blazor de <script>e antes da tag de fechamento </body>, adicione o bloco de código JavaScript <script>. A função a seguir chama fetch com cache: 'no-cache' para manter o cache do navegador atualizado.

Blazor Web App:

<script type="module">
  import { BrotliDecode } from './decode.min.js';
  Blazor.start({
    webAssembly: {
      loadBootResource: function (type, name, defaultUri, integrity) {
        if (type !== 'dotnetjs' && location.hostname !== 'localhost' && type !== 'configuration' && type !== 'manifest') {
          return (async function () {
            const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
            if (!response.ok) {
              throw new Error(response.statusText);
            }
            const originalResponseBuffer = await response.arrayBuffer();
            const originalResponseArray = new Int8Array(originalResponseBuffer);
            const decompressedResponseArray = BrotliDecode(originalResponseArray);
            const contentType = type === 
              'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
            return new Response(decompressedResponseArray, 
              { headers: { 'content-type': contentType } });
          })();
        }
      }
    }
  });
</script>

Blazor WebAssembly: independente

<script type="module">
  import { BrotliDecode } from './decode.min.js';
  Blazor.start({
    loadBootResource: function (type, name, defaultUri, integrity) {
      if (type !== 'dotnetjs' && location.hostname !== 'localhost' && type !== 'configuration') {
        return (async function () {
          const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
          if (!response.ok) {
            throw new Error(response.statusText);
          }
          const originalResponseBuffer = await response.arrayBuffer();
          const originalResponseArray = new Int8Array(originalResponseBuffer);
          const decompressedResponseArray = BrotliDecode(originalResponseArray);
          const contentType = type === 
            'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
          return new Response(decompressedResponseArray, 
            { headers: { 'content-type': contentType } });
        })();
      }
    }
  });
</script>

Para obter mais informações sobre como carregar recursos de boot, consulte ASP.NET Core Blazor startup.

Para desabilitar a compactação, adicione a propriedade CompressionEnabled MSBuild ao arquivo de projeto do aplicativo e defina o valor como false:

<PropertyGroup>
  <CompressionEnabled>false</CompressionEnabled>
</PropertyGroup>

A propriedade CompressionEnabled pode ser passada para o comando dotnet publish com a seguinte sintaxe em um shell de comando:

dotnet publish -p:CompressionEnabled=false

Reescrever URLs para roteamento correto

Rotear solicitações para componentes de página em um aplicativo Blazor WebAssembly não é tão simples quanto rotear solicitações em um aplicativo Blazor Server. Considere um aplicativo Blazor WebAssembly com dois componentes:

• Main.razor: Carrega na raiz do aplicativo e contém um link para o componente About (href="About").
• About.razor: About componente.

Quando o documento padrão do aplicativo é solicitado usando a barra de endereço do navegador (por exemplo, https://www.contoso.com/):

1. O navegador faz um pedido.
2. A página padrão é retornada, que geralmente é index.html.
3. index.html inicializa o aplicativo.
4. O componente Router é carregado e o componente RazorMain é renderizado.

Na página principal, selecionar o link para o componente About funciona no cliente porque o roteador Blazor impede que o navegador faça uma solicitação na Internet para www.contoso.com em busca de About e fornece ele próprio o componente About já renderizado. Todas as solicitações para pontos de extremidade internos no interior da aplicação Blazor WebAssembly funcionam da mesma maneira: as solicitações não iniciam requisições através do navegador para recursos hospedados em servidores na Internet. O roteador lida com as solicitações internamente.

Se uma solicitação for feita usando a barra de endereço do navegador para www.contoso.com/About, a solicitação falhará. Esse recurso não existe no host de Internet do aplicativo, portanto, uma resposta 404 - Não encontrado é retornada.

Como os navegadores fazem solicitações a hosts baseados na Internet para páginas do lado do cliente, os servidores Web e os serviços de hospedagem devem reescrever todas as solicitações de recursos que não estejam fisicamente no servidor para a página index.html. Quando index.html é retornado, o roteador Blazor do aplicativo assume o controle e responde com o recurso correto.

Ao implementar num servidor IIS, pode usar o Módulo de Reescrita de URL com o ficheiro publicado web.config da aplicação. Para obter mais informações, consulte Hospedar e implantar o ASP.NET Core Blazor WebAssembly com o IIS.

Implantação independente

Um standalone deployment serve o aplicativo Blazor WebAssembly como um conjunto de arquivos estáticos que são solicitados diretamente pelos clientes. Qualquer servidor de arquivos estáticos é capaz de servir o aplicativo Blazor.

Os ativos de implantação independentes são publicados no diretório /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot ou bin/Release/{TARGET FRAMEWORK}/browser-wasm/publish, onde o espaço reservado {TARGET FRAMEWORK} corresponde à estrutura de destino.

Serviço de Aplicações do Azure

Blazor WebAssembly os aplicativos podem ser implantados nos Serviços de Aplicativo do Azure no Windows, que hospeda o aplicativo no IIS.

Atualmente, não há suporte para a implantação de um aplicativo Blazor WebAssembly autônomo no Serviço de Aplicativo do Azure para Linux. Recomendamos hospedar uma aplicação Blazor WebAssembly autónoma usando Azure Static Web Apps, que dá suporte a este cenário.

Autónomo com Docker

Um aplicativo Blazor WebAssembly autônomo é publicado como um conjunto de arquivos estáticos para hospedagem por um servidor de arquivos estático.

Para hospedar o aplicativo no Docker:

• Escolha um contêiner Docker com suporte a servidor web, como Nginx ou Apache.
• Copie os ativos da pasta publish para uma pasta de local definida no servidor Web para servir arquivos estáticos.
• Aplique a configuração adicional conforme necessário para servir o aplicativo Blazor WebAssembly.

Para obter orientações de configuração, consulte os seguintes recursos:

• Artigos Nginx ou Apache
• Documentação do Docker

Valores de configuração do host

Blazor WebAssembly aplicativos podem aceitar os seguintes valores de configuração de host como argumentos de linha de comando em tempo de execução no ambiente de desenvolvimento.

Raiz do conteúdo

O argumento --contentroot define o caminho absoluto para o diretório que contém os arquivos de conteúdo do aplicativo (raiz de conteúdo). Nos exemplos a seguir, /content-root-path é o caminho raiz do conteúdo do aplicativo.

• Passe o argumento ao executar o aplicativo localmente em um prompt de comando. No diretório do aplicativo, execute:

  dotnet watch --contentroot=/content-root-path
  

• Adicione uma entrada no arquivo launchSettings.json do aplicativo no perfil IIS Express. Essa configuração é usada quando a aplicação é executada com o depurador do Visual Studio e a partir de uma linha de comandos com dotnet watch (ou dotnet run).

  "commandLineArgs": "--contentroot=/content-root-path"
  

• No Visual Studio, especifique o argumento em Propriedades>Depurar>argumentos do aplicativo. Definir o argumento na página de propriedades do Visual Studio adiciona o argumento ao arquivo launchSettings.json.

  --contentroot=/content-root-path
  

Base de trajeto

O argumento --pathbase define o caminho base da aplicação para uma execução local com um caminho de URL relativo não raiz (a tag <base>href é definida para um caminho diferente de / para os ambientes de teste e produção). Nos exemplos a seguir, /relative-URL-path é a base de caminho do aplicativo. Para obter mais informações, consulte ASP.NET Core caminho base da aplicaçãoBlazor.

Importante

Ao contrário do caminho fornecido para href da tag <base>, não inclua uma barra final (/) ao passar o valor do argumento --pathbase. Se o caminho base da aplicação for fornecido na etiqueta <base> como <base href="/CoolApp/"> (inclui uma barra no final), passe o valor como argumento da linha de comando como --pathbase=/CoolApp (sem barra no final).

• Passe o argumento ao executar o aplicativo localmente em um prompt de comando. No diretório do aplicativo, execute:

  dotnet watch --pathbase=/relative-URL-path
  

• Adicione uma entrada no arquivo launchSettings.json do aplicativo no perfil IIS Express. Essa configuração é usada ao executar o aplicativo com o Depurador do Visual Studio e a partir de um prompt de comando com dotnet watch (ou dotnet run).

  "commandLineArgs": "--pathbase=/relative-URL-path"
  

• No Visual Studio, especifique o argumento em Propriedades>Depurar>argumentos do aplicativo. Definir o argumento na página de propriedades do Visual Studio adiciona o argumento ao arquivo launchSettings.json.

  --pathbase=/relative-URL-path
  

Para obter mais informações, consulte ASP.NET Core caminho base da aplicaçãoBlazor.

URLs

O argumento --urls define os endereços IP ou endereços de host com portas e protocolos para escutar solicitações.

• Passe o argumento ao executar o aplicativo localmente em um prompt de comando. No diretório do aplicativo, execute:

  dotnet watch --urls=http://127.0.0.1:0
  

• Adicione uma entrada no arquivo launchSettings.json do aplicativo no perfil IIS Express. Essa configuração é usada ao executar o aplicativo com o Depurador do Visual Studio e a partir de um prompt de comando com dotnet watch (ou dotnet run).

  "commandLineArgs": "--urls=http://127.0.0.1:0"
  

• No Visual Studio, especifique o argumento em Propriedades>Depurar>argumentos do aplicativo. Definir o argumento na página de propriedades do Visual Studio adiciona o argumento ao arquivo launchSettings.json.

  --urls=http://127.0.0.1:0
  

Configurar o Trimmer

Blazor executa a redução de linguagem intermediária (IL) em cada compilação Release para remover IL desnecessário dos assemblies de saída. Para obter mais informações, consulte Configurar o Trimmer para ASP.NET Core Blazor.

Corrupção na implantação prévia

Normalmente, na implementação:

• Somente os arquivos que foram alterados são substituídos, o que geralmente resulta em uma implantação mais rápida.
• Os arquivos existentes que não fazem parte da nova implantação são deixados no local para uso pela nova implantação.

Em casos raros, arquivos persistentes de uma implantação anterior podem corromper uma nova implantação. A exclusão completa da implantação existente (ou do aplicativo publicado localmente antes da implantação) pode resolver o problema com uma implantação corrompida. Muitas vezes, excluir a implantação existente após é suficiente para resolver o problema, inclusive para um pipeline de compilação e implantação de DevOps.

Se você determinar que a limpeza de uma implantação anterior é sempre necessária quando um pipeline de compilação e implantação de DevOps estiver em uso, poderá adicionar temporariamente uma etapa ao pipeline de compilação para excluir a implantação anterior para cada nova implantação até solucionar a causa exata da corrupção.