Información general de los conceptos básicos de ASP.NET Core

Note

Esta no es la versión más reciente de este artículo. Para la versión actual, consulte la versión de .NET 10 de este artículo.

Warning

Esta versión de ASP.NET Core ya no se admite. Para más información, consulte la directiva de soporte técnico de .NET y .NET Core. Para la versión actual, consulte la versión de .NET 10 de este artículo.

En este artículo se proporciona información general sobre los aspectos básicos para compilar aplicaciones ASP.NET Core, incluida la inserción de dependencias (DI), la configuración y el middleware.

Para obtener información sobre aspectos básicos de Blazor, que agrega o reemplaza las instrucciones de este artículo, consulte Aspectos básicos de ASP.NET Core Blazor.

El archivo Program

ASP.NET Core aplicaciones creadas a partir de las plantillas de proyecto del marco contienen código de inicio en el Program archivo (Program.cs). El archivo Program es donde:

  • Se configuran los servicios requeridos por la aplicación.
  • El canal de procesamiento de solicitudes de la aplicación se define como una serie de componentes de middleware.

El código de inicio de la aplicación siguiente admite dos tipos de aplicación:

// Initialize a new instance of the WebApplicationBuilder class 
// with preconfigured defaults
var builder = WebApplication.CreateBuilder(args);

// Add services for Blazor (Razor components)
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents();

// Build the app
var app = builder.Build();

// Use exception-handling middleware and HSTS middleware
// when in the Development environment
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseStatusCodePagesWithReExecute("/not-found", createScopeForStatusCodePages: true);

// Use HTTPS redirection middleware to automatically
// redirect requests from HTTP to HTTPS
app.UseHttpsRedirection();

// Map static assets endpoints
app.MapStaticAssets();

// Map a Minimal API endpoint for requests to '/hi'
app.MapGet("/hi", () => "Hello!");

// Add endpoints for Blazor
app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode();

// Run the app
app.Run();

Note

Con la configuración adicional en el Program archivo, las aplicaciones de ASP.NET Core pueden admitir Razor Pages, MVC y la API web con controladores.

El código de inicio de la aplicación siguiente admite dos tipos de aplicación:

// Initialize a new instance of the WebApplicationBuilder class 
// with preconfigured defaults
var builder = WebApplication.CreateBuilder(args);

// Add services for Blazor (Razor components)
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents();

// Build the app
var app = builder.Build();

// Use exception-handling middleware and HSTS middleware
// when in the Development environment
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseStatusCodePagesWithReExecute("/not-found", createScopeForStatusCodePages: true);

// Use HTTPS redirection middleware to automatically
// redirect requests from HTTP to HTTPS
app.UseHttpsRedirection();

// Add antiforgery middleware
app.UseAntiforgery();

// Map static assets endpoints
app.MapStaticAssets();

// Map a Minimal API endpoint for requests to '/hi'
app.MapGet("/hi", () => "Hello!");

// Add endpoints for Blazor
app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode();

// Run the app
app.Run();

Note

Con la configuración adicional en el Program archivo, las aplicaciones de ASP.NET Core pueden admitir Razor Pages, MVC y la API web con controladores.

El código de inicio de la aplicación siguiente admite varios tipos de aplicación:

// Initialize a new instance of the WebApplicationBuilder class 
// with preconfigured defaults
var builder = WebApplication.CreateBuilder(args);

// Add services for Blazor (Razor components), Razor Pages, and MVC
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents();
builder.Services.AddRazorPages();
builder.Services.AddControllersWithViews();

// Build the app
var app = builder.Build();

// Configure the HTTP request pipeline

// Use exception-handling middleware and HSTS middleware
// when in the Development environment
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

// Use HTTPS redirection middleware to automatically
// redirect requests from HTTP to HTTPS
app.UseHttpsRedirection();

// Use static files middleware to serve static assets
app.UseStaticFiles();

// Use authorization middleware
app.UseAuthorization();

// Add antiforgery middleware
app.UseAntiforgery();

// Map a Minimal API endpoint for requests to '/hi'
app.MapGet("/hi", () => "Hello!");

// Configures the standard conventional route for MVC
app.MapDefaultControllerRoute();

// Add endpoints for Razor Pages
app.MapRazorPages();

// Add endpoints for Blazor
app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode();

// Run the app
app.Run();

El siguiente código de inicio de la aplicación admite:

// Initialize a new instance of the WebApplicationBuilder class 
// with preconfigured defaults
var builder = WebApplication.CreateBuilder(args);

// Add services for Razor Pages and MVC
builder.Services.AddRazorPages();
builder.Services.AddControllersWithViews();

// Build the app
var app = builder.Build();

// Configure the HTTP request pipeline

// Use exception-handling middleware and HSTS middleware
// when in the Development environment
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

// Use HTTPS redirection middleware to automatically
// redirect requests from HTTP to HTTPS
app.UseHttpsRedirection();

// Use static files middleware to serve static assets
app.UseStaticFiles();

// Use authorization middleware
app.UseAuthorization();

// Map a Minimal API endpoint for requests to '/hi'
app.MapGet("/hi", () => "Hello!");

// Configures the standard conventional route for MVC
app.MapDefaultControllerRoute();

// Add endpoints for Razor Pages
app.MapRazorPages();

// Run the app
app.Run();

La clase Startup.

La Startup clase (Startup.cs) es donde:

  • Los servicios requeridos por la aplicación se configuran en el ConfigureServices método .
  • La canalización de procesamiento de solicitudes de la aplicación se define en el método Configure como una serie de componentes de middleware.

El siguiente código de inicio de la aplicación admite:

public class Startup
{
    public void ConfigureServices(IServiceCollection services)
    {
        services.AddDbContext<RazorPagesMovieContext>(options =>
            options.UseSqlServer(Configuration.GetConnectionString("RazorPagesMovieContext")));

        services.AddControllersWithViews();
        services.AddRazorPages();
    }

    public void Configure(IApplicationBuilder app)
    {
        app.UseHttpsRedirection();
        app.UseStaticFiles();

        app.UseRouting();

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

Para obtener más información, consulte Inicio de la aplicación en ASP.NET Core y inicio de ASP.NET CoreBlazor.

Inserción de dependencias (servicios)

ASP.NET Core incluye inyección de dependencias (DI) integrada, que hace que los servicios configurados estén disponibles en toda la aplicación para la inversión de control (IoC).

Cuando se crea una instancia de WebApplicationBuilder al llamar a WebApplication.CreateBuilder, los servicios proporcionados por el framework se agregan automáticamente, como los servicios de configuración y registro:

var builder = WebApplication.CreateBuilder(args);

Se agregan servicios adicionales al contenedor de DI con WebApplicationBuilder.Services. En el ejemplo siguiente se registran los servicios Blazor:

builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents();
builder.Services.AddServerSideBlazor();

El marco de inserción de dependencias proporciona instancias de servicios solicitados en tiempo de ejecución. En aplicaciones Blazor, los servicios suelen resolverse desde la inyección de dependencias en tiempo de ejecución mediante la directiva @inject en un archivo Razor de componente (.razor). En el ejemplo siguiente, el componente usa la abstracción NavigationManager para obtener una instancia del administrador de navegación, que se usa para consultar y administrar la navegación por URI, para llevar al usuario a la página de productos en /products cuando se selecciona el botón:

@inject NavigationManager Navigation

<button @onclick="NavigateToProductList">
    Products
</button>

@code {
    private void NavigateToProductList()
    {
        Navigation.NavigateTo("/products");
    }
}

Otra forma de resolver un servicio mediante la inyección de dependencias es usar la inyección mediante constructor. En el ejemplo siguiente, el constructor principal (C# 12 o posterior) acepta parámetros de los tipos AppDbContext y ILogger<OrderProcessor> y los resuelve en tiempo de ejecución como las variables context y logger (las instancias de las abstracciones de base de datos y de registro). La instancia de contexto de base de datos se usa para procesar todos los pedidos en los que el IsProcessed campo está false en la base de datos y cada pedido procesado se registra como información con su identificador de pedido (OrderId) mediante la instancia del registrador:

public class OrderProcessor(AppDbContext context, ILogger<OrderProcessor> logger)
{
    public async Task ProcessPendingOrdersAsync()
    {
        var orders = await context.Orders
            .Where(o => !o.IsProcessed)
            .ToListAsync();

        foreach (var order in orders)
        {
            order.IsProcessed = true;
            logger.LogInformation("Processed order ID {OrderId}.", order.Id);
        }

        await context.SaveChangesAsync();
    }
}

También puede inyectar dependencias directamente en los parámetros de lambda de los puntos de conexión de API mínima. En el ejemplo siguiente, se devuelve una lista de tareas pendientes del punto de conexión /todos. Una instancia de registrador para ILogger<Program> registra información, y la instancia de base de datos para AppDbContext se usa para obtener de la base de datos la lista de elementos de tareas pendientes para incluirla en la respuesta:

app.MapGet("/todos", async (AppDbContext context, ILogger<Program> logger) =>
{
    logger.LogInformation("Fetching todos using inline handler injection.");
    var todos = await context.Todos.ToListAsync();

    return Results.Ok(todos);
});

Cuando se llama al Host.CreateDefaultBuilder en el archivo Program, se inicializa automáticamente una nueva instancia de la clase HostBuilder con servicios proporcionados por el marco de trabajo, como servicios de configuración y registro:

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

Se añaden servicios adicionales a la colección de servicios del contenedor de DI (IServiceCollection) en el Startup.ConfigureServices método (Startup.cs). En el ejemplo siguiente se registran los servicios de MVC y Razor Pages:

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

Los servicios se suelen resolver desde la inserción de dependencias mediante la inserción de constructores. Con la inserción de constructores, una clase declara un parámetro de constructor del tipo requerido o una interfaz. El marco de inserción de dependencias proporciona una instancia del servicio en tiempo de ejecución.

Si el contenedor de inserción de dependencias integrado no satisface sus necesidades, se puede usar un contenedor de IoC de terceros en su lugar.

Para obtener más información, consulte Inserción de dependencias en ASP.NET Core e inserción de dependencias ASP.NET CoreBlazor.

Environments

Los entornos de ejecución están disponibles en ASP.NET Core, como:

  • Development: cuando la aplicación está en desarrollo local.
  • Staging: Cuando la aplicación está preparada para su despliegue.
  • Production: cuando la aplicación activa se ejecuta para los usuarios.

Especifique el entorno en el que se ejecuta una aplicación estableciendo la ASPNETCORE_ENVIRONMENT variable de entorno en el host donde se ejecuta la aplicación. ASP.NET Core lee la variable de entorno en el inicio de la aplicación y almacena el valor para controlar la ejecución de código en torno a la aplicación.

El código de desarrollador puede comprobar si hay un entorno determinado. En el ejemplo de archivo siguiente Program , el código del bloque de ejecución solo se ejecuta cuando la aplicación no se ejecuta en el Development entorno:

if (!app.Environment.IsDevelopment())
{
    ...
}
public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (!env.IsDevelopment())
    {
        ...
    }

    ...
}

Para obtener más información, consulte entornos de ejecución de ASP.NET Core y entornos de ASP.NET Core Blazor.

Middleware

La canalización de control de solicitudes se compone de una serie de componentes de software intermedio. Cada componente lleva a cabo las operaciones en un contexto HttpContext e invoca el middleware siguiente de la canalización, o bien finaliza 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". En el ejemplo siguiente que representa parte de una canalización de procesamiento de solicitudes, se llama al middleware para el control de excepciones (UseExceptionHandler), el protocolo de seguridadUseHsts de transporte estricto HTTP (HSTS) y el redireccionamiento HTTPS (UseHttpsRedirection). Dos de los middlewares solo se activan cuando la aplicación no está en desarrollo local en el entorno Development, por ejemplo, cuando la aplicación está en fase de preproducción (el entorno Staging) o en producción (el entorno Production):

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error", createScopeForErrors: true);
    app.UseHsts();
}

app.UseHttpsRedirection();
if (env.IsDevelopment())
{
    ...
}
else
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

app.UseHttpsRedirection();

ASP.NET Core incluye un amplio conjunto de middleware integrado. También puede crear componentes de middleware personalizados para cumplir las especificaciones especiales de procesamiento de solicitudes de una aplicación. Para obtener más información, consulte ASP.NET Core middleware.

Host

Al iniciarse, una aplicación ASP.NET Core compila un host. El host encapsula todos los recursos de la aplicación, como:

  • Una implementación de servidor de HTTP
  • Componentes de middleware
  • Logging
  • Servicios de inserción de dependencias (DI)
  • Configuration

Hay tres hosts diferentes capaces de ejecutar una aplicación de ASP.NET Core:

Se recomiendan los tipos ASP.NET Core WebApplication y WebApplicationBuilder, y se usan en todas las plantillas de proyecto de ASP.NET Core. WebApplication se comporta de manera similar al host genérico de .NET y expone muchas de las mismas interfaces, pero requiere menos llamadas de retorno para configurarse. El ASP.NET Core WebHost solo está disponible para la compatibilidad con versiones anteriores.

En el ejemplo siguiente se crea una instancia de un WebApplication y se asigna a una variable denominada app:

var builder = WebApplication.CreateBuilder(args);

...

var app = builder.Build();

El WebApplicationBuilder.Build método configura un host con un conjunto de opciones predeterminadas, como:

  • Uso Kestrel como servidor web y habilitación de la integración de IIS.
  • Carga de la configuración desde archivos de configuración de la aplicación (por ejemplo, appsettings.json), variables de entorno, argumentos de línea de comandos y otros orígenes de configuración.
  • Configurar el registro y dirigir la salida del registro a la consola y a los proveedores de registro de depuración.

Hay dos hosts:

Se recomienda el host genérico de .NET. El host web de ASP.NET Core solo está disponible para la compatibilidad con versiones anteriores.

Los CreateDefaultBuilder métodos y ConfigureWebHostDefaults del ejemplo siguiente configuran un host con un conjunto de opciones predeterminadas, como:

  • Uso Kestrel como servidor web y habilitación de la integración de IIS.
  • Carga de la configuración desde archivos de configuración de la aplicación (por ejemplo, appsettings.json), variables de entorno, argumentos de línea de comandos y otros orígenes de configuración.
  • Configurar el registro y dirigir la salida del registro a la consola y a los proveedores de registro de depuración.
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>();
            });
}

Para obtener más información, consulte los recursos siguientes:

Escenarios no-web

El Generic Host permite que otros tipos de aplicaciones usen extensiones transversales del marco, como el registro, la inyección de dependencias (DI), la configuración y la administración del ciclo de vida de la aplicación. Para más información, consulte Host genérico de .NET en ASP.NET Core y Tareas en segundo plano con servicios hospedados en ASP.NET Core.

Servers

Una aplicación ASP.NET Core usa una implementación de servidor HTTP para escuchar las solicitudes HTTP. El servidor muestra las solicitudes a la aplicación como un conjunto de características de solicitud compuestas en un HttpContext.

Para más información, consulte Implementaciones de servidores web en ASP.NET Core.

Windows

ASP.NET Core proporciona las siguientes implementaciones de servidor:

  • Kestrel es un servidor web multiplataforma. Kestrel a menudo se ejecuta en una configuración de proxy inverso mediante IIS. En ASP.NET Core 2.0 y versiones posteriores, Kestrel se puede ejecutar como servidor perimetral de acceso público expuesto directamente a Internet.
  • Servidor HTTP de IIS es un servidor para Windows que usa IIS. Con este servidor, la aplicación de ASP.NET Core e IIS se ejecutan en el mismo proceso.
  • HTTP.sys es un servidor para Windows que no se usa con IIS.

macOS y Linux

ASP.NET Core proporciona la implementación de servidor multiplataforma Kestrel. En ASP.NET Core 2.0 y versiones posteriores, Kestrel se puede ejecutar como servidor perimetral de acceso público expuesto directamente a Internet. Kestrel a menudo se ejecuta en una configuración de proxy inverso con Nginx o Apache.

Configuration

ASP.NET Core proporciona un marco de configuración que obtiene valores de configuración en forma de pares nombre-valor a partir de un conjunto ordenado de proveedores de configuración. Los proveedores de configuración integrados están disponibles para una variedad de orígenes, como archivos JSON (), archivos XML (.json.xml), variables de entorno y argumentos de línea de comandos. Puede crear proveedores de configuración personalizados para admitir otros orígenes.

De forma predeterminada, las aplicaciones de ASP.NET Core están configuradas para leer desde archivos de configuración de la aplicación (por ejemplo, appsettings.json), variables de entorno y la línea de comandos.

Cuando se carga la configuración de la aplicación, los valores de las variables de entorno invalidan los valores de los archivos de configuración de la aplicación. La API options está disponible para leer los valores de configuración relacionados.

Para administrar datos de configuración confidenciales, como contraseñas en el Development entorno, .NET proporciona el Administrador de secretos. Para los secretos de producción, se recomienda usar Azure Key Vault.

Para obtener más información, consulte los recursos siguientes:

Logging

ASP.NET Core admite una API de registro que funciona con una variedad de proveedores de registro:

  • Console
  • Debug
  • Seguimiento de eventos en Windows
  • Registro de sucesos de Windows
  • TraceSource
  • Azure App Service
  • Azure Application Insights
  • Proveedores de terceros

Para crear registros, resuelva un servicio ILogger<TCategoryName> mediante inyección de dependencias (DI) y llame a métodos de registro, como LogInformation. Un objeto de registro y un proveedor de consola para el objeto de registro se almacenan automáticamente en el contenedor de inyección de dependencias cuando se llama al método WebApplication.CreateBuilder.

En el ejemplo siguiente se muestra cómo obtener una instancia de registro de la inyección de dependencias y usarla en un componente Weather (Weather.razor) de una aplicación Blazor que muestra datos meteorológicos:

@inject ILogger<Weather> Logger

...

@code {
    protected override async Task OnInitializedAsync()
    {
        Logger.LogInformation("OnInitializedAsync method called!");

        ...
    }
}

Para obtener más información, incluida la guía de enrutamiento para Razor las aplicaciones Pages y MVC, consulte Registro en .NET y ASP.NET Core y registro de ASP.NET CoreBlazor.

Routing

El enrutamiento en ASP.NET Core es un mecanismo que asigna las solicitudes entrantes a puntos de conexión específicos de una aplicación. Permite definir patrones de dirección URL que corresponden a distintos componentes, como componentes de Razor, páginas de Razor, acciones del controlador MVC o middleware.

El método UseRouting agrega el middleware de enrutamiento a la pipeline de solicitudes. Este middleware procesa la información de enrutamiento y determina el punto de conexión adecuado para cada solicitud. En las aplicaciones que usan el Host mínimo, no se llama explícitamente a UseRouting en el código del desarrollador, a menos que se quiera cambiar el orden de procesamiento del middleware.

Para obtener más información, consulte los recursos siguientes:

Gestión de errores

ASP.NET Core tiene características integradas para controlar los errores, tales como:

  • Una página de excepciones para el desarrollador
  • Páginas de error personalizadas
  • Páginas de códigos de estado estáticos
  • Control de excepciones de inicio

Para obtener más información, consulte Control de errores en ASP.NET Core y Control de errores en aplicaciones ASP.NET CoreBlazor.

Realización de solicitudes HTTP

Una implementación de IHttpClientFactory está disponible para crear instancias de HttpClient. La fábrica:

  • Proporciona una ubicación central para denominar y configurar instancias de HttpClient lógicas. Por ejemplo, confíe en un cliente predeterminado para la mayoría de las solicitudes de datos de la aplicación con una API web y registre un cliente configurado diferente para acceder a GitHub.
  • Admite el registro y encadenamiento de varios controladores de delegación para crear una canalización de middleware de solicitud saliente. Este patrón es similar a la canalización de middleware de entrada de ASP.NET Core. Dicho patrón proporciona un mecanismo para administrar cuestiones transversales relativas a las solicitudes HTTP, como el almacenamiento en caché, el control de errores, la serialización y el registro.
  • Se integra con Polly, una biblioteca popular de terceros para el control de errores transitorios.
  • Administra la agrupación y duración de las instancias de HttpClientHandler subyacentes para evitar los problemas de DNS que suelen producirse al administrar manualmente las duraciones de HttpClient.
  • Agrega una experiencia de registro configurable a través de ILogger en todas las solicitudes enviadas a través de los clientes creados por Factory.

Para obtener más información, consulte Solicitudes HTTP con IHttpClientFactory: ASP.NET Core y Llamada a una API web desde una aplicación de ASP.NET CoreBlazor.

Raíz del contenido

La raíz del contenido es la ruta de acceso base para:

  • Archivo ejecutable que hospeda la aplicación (.exe).
  • Los ensamblados compilados que componen la aplicación (.dll).
  • Archivos de contenido usados por la aplicación, como Razor archivos (.cshtml, .razor), archivos de configuración (.json, .xml) y archivos de datos (.db).
  • La raíz web, que suele ser la carpeta wwwroot.

Durante el desarrollo, la raíz del contenido tiene como valor predeterminado el directorio raíz del proyecto. Este directorio también es la ruta de acceso base para los archivos de contenido de la aplicación y la raíz web. Especifique una raíz de contenido diferente estableciendo su ruta de acceso al compilar el host.

Para obtener más información, consulte .NET Generic Host en ASP.NET Core y Servir archivos estáticos en aplicaciones de ASP.NET Core.

Raíz web

La raíz web es la ruta de acceso base para archivos de recursos públicos y estáticos, como hojas de estilos, archivos javaScript e imágenes.

De forma predeterminada, los archivos estáticos solo se sirven desde el directorio raíz web y sus subdirectorios. La ruta de acceso raíz web tiene como valor predeterminado {CONTENT ROOT}/wwwroot, donde el marcador de posición {CONTENT ROOT} es la raíz del contenido. Para especificar otra raíz web, establezca su ruta de acceso al compilar el host. También puede evitar la publicación de archivos en wwwroot con el elemento de proyecto <Content> en el archivo de proyecto de la aplicación.

En los archivos Razor.cshtml, ~/ apunta a la raíz web. Una ruta de acceso que comienza con ~/ se conoce como ruta de acceso virtual.

Para obtener más información, consulte .NET Generic Host en ASP.NET Core y Servir archivos estáticos en aplicaciones de ASP.NET Core.

Cómo descargar un ejemplo

En muchos de los artículos y tutoriales se incluyen vínculos a código de ejemplo.

  1. Descargue el archivo ZIP del repositorio de ASP.NET.
  2. Descomprima el archivo AspNetCore.Docs-main.zip.
  3. Para acceder a la aplicación de ejemplo de un artículo en el repositorio descomprimido, use la dirección URL del vínculo de ejemplo del artículo para ayudarle a navegar a la carpeta del ejemplo. Normalmente, el vínculo de ejemplo de un artículo aparece en la parte superior del artículo con el texto del vínculo Ver o descargar código de ejemplo.

Para obtener una sola aplicación de ejemplo y solo su última confirmación, use git sparse-checkout.

En el siguiente ejemplo del repositorio de GitHub de ejemplos Blazor samples, el comando git sparse-checkout set especifica la ruta de acceso a la carpeta de ejemplos:

  • Sustituya el marcador de posición {VERSION FOLDER} por la carpeta de versión.
  • Sustituya el marcador de posición {SAMPLE FOLDER} por la carpeta de muestra.

En un shell de comandos, vaya a la carpeta donde desea clonar el ejemplo. Ejecute los siguientes comandos en el intérprete de comandos, pasando la ruta de acceso a la carpeta version/sample al comando git sparse-checkout set:

git clone --depth 1 --filter=blob:none https://github.com/dotnet/blazor-samples.git --sparse
cd blazor-samples
git sparse-checkout init --cone
git sparse-checkout set {VERSION FOLDER}/{SAMPLE FOLDER}

En el siguiente ejemplo de PowerShell, se obtiene la muestra 10.0 Blazor Web App y se coloca en la carpeta Documentos del usuario mediante la ruta de ~/documents de PowerShell para el comando change directory (cd):

cd "~/documents"
git clone --depth 1 --filter=blob:none https://github.com/dotnet/blazor-samples.git --sparse
cd blazor-samples
git sparse-checkout init --cone
git sparse-checkout set 10.0/BlazorSample_BlazorWebApp

Directivas de preprocesador en código de ejemplo

Para mostrar varios escenarios, las aplicaciones de ejemplo usan las directivas de preprocesador #define y #if-#else/#elif-#endif para compilar de forma selectiva y ejecutar secciones distintas de código de ejemplo. Para los ejemplos que usan este enfoque, establezca la directiva #define en la parte superior de los archivos C# para definir el símbolo asociado con el escenario que quiera ejecutar. Algunos ejemplos requieren la definición del símbolo en la parte superior de varios archivos para ejecutar un escenario.

Por ejemplo, la siguiente lista de símbolos de #define indica que hay cuatro escenarios disponibles (un escenario por símbolo). La configuración de ejemplo actual ejecuta el escenario TemplateCode:

#define TemplateCode // or LogFromMain or ExpandDefault or FilterInCode

Para cambiar el ejemplo el escenario ExpandDefault, defina el símbolo ExpandDefault y deje los símbolos restantes comentados:

#define ExpandDefault // TemplateCode or LogFromMain or FilterInCode

Para obtener más información sobre el uso de directivas de preprocesador de C# para compilar de forma selectiva secciones de código, vea #define (Referencia de C#) y #if (Referencia de C#).

Regiones en código de ejemplo

Algunas aplicaciones de ejemplo contienen secciones de código rodeadas de directivas de #region y #endregion de C#. El sistema de compilación de documentación inserta estas regiones en los temas de documentación representados.

Los nombres de región suelen contener la palabra "fragmento de código". En el ejemplo siguiente se muestra una región denominada snippet_WebHostDefaults:

#region snippet_WebHostDefaults
Host.CreateDefaultBuilder(args)
    .ConfigureWebHostDefaults(webBuilder =>
    {
        webBuilder.UseStartup<Startup>();
    });
#endregion

Se hace referencia al fragmento de código de C# anterior en el archivo Markdown del tema con la siguiente línea:

[!code-csharp[](sample/SampleApp/Program.cs?name=snippet_WebHostDefaults)]

Puede ignorar o quitar de forma segura las directivas #region y #endregion que rodean el código. No modifique el código dentro de estas directivas si tiene previsto ejecutar los escenarios de ejemplo descritos en el tema.

Para obtener más información, consulte Contribución a la documentación de ASP.NET: Fragmentos de código.

Modelo de objetos de documento (DOM)

Las referencias al modelo de objetos de documento a lo largo de este conjunto de documentación usan la abreviatura DOM.

Para obtener más información, vea Introducción al DOM (documentación de MDN) y Especificación del modelo de objetos de documento de nivel 1 (W3C).

Múltiplos de byte

Los tamaños de bytes de .NET usan prefijos métricos para múltiplos no decimales de bytes en función de las potencias de 1024.

Nombre (abreviatura) Size Ejemplo
Kilobyte (KB) 1024 bytes 1 KB = 1024 bytes
Megabyte (MB) 10242 bytes 1 MB = 1 048 576 bytes
Gigabyte (GB) 10243 bytes 1 GB = 1 073 741 824 bytes

Solicitudes de soporte técnico

Solo los problemas relacionados con la documentación son adecuados para el repositorio dotnet/AspNetCore.Docs. Para obtener soporte técnico de productos, no abra un problema relativo a la documentación. Busque ayuda a través de uno o varios de los siguientes canales de soporte técnico:

En caso de producirse un error potencial en los comentarios sobre el marco o el producto, abra un problema para la unidad de producto de ASP.NET Core en problemas dotnet/aspnetcore. Los informes de errores suelen requerir lo siguiente:

  • Explicación clara del problema: siga las instrucciones de la plantilla de problemas de GitHub proporcionada por la unidad de producto al abrirse un problema.
  • Proyecto mínimo reproducible: Coloque un proyecto en GitHub para que los ingenieros de la unidad de producto lo descarguen y ejecuten. Vincule el proyecto de forma cruzada al comentario de apertura del problema.

Para un posible problema con un artículo, abra un problema de documentación. Para abrir un problema de documentación, usa el vínculo de comentarios Abrir una incidencia de documentación en la parte inferior del artículo. Los metadatos agregados a tu incidencia proporcionan datos de seguimiento y hacen ping automáticamente al autor del artículo. Si se ha tratado el asunto con la unidad de producto antes de abrir la incidencia de documentación, sitúa un vínculo cruzado al problema de ingeniería en el comentario de apertura del problema de la documentación.

Los problemas de GitHub relativos a la documentación de Blazor se marcan automáticamente para la priorización en el proyecto Blazor.Docs (repositorio de GitHub dotnet/AspNetCore.Docs). Espere un poco para obtener una respuesta, especialmente durante los fines de semana y los días festivos. Normalmente, los creadores de la documentación responden en un plazo de 24 horas los días laborables.

Para notificar problemas o comentarios sobre Visual Studio, use los gestos de Notificar un problema o Sugerir una característica desde Visual Studio, los cuales abren incidencias internas para Visual Studio. Para obtener más información, vea Visual Studio Feedback.

Si tiene problemas con Visual Studio Code, solicite soporte técnico en los foros de soporte técnico de la comunidad. Para los informes de errores y los comentarios sobre el producto, abra un problema en el repositorio microsoft/vscode GitHub.