Inicio de la aplicación

Sugerencia

Este contenido es un extracto del libro electrónico "Blazor para desarrolladores de ASP NET Web Forms para Azure", disponible en documentos de .NET o como un PDF descargable gratuito que se puede leer sin conexión.

Descargar PDF

Las aplicaciones escritas para ASP.NET suelen tener un archivo global.asax.cs en el que se define el evento Application_Start que controla qué servicios se configuran y están disponibles para la representación en HTML y el procesamiento de .NET. En este capítulo se examinan las pequeñas diferencias en ASP.NET Core y Blazor Server.

Application_Start y Web Forms

El método predeterminado de Web Forms Application_Start ha crecido en funcionalidad con el paso de los años para administrar muchas tareas de configuración. Un nuevo proyecto de formularios web con la plantilla predeterminada en Visual Studio 2022 ahora contiene la lógica de configuración siguiente:

• RouteConfig: enrutamiento de URL de la aplicación
• BundleConfig: unión y minificación de CSS y JavaScript

Cada uno de estos archivos individuales se encuentra en la carpeta App_Start y se ejecuta solo una vez al principio de la aplicación. En la plantilla de proyecto predeterminada, RouteConfig agrega el objeto FriendlyUrlSettings para los formularios web a fin de permitir que las direcciones URL de la aplicación omitan la extensión de archivo .ASPX. La plantilla predeterminada también contiene una directiva que proporciona códigos de estado de redirección HTTP permanentes (HTTP 301) para las páginas .ASPX a la dirección URL descriptiva con el nombre de archivo que omite la extensión.

Con ASP.NET Core y Blazor, estos métodos se han simplificado y consolidado en la clase Startup, o bien se han eliminado en favor de tecnologías web comunes.

Estructura de inicio de Blazor Server

Las aplicaciones Blazor Server se sitúan sobre ASP.NET Core 3.0 o una versión posterior. Las aplicaciones web de ASP.NET Core se configuran en Program.cs o mediante un par de métodos de la clase Startup.cs. A continuación, se muestra un archivo Program.cs de ejemplo:

using BlazorApp1.Data;
using Microsoft.AspNetCore.Components;
using Microsoft.AspNetCore.Components.Web;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddServerSideBlazor();
builder.Services.AddSingleton<WeatherForecastService>();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.MapBlazorHub();
app.MapFallbackToPage("/_Host");

app.Run();

Los servicios necesarios de la aplicación se agregan a la colección WebApplicationBuilder de la instancia Services. Así es cómo los distintos servicios del marco de ASP.NET Core se configuran con el contenedor de inserción de dependencias integrado del marco. Los distintos métodos builder.Services.Add* agregan servicios que habilitan características como la autenticación, Razor Pages, el enrutamiento de controladores MVC, SignalR y las interacciones de Blazor Server, entre otras muchas. Este método no era necesario en los formularios web, ya que el análisis y el control de los archivos ASPX, ASCX, ASHX y ASMX se definían al hacer referencia a ASP.NET en el archivo de configuración web.config. Puede encontrar más información sobre la inserción de dependencias en ASP.NET Core en la documentación en línea.

Una vez que builder ha creado app, el resto de llamadas a app configuran su canalización HTTP. Con estas llamadas, desde la parte superior a la inferior se declara el middleware que controlará todas las solicitudes enviadas a la aplicación. La mayoría de estas características en la configuración predeterminada estaban diseminadas en los archivos de configuración de los formularios web y ahora se encuentran en un solo lugar para facilitar la referencia.

La configuración de la página de errores personalizada ya no se coloca en un archivo web.config, sino que ahora se configura para que se muestre siempre si el entorno de la aplicación no tiene la etiqueta Development. Además, ahora las aplicaciones ASP.NET Core están configuradas para proporcionar páginas seguras con TLS de forma predeterminada con la llamada de método UseHttpsRedirection.

A continuación, se realiza una llamada de método de configuración inesperada a UseStaticFiles. En ASP.NET Core, la compatibilidad con las solicitudes de archivos estáticos (por ejemplo, JavaScript, CSS y archivos de imagen) se debe habilitar de forma explícita, y solo se puede acceder públicamente a los archivos de la carpeta wwwroot de la aplicación.

La línea siguiente es la primera en la que se replica una de las opciones de configuración de los formularios web: UseRouting. Este método agrega el enrutador de ASP.NET Core a la canalización y se puede configurar aquí o en los archivos individuales que puede tener en cuenta para el enrutamiento. Puede encontrar más información sobre la configuración de enrutamiento en la sección Enrutamiento.

Las llamadas app.Map* finales de esta sección definen los puntos de conexión en los que escucha ASP.NET Core. Estas rutas son las ubicaciones accesibles desde la web a las que puede acceder en el servidor web y reciben contenido controlado por .NET y que se le devuelve. La primera entrada, MapBlazorHub, configura un centro de SignalR para utilizarlo en el suministro de la conexión persistente y en tiempo real al servidor en el que se controla el estado y la representación de los componentes de Blazor. La llamada de método MapFallbackToPage indica la ubicación accesible desde la web de la página que inicia la aplicación Blazor, que también configura para controlar las solicitudes de vinculación en profundidad desde el lado cliente. Verá esta característica en acción si abre un explorador y navega directamente a la ruta controlada por Blazor de la aplicación, como /counter en la plantilla de proyecto predeterminada. La solicitud se controla mediante la página de reserva _Host.cshtml, que luego ejecuta el enrutador de Blazor y representa la página del contador.

La última línea inicia la aplicación, algo que no era necesario en los formularios web (ya que se basaba en IIS para ejecutarse).

Actualización del proceso BundleConfig

Las tecnologías para la agrupación de recursos como hojas de estilos CSS y archivos JavaScript, han cambiado significativamente, con otras que proporcionan herramientas y técnicas que evolucionan con rapidez para administrar estos recursos. Con este fin, se recomienda usar una herramienta de línea de comandos de Node como Grunt, Gulp o WebPack para empaquetar los recursos estáticos.

Las herramientas de línea de comandos Grunt, Gulp y WebPack, así como sus configuraciones asociadas, se pueden agregar a la aplicación y ASP.NET Core omitirá silenciosamente esos archivos durante el proceso de compilación de la aplicación. Puede agregar una llamada para ejecutar sus tareas; para ello, incluya Target dentro del archivo del proyecto con una sintaxis similar a la siguiente que desencadenará un script de gulp y el destino min dentro de ese script.

<Target Name="MyPreCompileTarget" BeforeTargets="Build">
  <Exec Command="gulp min" />
</Target>

Puede encontrar más información sobre las dos estrategias para administrar los archivos CSS y JavaScript en la documentación de agrupación y minificación de recursos estáticos en ASP.NET Core.

AnteriorSiguiente