Inicio de la aplicación en ASP.NET Core

El archivo Program

Las aplicaciones de ASP.NET Core inicializan y configuran el arranque en el archivo Program de la aplicación (Program.cs).

La primera parte del Program archivo se centra en la compilación de la aplicación. Esta fase utiliza WebApplication.CreateBuilder para inicializar una nueva instancia de la WebApplicationBuilder clase con valores predeterminados preconfigurados antes de iniciar la aplicación. Las plantillas de proyecto ASP.NET Core asignan el generador de aplicaciones web a una variable denominada builder:

var builder = WebApplication.CreateBuilder(args);

Entre las propiedades del generador de aplicaciones web se incluyen:

• builder.Configuration es un IConfigurationBuilder y IConfigurationRoot para administrar fuentes y proveedores de configuración. Para obtener más información, consulte Configuración en ASP.NET Core.
• builder.Environment es un IWebHostEnvironment que proporciona información sobre el entorno de alojamiento web de la aplicación. Para obtener más información, consulte entornos de ejecución de ASP.NET Core.
• builder.Host es un IHostBuilder para configurar propiedades específicas del host. Para obtener más información, consulte Hospedaje genérico de .NET en ASP.NET Core.
• builder.Logging es un ILoggingBuilder con métodos de extensión que permiten agregar y administrar proveedores de registro. Para obtener más información, consulte Registro en .NET y ASP.NET Core.
• builder.Metrics(.NET 8 o posterior) permite habilitar las métricas y dirigir su salida. Para obtener más información, consulta métricas de ASP.NET Core.
• builder.Services es un conjunto de servicios de inyección de dependencias (DI) (IServiceCollection) que la aplicación utiliza para componer la inversión de control (IoC). Para más información, consulte Inserción de dependencias en ASP.NET Core.
• builder.WebHost es una IWebHostBuilder para configurar propiedades específicas del servidor.

La aplicación se compila llamando a WebApplicationBuilder.Build, que devuelve el WebApplication compilado. Las plantillas de proyecto ASP.NET Core asignan la aplicación web compilada a una variable denominada app:

var app = builder.Build();

La siguiente parte del archivo Program se centra en configurar la canalización de procesamiento de solicitudes HTTP como una serie de componentes de middleware. Cada middleware realiza operaciones en HttpContext y bien llama al siguiente middleware de la canalización, bien pone fin a la solicitud. Por convención, los componentes de middleware se agregan a la canalización invocando un método de extensión que comienza por "Use". Para obtener más información, consulte ASP.NET Core middleware.

El método Run inicia la aplicación y bloquea el hilo que realiza la llamada hasta que el host se cierre:

app.Run();

Cuando Run se ejecuta, la aplicación realiza la transición a un proceso activo y en ejecución:

1. Se inician los servicios hospedados.

   El host recorre todos los servicios alojados registrados (IHostedService instancias) y llama a sus StartAsync métodos. A menos que la aplicación habilite el inicio concurrente de los servicios hospedados (.NET 8 o posterior), los servicios hospedados se inician secuencialmente en el orden en que se registran en el contenedor de inyección de dependencias. Para obtener más información, consulte Tareas en segundo plano con servicios hospedados en ASP.NET Core.

2. Se ha creado la canalización de middleware.

   Cuando se invoca builder.Build, se resuelven las dependencias, pero la canalización de procesamiento propiamente dicha no queda completamente configurada. Cuando app.Run se ejecuta, el marco finaliza la canalización de middleware HTTP. Los métodos de middleware declarados y las asignaciones de puntos de conexión se compilan en una única secuencia de delegados de ejecución de alto rendimiento. Para obtener más información, consulte ASP.NET Core middleware.

3. Se inicia el servidor web (Kestrel de forma predeterminada).

   El host busca dentro de su contenedor de dependencias, localiza la implementación del servidor registrado (normalmente Kestrel) y desencadena su ciclo de inicio. Kestrel a continuación:

   • Busca las direcciones URL y puertos de hospedaje definidos desde los argumentos de configuración, variables de entorno o línea de comandos.
   • Abre y asigna sockets físicos de red.
   • Enlaza los puertos y comienza a escuchar el tráfico entrante.

   Para obtener más información, consulte .NET host genérico en ASP.NET Core, implementaciones de servidor web en ASP.NET Core y Kestrel servidor web en ASP.NET Core.

4. Se activan los eventos del ciclo de vida al iniciarse la aplicación.

   El servicio IHostApplicationLifetime activa su token ApplicationStarted, que invoca las funciones de devolución de llamada registradas en él. Cualquier callback, programa de inicialización de bases de datos u otros detectores de eventos personalizados que estén configurados para esperar a que se active el token se activan para iniciar el procesamiento.

5. El subproceso de ejecución principal se bloquea mientras se ejecuta la aplicación.

   Run (app.Run()) espera sincrónicamente hasta el apagado.

6. La aplicación está lista para procesar solicitudes.

   En este punto, el intérprete de comandos registra diagnósticos de alojamiento:

   info: Microsoft.Hosting.Lifetime[14]
         Now listening on: https://localhost:7123
   info: Microsoft.Hosting.Lifetime[14]
         Now listening on: http://localhost:5123
   info: Microsoft.Hosting.Lifetime[0]
         Application started. Press Ctrl+C to shut down.
   

La aplicación permanece en este estado indefinidamente, pasando el tráfico web entrante por la canalización de middleware y enviando respuestas.

Cuando se señala el apagado, por ejemplo, cuando se detecta Ctrl+c en el shell de comandos que ejecuta la aplicación o una herramienta de orquestación de contenedores envía un evento SIGTERM, Run desbloquea y se realizan las siguientes acciones:

1. ApplicationStopping Los tokens se desencadenan, lo que permite que la aplicación ejecute lógica antes de que comience el proceso de apagado.

2. El Kestrel servidor se apaga, lo que deshabilita las nuevas conexiones. El servidor espera a que se completen las solicitudes en las conexiones existentes durante el tiempo que permita el tiempo de espera de apagado. El servidor envía el encabezado de cierre de conexión en las solicitudes adicionales de las conexiones existentes.

3. El host cierra los servicios hospedados registrados. A menos que la aplicación configure la detención simultánea de los servicios hospedados (.NET 8 o una versión posterior), los servicios hospedados se detienen de forma secuencial en el orden inverso de sus registros en el contenedor de inyección de dependencias. Para obtener más información, consulte Tareas en segundo plano con servicios hospedados en ASP.NET Core.

4. ApplicationStopped Los controladores de eventos se desencadenan, lo que permite que la aplicación ejecute lógica después de que la aplicación se haya apagado.

5. La ejecución de la consola finaliza correctamente con un código de salida de 0.

La clase Startup configura los servicios y la canalización de solicitudes de la aplicación.

La clase Startup.

ASP.NET Core aplicaciones usan una clase de inicio denominada Startup por convención. La clase Startup:

• Incluye opcionalmente un método ConfigureServices para configurar los servicios de la aplicación. Un servicio es un componente reutilizable que proporciona funcionalidades de la aplicación. Los servicios se registran en ConfigureServices y se usan en la aplicación a través de la inserción de dependencias (DI) o ApplicationServices.
• Incluye un método Configure para crear la canalización de procesamiento de solicitudes de la aplicación.

ConfigureServices y Configure son llamados por el tiempo de ejecución de ASP.NET Core cuando la aplicación se inicia.

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        ...
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        ...
    }
}

La clase Startup se especifica cuando se crea el host de la aplicación. La clase Startup se suele especificar llamando a WebHostBuilderExtensions.UseStartup en el generador de host:

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.UseStartup<Startup>();
            });
}

El host proporciona servicios que están disponibles para el constructor de clase Startup. La aplicación agrega servicios adicionales a través de ConfigureServices. Los servicios del host y de la aplicación son accesibles en Configure y en toda la aplicación.

Solo se pueden inyectar los siguientes tipos de servicio en el constructor Startup al usar el Host Genérico (IHostBuilder):

• IWebHostEnvironment
• IHostEnvironment
• IConfiguration

public class Startup
{
    private readonly IWebHostEnvironment _env;

    public Startup(IConfiguration configuration, IWebHostEnvironment env)
    {
        Configuration = configuration;
        _env = env;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {
        if (_env.IsDevelopment())
        {
        }
        else
        {
        }
    }
}

La mayoría de los servicios no están disponibles hasta que se llama al método Configure.

Varias Startup clases

Cuando la aplicación define clases Startup independientes para otros entornos (por ejemplo, StartupDevelopment), la clase Startup correspondiente se selecciona en tiempo de ejecución. La clase cuyo sufijo de nombre coincide con el entorno actual se establece como prioritaria. Si la aplicación se ejecuta en el Development entorno e incluye una Startup clase y una StartupDevelopment clase, se usa la StartupDevelopment clase . Para obtener más información, consulte Uso de varios entornos.

El método ConfigureServices

El método opcional ConfigureServices es:

• Lo llama el host antes del método Configure para configurar los servicios de la aplicación.
• Es donde se establecen por convención las opciones de configuración.

El host puede configurar algunos servicios antes de que se llamen los métodos Startup. Para obtener más información, consulte visión general de los fundamentos de ASP.NET Core.

Para las funciones que requieren una configuración compleja, existen Add{Service} métodos de extensión en IServiceCollection, como:

• AddDbContext
• AddDefaultIdentity
• AddEntityFrameworkStores
• AddRazorPages

public class Startup
{
    public Startup(IConfiguration configuration)
    {
        Configuration = configuration;
    }

    public IConfiguration Configuration { get; }

    public void ConfigureServices(IServiceCollection services)
    {

        services.AddDbContext<ApplicationDbContext>(options =>
            options.UseSqlServer(
                Configuration.GetConnectionString("DefaultConnection")));
        services.AddDefaultIdentity<IdentityUser>(
            options => options.SignIn.RequireConfirmedAccount = true)
            .AddEntityFrameworkStores<ApplicationDbContext>();

        services.AddRazorPages();
    }
}

La adición de servicios al contenedor de servicios hace que estén disponibles en la aplicación y en el método Configure. Los servicios se resuelven a través de la inserción de dependencias o desde ApplicationServices.

El método Configure

El método Configure se usa para especificar la forma en que la aplicación responde a las solicitudes HTTP. La canalización de solicitudes se configura mediante la adición de componentes de middleware a una instancia de IApplicationBuilder. IApplicationBuilder está disponible para el método Configure, pero no está registrado en el contenedor de servicios. El hospedaje crea un elemento IApplicationBuilder y lo pasa directamente a Configure.

Las plantillas de ASP.NET Core configuran la canalización con compatibilidad para lo siguiente:

• Página de excepciones para el desarrollador
• Controlador de excepciones
• Seguridad de transporte estricta de HTTP (HSTS)
• Redireccionamiento HTTPS
• Archivos estáticos
• ASP.NET Core MVC y Razor Pages

En el ejemplo siguiente se muestra el middleware para una aplicación típica Razor de Pages:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddRazorPages();
    }

    public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
    {
        if (env.IsDevelopment())
        {
            app.UseDeveloperExceptionPage();
        }
        else
        {
            app.UseExceptionHandler("/Error");
            app.UseHsts();
        }

        app.UseHttpsRedirection();
        app.UseStaticFiles();
        app.UseRouting();

        app.UseEndpoints(endpoints =>
        {
            endpoints.MapRazorPages();
        });
    }
}

El ejemplo anterior corresponde a Razor Pages; la versión para MVC es similar.

Cada método de extensión Use agrega uno o más componentes de middleware a la canalización de solicitudes. Por ejemplo, UseStaticFiles configura middleware para proporcionar archivos estáticos.

Cada componente de middleware de la canalización de solicitudes es responsable de invocar al siguiente componente de la canalización o de cortocircuitar la cadena en caso de ser necesario.

En la firma del método IWebHostEnvironment se pueden especificar servicios adicionales, como ILoggerFactory, ConfigureServices, o bien todo lo definido en Configure. Estos servicios se inyectan si están disponibles.

Para obtener más información sobre cómo usar IApplicationBuilder y el orden del procesamiento de middleware, consulte ASP.NET Core middleware.

Configurar servicios sin una Startup clase

Para configurar los servicios y la canalización de procesamiento de solicitudes sin usar una clase Startup, llame a los métodos de conveniencia ConfigureServices y Configure en el generador de host. Varias llamadas a ConfigureServices se anexan entre sí. Si hay varias llamadas al método Configure, se usa la última llamada a Configure.

public class Program
{
    public static void Main(string[] args)
    {
        CreateHostBuilder(args).Build().Run();
    }

    public static IHostBuilder CreateHostBuilder(string[] args) =>
        Host.CreateDefaultBuilder(args)
            .ConfigureAppConfiguration((hostingContext, config) =>
            {
            })
            .ConfigureWebHostDefaults(webBuilder =>
            {
                webBuilder.ConfigureServices(services =>
                {
                    ...
                })
                .Configure(app =>
                {
                    ...
                });
        });
}

La implementación del filtro de inicio se registra en el Program archivo :

builder.Services.AddTransient<IStartupFilter, CustomResponseHeaderFilter>();

La implementación del filtro de inicio se registra en Startup.ConfigureServices:

services.AddTransient<IStartupFilter, CustomResponseHeaderFilter>();

La clase Startup (métodos ConfigureServices y Configure)

Aunque se admite en aplicaciones de ASP.NET Core destinadas a .NET 6 o versiones posteriores, no se recomienda usar una clase Startup. Para obtener más información, consulte Migración de ASP.NET Core en .NET 5 a .NET 6.

Para obtener información sobre el uso de los ConfigureServices métodos y Configure con el modelo de hospedaje mínimo, consulte lo siguiente:

• Uso de una Startup clase con el modelo de hospedaje mínimo
• La Startup clase (.NET 5 versión de este artículo)

Medición del rendimiento de inicio

El ASP.NET Core hospedaje EventSource emite el ServerReady evento , que representa el punto en el que el servidor está listo para responder a las solicitudes y se puede usar para medir el tiempo de inicio. Para obtener más información, consulte Registro en .NET y ASP.NET Core.