Hospedaje e implementación de ASP.NET Core Blazor WebAssembly

En este artículo se explica cómo hospedar e implementar aplicaciones de Blazor WebAssembly.

Con el Blazor WebAssembly modelo de hospedaje:

• La aplicación Blazor, sus dependencias y el entorno de ejecución de .NET se descargan en el explorador en paralelo.
• La aplicación se ejecuta directamente en el subproceso de interfaz de usuario del explorador.

Este artículo pertenece al escenario de implementación donde la aplicación Blazor se coloca en un servidor o servicio web de hospedaje estático; .NET no se usa para suministrar la aplicación Blazor. Esta estrategia se trata en la sección implementación Standalone y en otros artículos de este nodo para IIS, servicios Azure, Apache, Nginx y GitHub Pages.

Hospedaje de subdominios y subaplicaciones de IIS

El hospedaje de subdominios no requiere una configuración especial de la aplicación. No es necesario configurar la ruta de acceso base de la aplicación (la etiqueta <base> en wwwroot/index.html) para hospedar la aplicación en un subdominio.

El hospedaje de sub-aplicaciones en IIS requiere que usted establezca la ruta base de la aplicación. Para obtener más información y vínculos cruzados para obtener instrucciones adicionales sobre el hospedaje de aplicaciones secundarias de IIS, consulte Hospedaje e implementación de ASP.NET Core Blazor.

Reducir el tamaño máximo del montón para algunos exploradores de dispositivo móvil

Al compilar una aplicación Blazor que se ejecuta en el cliente (proyecto .Client de una app Blazor Web App o Blazor WebAssembly independiente) y tiene como destino exploradores de dispositivos móviles, especialmente Safari en iOS, la disminución de la memoria máxima de la aplicación con la propiedad MSBuild EmccMaximumHeapSize puede ser necesaria. El valor predeterminado es 2 147 483 648 bytes, que puede ser demasiado grande y provocar el bloqueo de la aplicación si intenta asignar más memoria y el navegador no se la concede. En el ejemplo siguiente se establece el valor en 268 435 456 bytes en el archivo Program:

<EmccMaximumHeapSize>268435456</EmccMaximumHeapSize>

Para obtener más información sobre las propiedades y destinos de MSBuild de Mono/WebAssembly, consulte WasmApp.Common.targets (repositorio de GitHub dotnet/runtime).

Formato de empaquetado Webcil para ensamblados .NET

Webcil es un formato de empaquetado compatible con la web para ensamblados .NET diseñados para permitir el uso de Blazor WebAssembly en entornos de red restrictivos. Los archivos Webcil usan un contenedor WebAssembly estándar, donde los ensamblados se implementan como archivos WebAssembly que usan la extensión de archivo estándar .wasm.

Webcil es el formato de empaquetado predeterminado al publicar una aplicación Blazor WebAssembly. Para deshabilitar el uso de Webcil, establezca la siguiente propiedad MSBuild en el archivo de proyecto de la aplicación:

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

Personalización de la carga de los recursos de arranque

Personalice la forma en que se cargan los recursos de arranque mediante la API loadBootResource. Para obtener más información, vea Inicio de Blazor de ASP.NET Core.

Compresión

Cuando se publica una aplicación Blazor WebAssembly, la salida se comprime estáticamente durante la publicación para reducir el tamaño de la aplicación y acabar con la necesidad de compresión en tiempo de ejecución. Se usan los algoritmos de compresión siguientes:

• Brotli (el nivel más alto)
• Gzip

Blazor se basa en el host para proporcionar los archivos comprimidos adecuados. Al hospedar una aplicación independiente Blazor WebAssembly, puede que sea necesario realizar trabajo adicional para garantizar que se proporcionan los archivos comprimidos estáticamente:

• Para la configuración de compresión de IIS web.config, consulte la sección IIS: compresión Brotli y Gzip.
• Al hospedar en soluciones de hospedaje estáticas que no admiten la negociación de contenido de archivos comprimidos estáticamente, considere la posibilidad de configurar la aplicación para capturar y descodificar archivos comprimidos Brotli:

Obtenga el descodificador Brotli de JavaScript del repositorio de GitHub google/brotli. El archivo del descodificador minificado se llama decode.min.js y se encuentra en la carpeta js del repositorio.

Nota:

Si se produce un error en la versión minificada del script decode.js (decode.min.js), en su lugar, pruebe a usar la versión no minificada (decode.js).

Actualice la aplicación para que use el descodificador.

En el archivo wwwroot/index.html, establezca autostart en false en la etiqueta Blazor de <script>:

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

Después de la etiqueta Blazor de <script> y antes de la etiqueta de cierre </body>, agregue el siguiente bloque <script> de código de JavaScript. La función siguiente llama a fetch con cache: 'no-cache' para mantener actualizada la memoria caché del explorador.

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 independiente:

<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 obtener más información sobre la carga de los recursos de arranque, vea Inicio de Blazor de ASP.NET Core.

Para deshabilitar la compresión, agregue la propiedad CompressionEnabled de MSBuild al archivo del proyecto de la aplicación y establezca el valor en false:

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

La propiedad CompressionEnabled se puede pasar al comando dotnet publish con la sintaxis siguiente en un shell de comandos:

dotnet publish -p:CompressionEnabled=false

Reescritura de las URL para conseguir un enrutamiento correcto

Enrutar las solicitudes de los componentes de página de una aplicación Blazor WebAssembly no es tan sencillo como enrutar las solicitudes de una aplicación Blazor Server. Imagine que tiene una aplicación Blazor WebAssembly con dos componentes:

• Main.razor: se carga en la raíz de la aplicación y contiene un vínculo al componente About (href="About").
• About.razor: componente About.

Cuando se solicita el documento predeterminado de la aplicación mediante la barra de direcciones del explorador (por ejemplo, https://www.contoso.com/):

1. El explorador realiza una solicitud.
2. Se devuelve la página predeterminada, que suele ser index.html.
3. index.html inicializa la aplicación.
4. Router carga el componente y se representa el componente RazorMain.

En la página principal, la selección del vínculo al componente About funciona en el cliente porque el enrutador de Blazor impide que el explorador haga una solicitud en Internet a www.contoso.com sobre About y presenta el propio componente About representado. Todas las solicitudes de puntos de conexión internos dentro de la aplicación Blazor WebAssembly funcionan del mismo modo: Las solicitudes no desencadenan solicitudes basadas en el explorador a recursos hospedados en el servidor en Internet. El enrutador controla las solicitudes de forma interna.

Si se realiza una solicitud mediante la barra de direcciones del explorador para www.contoso.com/About, se produce un error. Este recurso no existe en el host de Internet de la aplicación, por lo que se devuelve una respuesta 404 No encontrado.

Dado que los exploradores solicitan páginas del lado cliente a hosts basados en Internet, los servidores web y los servicios de hospedaje deben reescribir todas las solicitudes de recursos que no estén físicamente en el servidor a la página index.html. Cuando se devuelve index.html, el enrutador Blazor de la aplicación se hace cargo y responde con el recurso correcto.

Al implementar en un servidor IIS, puede usar el módulo URL Rewrite con el archivo web.config publicado de la aplicación. Para más información, vea Hospedaje e implementación de ASP.NET Core Blazor WebAssembly con ISS.

Implementación independiente

Una implementación independiente suministra la aplicación Blazor WebAssembly como un conjunto de archivos estáticos que los clientes solicitan directamente. Cualquier servidor de archivos estático es capaz de suministrar la aplicación Blazor.

Los recursos de implementación independientes se publican en la carpeta /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot o bin/Release/{TARGET FRAMEWORK}/browser-wasm/publish, donde el marcador de posición {TARGET FRAMEWORK} es la plataforma de destino.

Azure App Service

Las aplicaciones Blazor WebAssembly se pueden implementar en Azure App Services en Windows, que hospeda la aplicación en IIS.

Actualmente no se admite la implementación de una aplicación Blazor WebAssembly independiente en Azure App Service para Linux. Se recomienda hospedar una aplicación independiente Blazor WebAssembly mediante Azure Static Web Apps, que admite este escenario.

Independiente con Docker

Una aplicación independiente Blazor WebAssembly se publica como un conjunto de archivos estáticos que hospeda un servidor de archivos estáticos.

Para hospedar la aplicación en Docker:

• Elija un contenedor de Docker con compatibilidad con el servidor web, como Nginx o Apache.
• Copie los recursos de la carpeta publish en una carpeta de ubicación definida en el servidor web para atender archivos estáticos.
• Aplique la configuración adicional según sea necesario para atender la aplicación Blazor WebAssembly.

Para obtener orientación sobre la configuración, consulte los siguientes recursos:

• Artículos Nginx o Apache
• Documentación de Docker.

Valores de configuración de host

Las aplicaciones Blazor WebAssembly pueden aceptar los siguientes valores de configuración de host como argumentos de línea de comandos en tiempo de ejecución en el entorno de desarrollo.

Raíz del contenido

El argumento --contentroot establece la ruta de acceso absoluta al directorio que incluye los archivos de contenido de la aplicación (raíz del contenido). En los ejemplos siguientes, /content-root-path es la ruta de acceso raíz del contenido de la aplicación.

• Pase el argumento al ejecutar la aplicación de forma local en un símbolo del sistema. En el directorio de la aplicación, ejecute lo siguiente:

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

• Agregue una entrada al archivo launchSettings.json de la aplicación en el perfil IIS Express. Esta configuración se utiliza cuando se ejecuta la aplicación mediante el depurador de Visual Studio y desde una línea de comandos con dotnet watch (o dotnet run).

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

• En Visual Studio, especifique el argumento en Propiedades>Depuración>Argumentos de la aplicación. Al establecer el argumento en la página de propiedades de Visual Studio, se agrega el argumento al archivo launchSettings.json.

  --contentroot=/content-root-path
  

Ruta de acceso base

El argumento --pathbase establece la ruta de acceso base de la aplicación para una aplicación que se ejecuta localmente con una ruta de acceso de URL relativa que no es raíz (el valor <base> de la etiqueta href se establece en una ruta de acceso que no sea / para ensayo y producción). En los ejemplos siguientes, /relative-URL-path es la ruta de acceso base de la aplicación. Para obtener más información, consulte ASP.NET Core Blazor app base path.

Importante

A diferencia de la ruta de acceso proporcionada al valor href de la etiqueta <base>, no incluya una barra diagonal final (/) al pasar el valor del argumento --pathbase. Si se proporciona la ruta de acceso base de la aplicación en la etiqueta <base> como <base href="/CoolApp/"> (se incluye una barra diagonal final), se pasa el valor del argumento de línea de comandos como --pathbase=/CoolApp (sin barra diagonal final).

• Pase el argumento al ejecutar la aplicación de forma local en un símbolo del sistema. En el directorio de la aplicación, ejecute lo siguiente:

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

• Agregue una entrada al archivo launchSettings.json de la aplicación en el perfil IIS Express. Esta configuración se utiliza al ejecutar la aplicación usando el depurador de Visual Studio y desde una línea de comandos con dotnet watch (o dotnet run).

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

• En Visual Studio, especifique el argumento en Propiedades>Depuración>Argumentos de la aplicación. Al establecer el argumento en la página de propiedades de Visual Studio, se agrega el argumento al archivo launchSettings.json.

  --pathbase=/relative-URL-path
  

Para obtener más información, consulte ASP.NET Core Blazor app base path.

Direcciones web URL

El argumento --urls establece las direcciones IP o de host junto con los puertos y protocolos en los que se deben recibir las solicitudes.

• Pase el argumento al ejecutar la aplicación de forma local en un símbolo del sistema. En el directorio de la aplicación, ejecute lo siguiente:

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

• Agregue una entrada al archivo launchSettings.json de la aplicación en el perfil IIS Express. Esta configuración se utiliza al ejecutar la aplicación usando el depurador de Visual Studio y desde una línea de comandos con dotnet watch (o dotnet run).

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

• En Visual Studio, especifique el argumento en Propiedades>Depuración>Argumentos de la aplicación. Al establecer el argumento en la página de propiedades de Visual Studio, se agrega el argumento al archivo launchSettings.json.

  --urls=http://127.0.0.1:0
  

Configurar el recortador

Blazor realiza el recorte de lenguaje intermedio (IL) en cada compilación de lanzamiento para quitar el IL innecesario de los ensamblados de salida. Para más información, vea Configuración del recortador de ASP.NET Core Blazor.

Corrupción en el despliegue anterior

Normalmente, en la implementación:

• Solo se reemplazan los archivos que han cambiado, lo que normalmente da lugar a una implementación más rápida.
• Los archivos existentes que no forman parte de la nueva implementación se dejan en su lugar para ser usados por la nueva implementación.

En raras ocasiones, los archivos persistentes de una implementación anterior pueden dañar una nueva implementación. La eliminación completa de la implementación existente (o la aplicación publicada localmente antes de la implementación) puede resolver el problema con una implementación dañada. A menudo, la eliminación de la implementación existente una vez es suficiente para resolver el problema, incluidos los DevOps compilación e implementación de la canalización.

Si determina que siempre es necesario borrar una implementación anterior cuando se está utilizando una canalización de compilación e implementación de DevOps, puede agregar temporalmente un paso a la canalización de compilación para eliminar la implementación anterior de cada nueva implementación hasta que solucione la causa exacta de los daños.