Vue d’ensemble des notions de base d’ASP.NET Core

Cet article fournit une vue d’ensemble des principes fondamentaux de la création d’applications ASP.NET Core, notamment l’injection de dépendances (DI), la configuration, l’intergiciel et bien plus encore.

Program.cs

ASP.NET Core applications créées avec les modèles web contiennent le code de démarrage de l’application dans le Program.cs fichier. Le Program.cs fichier est l’emplacement suivant :

  • Les services nécessaires à l’application sont configurés.
  • Le pipeline de gestion des demandes de l’application est défini comme une série de composants intergiciels.

Le code de démarrage de l’application suivant prend en charge :

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddControllersWithViews();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

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

app.UseAuthorization();

app.MapGet("/hi", () => "Hello!");

app.MapDefaultControllerRoute();
app.MapRazorPages();

app.Run();

Injection de dépendances (services)

ASP.NET Core inclut l’injection de dépendances (DI) qui rend les services configurés disponibles dans une application. Les services sont ajoutés au conteneur d’adresses di avec WebApplicationBuilder.Services, builder.Services dans le code précédent. Lorsque l’instanciation WebApplicationBuilder est instanciée, de nombreux services fournis par l’infrastructure sont ajoutés. builder est un WebApplicationBuilder code suivant :

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddControllersWithViews();

var app = builder.Build();

Dans le code mis en surbrillance précédent, a la configuration, builder la journalisation et de nombreux autres services ajoutés au conteneur d’di.

Le code suivant ajoute Razor des pages, des contrôleurs MVC avec des vues et un conteneur d’interface utilisateur personnalisé DbContext :

using Microsoft.EntityFrameworkCore;
using RazorPagesMovie.Data;
var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddControllersWithViews();

builder.Services.AddDbContext<RazorPagesMovieContext>(options =>
   options.UseSqlServer(builder.Configuration.GetConnectionString("RPMovieContext")));

var app = builder.Build();

Les services sont généralement résolus à partir de DI à l’aide de l’injection de constructeur. L’infrastructure di fournit une instance de ce service au moment de l’exécution.

Le code suivant utilise l’injection de constructeur pour résoudre le contexte de base de données et l’enregistreur d’événements à partir de DI :

public class IndexModel : PageModel
{
    private readonly RazorPagesMovieContext _context;
    private readonly ILogger<IndexModel> _logger;

    public IndexModel(RazorPagesMovieContext context, ILogger<IndexModel> logger)
    {
        _context = context;
        _logger = logger;
    }

    public IList<Movie> Movie { get;set; }

    public async Task OnGetAsync()
    {
        _logger.LogInformation("IndexModel OnGetAsync.");
        Movie = await _context.Movie.ToListAsync();
    }
}

Middleware

Le pipeline de traitement des requêtes est composé comme une série de composants d’intergiciel (middleware). Chaque composant effectue des opérations sur un HttpContext intergiciel et appelle le middleware suivant dans le pipeline ou met fin à la requête.

Par convention, un composant middleware est ajouté au pipeline en appelant une méthode d’extension Use{Feature} . Le middleware ajouté à l’application est mis en surbrillance dans le code suivant :

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddControllersWithViews();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

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

app.UseAuthorization();

app.MapGet("/hi", () => "Hello!");

app.MapDefaultControllerRoute();
app.MapRazorPages();

app.Run();

Pour plus d’informations, consultez ASP.NET Core Middleware.

Host

Au démarrage, une application ASP.NET Core génère un hôte. L’hôte encapsule toutes les ressources de l’application, telles que :

  • Une implémentation serveur HTTP
  • Composants d’intergiciel (middleware)
  • Journalisation
  • Services d’injection de dépendances (DI)
  • Configuration

Il existe trois hôtes différents :

L’hôte WebApplication .NET est recommandé et utilisé dans tous les modèles ASP.NET Core. L’hôte WebApplication .NET et l’hôte générique .NET partagent de nombreuses interfaces et classes identiques. L’hôte web ASP.NET Core est disponible uniquement pour la compatibilité descendante.

L’exemple suivant instancie un hôte WebApplication :

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddControllersWithViews();

var app = builder.Build();

La méthode WebApplicationBuilder.Build configure un hôte avec un ensemble d’options par défaut, telles que :

  • Utilisez Kestrel comme serveur web et activez l’intégration d’IIS.
  • Chargez la configuration à partir des variables d’environnement, des arguments de ligne de appsettings.jsoncommande et d’autres sources de configuration.
  • Envoyez la sortie de journalisation aux fournisseurs Console et Debug.

Scénarios non basés sur le web

L’hôte générique permet à d’autres types d’application d’utiliser des extensions de framework composites, par exemple la journalisation, l’injection de dépendance, la configuration et la gestion de la durée de vie de l’application. Pour plus d’informations, consultez l’hôte générique .NET dans ASP.NET Core et les tâches en arrière-plan avec des services hébergés dans ASP.NET Core.

Serveurs

Une application ASP.NET Core utilise une implémentation de serveur HTTP pour écouter les requêtes HTTP. Les surfaces de serveur envoient des requêtes à l’application comme un ensemble de fonctionnalités de requête composées dans un HttpContext.

ASP.NET Core fournit les implémentations de serveur suivantes :

  • Kestrel est un serveur web multiplateforme. Kestrel est souvent exécuté dans une configuration de proxy inverse à l’aide d’IIS. Dans ASP.NET Core version 2.0 ou ultérieure, Kestrel peut être exécuté en tant que serveur edge accessible au public directement sur Internet.
  • IIS HTTP Server est un serveur pour Windows qui utilise IIS. Avec ce serveur, l’application ASP.NET Core et IIS s’exécutent dans le même processus.
  • HTTP.sys est un serveur Windows qui n’est pas utilisé avec IIS.

Pour plus d’informations, consultez implémentations de serveur web dans ASP.NET Core.

Configuration

ASP.NET Core fournit une infrastructure de configuration qui obtient les paramètres en tant que paires nom-valeur à partir d’un ensemble ordonné de fournisseurs de configuration. Les fournisseurs de configuration intégrés sont disponibles pour diverses sources, telles que .json des fichiers, des fichiers, .xml des variables d’environnement et des arguments de ligne de commande. Écrivez des fournisseurs de configuration personnalisés pour prendre en charge d’autres sources.

Par défaut, les applications ASP.NET Core sont configurées pour lire à partir des variables d’environnement, la ligne de appsettings.jsoncommande et bien plus encore. Lorsque la configuration de l’application est chargée, les valeurs des variables d’environnement remplacent les valeurs à partir de appsettings.json.

Pour gérer les données de configuration confidentielles telles que les mots de passe, .NET Core fournit le Gestionnaire de secrets. Pour les secrets de production, nous vous recommandons Azure Key Vault.

Pour plus d’informations, consultez Configuration dans ASP.NET Core.

Environnements

Les environnements d’exécution, tels que Development, Staginget Production, sont disponibles dans ASP.NET Core. Spécifiez l’environnement dans lequel une application s’exécute en définissant la ASPNETCORE_ENVIRONMENT variable d’environnement. ASP.NET Core lit la variable d’environnement au démarrage de l’application et stocke la valeur dans une implémentation IWebHostEnvironment. Cette implémentation est disponible n’importe où dans une application via l’injection de dépendances (DI).

L’exemple suivant configure le gestionnaire d’exceptions et le middleware HSTS (HTTP Strict Transport Security Protocol) lors de l’exécution dans l’environnement Development :

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddControllersWithViews();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

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

app.UseAuthorization();

app.MapGet("/hi", () => "Hello!");

app.MapDefaultControllerRoute();
app.MapRazorPages();

app.Run();

Pour plus d’informations, consultez Utiliser plusieurs environnements dans ASP.NET Core.

Journalisation

ASP.NET Core prend en charge une API de journalisation qui fonctionne avec un large éventail de fournisseurs de journalisation intégrés et tiers. Les fournisseurs disponibles sont les suivants :

  • Console
  • Débogage
  • Suivi des événements sur Windows
  • Journal des événements Windows
  • TraceSource
  • Azure App Service
  • Azure Application Insights

Pour créer des journaux, résolvez un ILogger<TCategoryName> service à partir de l’injection de dépendances (DI) et appelez des méthodes de journalisation telles que LogInformation. Exemple :

public class IndexModel : PageModel
{
    private readonly RazorPagesMovieContext _context;
    private readonly ILogger<IndexModel> _logger;

    public IndexModel(RazorPagesMovieContext context, ILogger<IndexModel> logger)
    {
        _context = context;
        _logger = logger;
    }

    public IList<Movie> Movie { get;set; }

    public async Task OnGetAsync()
    {
        _logger.LogInformation("IndexModel OnGetAsync.");
        Movie = await _context.Movie.ToListAsync();
    }
}

Pour plus d’informations, consultez Journalisation dans .NET Core et ASP.NET Core.

Routage

Un itinéraire est un modèle d’URL qui est mappé à un gestionnaire. Le gestionnaire est généralement une page, une Razor méthode d’action dans un contrôleur MVC ou un middleware. Le routage ASP.NET Core vous permet de contrôler les URL utilisées par votre application.

Le code suivant, généré par le modèle d’application web ASP.NET Core, appelle UseRouting:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    app.UseHsts();
}

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Pour plus d’informations, consultez Routage dans ASP.NET Core.

Gestion des erreurs

ASP.NET Core offre des fonctionnalités intégrées pour gérer des erreurs, telles que :

  • Une page d’exceptions du développeur
  • Pages d’erreur personnalisées
  • Pages de codes d’état statique
  • Gestion des exceptions de démarrage

Pour plus d’informations, consultez Gérer les erreurs dans ASP.NET Core.

Effectuer des requêtes HTTP

Une implémentation de IHttpClientFactory est disponible pour la création d’instances HttpClient. La fabrique :

  • Fournit un emplacement central pour le nommage et la configuration d’instance de HttpClient logiques. Par exemple, inscrivez et configurez un client github pour accéder à GitHub. Inscrivez et configurez un client par défaut à d’autres fins.
  • Prend en charge l’inscription et le chaînage de plusieurs gestionnaires de délégation pour créer un pipeline de middlewares pour les requêtes sortantes. Ce modèle est similaire au pipeline d’intergiciel entrant de ASP.NET Core. Le modèle fournit un mécanisme permettant de gérer les préoccupations croisées relatives aux requêtes HTTP, notamment la mise en cache, la gestion des erreurs, la sérialisation et la journalisation.
  • S’intègre à Polly, une bibliothèque tierce populaire pour la gestion des erreurs temporaires.
  • Gère le regroupement et la durée de vie des instances sous-jacentes HttpClientHandler pour éviter les problèmes DNS courants qui se produisent lors de la gestion HttpClient des durées de vie manuellement.
  • Ajoute une expérience de journalisation configurable via ILogger toutes les demandes envoyées par les clients créés par la fabrique.

Pour plus d’informations, consultez Effectuer des requêtes HTTP à l’aide d’IHttpClientFactory dans ASP.NET Core.

Racine de contenu

La racine du contenu est le chemin d’accès de base pour :

  • Exécutable hébergeant l’application (.exe).
  • Assemblys compilés qui composent l’application (.dll).
  • Fichiers de contenu utilisés par l’application, tels que :
    • Razor fichiers (.cshtml, .razor)
    • Fichiers de configuration (.json, .xml)
    • Fichiers de données (.db)
  • Racine web, généralement le dossier wwwroot.

Pendant le développement, la racine de contenu est par défaut dans le répertoire racine du projet. Ce répertoire est également le chemin d’accès de base pour les fichiers de contenu de l’application et la racine web. Spécifiez une autre racine de contenu en définissant son chemin d’accès lors de la génération de l’hôte. Pour plus d’informations, consultez Racine de contenu.

Racine web

La racine web est le chemin d’accès de base pour les fichiers de ressources statiques publics, tels que :

  • Feuilles de style (.css)
  • JavaScript (.js)
  • Images (.png, .jpg)

Par défaut, les fichiers statiques sont servis uniquement à partir du répertoire racine web et de ses sous-répertoires. Le chemin racine web est défini par défaut sur {content root}/wwwroot. Spécifiez une autre racine web en définissant son chemin d’accès lors de la génération de l’hôte. Pour plus d’informations, consultez Racine web.

Empêcher la publication de fichiers dans wwwroot avec l’élément< de projet de contenu> dans le fichier projet. L’exemple suivant empêche la publication de contenu dans wwwroot/local et ses sous-répertoires :

<ItemGroup>
  <Content Update="wwwroot\local\**\*.*" CopyToPublishDirectory="Never" />
</ItemGroup>

Dans les Razor.cshtml fichiers, ~/ pointe vers la racine web. Un chemin d’accès commençant par ~/ est appelé chemin d’accès virtuel.

Pour plus d’informations, consultez Fichiers statiques dans ASP.NET Core.

Ressources supplémentaires

Cet article fournit une vue d’ensemble des principes fondamentaux de la création d’applications ASP.NET Core, notamment l’injection de dépendances (DI), la configuration, l’intergiciel et bien plus encore.

Classe Startup

La classe Startup est l’endroit où :

  • Les services nécessaires à l’application sont configurés.
  • Le pipeline de gestion des demandes de l’application est défini en tant que série de composants intergiciels.

Voici un exemple de classe Startup :

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();
        });
    }
}

Pour plus d’informations, consultez Start-up de l’application dans ASP.NET Core.

Injection de dépendances (services)

ASP.NET Core inclut une infrastructure intégrée d’injection de dépendances (DI) qui rend les services configurés disponibles dans une application. Par exemple, un composant de journalisation est un service.

Le code pour configurer (ou enregistrer) des services est ajouté à la méthode Startup.ConfigureServices. Exemple :

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

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

Les services sont généralement résolus à partir de DI à l’aide de l’injection de constructeur. Avec l’injection de constructeur, une classe déclare un paramètre de constructeur du type requis ou d’une interface. L’infrastructure di fournit une instance de ce service au moment de l’exécution.

L’exemple suivant utilise l’injection de constructeur pour résoudre un RazorPagesMovieContext di :

public class IndexModel : PageModel
{
    private readonly RazorPagesMovieContext _context;

    public IndexModel(RazorPagesMovieContext context)
    {
        _context = context;
    }

    // ...

    public async Task OnGetAsync()
    {
        Movies = await _context.Movies.ToListAsync();
    }
}

Si le conteneur IoC (Intégré Inversion of Control) ne répond pas à tous les besoins d’une application, un conteneur IoC tiers peut être utilisé à la place.

Pour plus d’informations, consultez l’injection de dépendances dans ASP.NET Core.

Middleware

Le pipeline de traitement des requêtes est composé comme une série de composants d’intergiciel (middleware). Chaque composant effectue des opérations sur un HttpContext intergiciel et appelle le middleware suivant dans le pipeline ou met fin à la requête.

Par convention, un composant middleware est ajouté au pipeline en appelant une méthode d’extension Use... dans la Startup.Configure méthode. Par exemple, pour activer le rendu des fichiers statiques, appelez UseStaticFiles.

L’exemple suivant configure un pipeline de gestion des demandes :

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

    app.UseRouting();

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

ASP.NET Core inclut un ensemble riche d’intergiciels intégrés. Les composants intergiciels personnalisés peuvent également être écrits.

Pour plus d’informations, consultez ASP.NET Core Middleware.

Host

Au démarrage, une application ASP.NET Core génère un hôte. L’hôte encapsule toutes les ressources de l’application, telles que :

  • Une implémentation serveur HTTP
  • Composants d’intergiciel (middleware)
  • Journalisation
  • Services d’injection de dépendances (DI)
  • Configuration

Il existe deux hôtes différents :

  • Hôte générique .NET
  • Hôte web ASP.NET Core

L’hôte générique .NET est recommandé. L’hôte web ASP.NET Core est disponible uniquement pour la compatibilité descendante.

L’exemple suivant crée un hôte générique .NET :

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>();
            });
}

Les méthodes et ConfigureWebHostDefaults les CreateDefaultBuilder méthodes configurent un hôte avec un ensemble d’options par défaut, telles que :

  • Utilisez Kestrel comme serveur web et activez l’intégration IIS.
  • Chargez la configuration à partir des appsettings.jsonvariables d’environnement appsettings.{Environment}.json, des arguments de ligne de commande et d’autres sources de configuration.
  • Envoyez la sortie de journalisation aux fournisseurs Console et Debug.

Pour plus d’informations, consultez l’hôte générique .NET dans ASP.NET Core.

Scénarios non basés sur le web

L’hôte générique permet à d’autres types d’application d’utiliser des extensions de framework composites, par exemple la journalisation, l’injection de dépendance, la configuration et la gestion de la durée de vie de l’application. Pour plus d’informations, consultez l’hôte générique .NET dans ASP.NET Core et les tâches en arrière-plan avec des services hébergés dans ASP.NET Core.

Serveurs

Une application ASP.NET Core utilise une implémentation de serveur HTTP pour écouter les requêtes HTTP. Les surfaces de serveur envoient des requêtes à l’application comme un ensemble de fonctionnalités de requête composées dans un HttpContext.

ASP.NET Core fournit les implémentations de serveur suivantes :

  • Kestrel est un serveur web multiplateforme. Kestrel est souvent exécuté dans une configuration de proxy inverse à l’aide d’IIS. Dans ASP.NET Core version 2.0 ou ultérieure, Kestrel vous pouvez l’exécuter en tant que serveur edge public exposé directement à Internet.
  • Le serveur HTTP IIS est un serveur pour Windows qui utilise IIS. Avec ce serveur, l’application ASP.NET Core et IIS s’exécutent dans le même processus.
  • HTTP.sys est un serveur Windows qui n’est pas utilisé avec IIS.

Pour plus d’informations, consultez implémentations de serveur web dans ASP.NET Core.

Configuration

ASP.NET Core fournit une infrastructure de configuration qui obtient des paramètres en tant que paires nom-valeur à partir d’un ensemble ordonné de fournisseurs de configuration. Les fournisseurs de configuration intégrés sont disponibles pour diverses sources, telles que .json des fichiers, des fichiers, .xml des variables d’environnement et des arguments de ligne de commande. Écrivez des fournisseurs de configuration personnalisés pour prendre en charge d’autres sources.

Par défaut, ASP.NET Core applications sont configurées pour lire à partir des appsettings.jsonvariables d’environnement, la ligne de commande et bien plus encore. Lorsque la configuration de l’application est chargée, les valeurs des variables d’environnement remplacent les valeurs de appsettings.json.

La méthode préférée pour lire les valeurs de configuration associées utilise le modèle d’options. Pour plus d’informations, consultez Lier des données de configuration hiérarchiques à l’aide du modèle d’options.

Pour gérer les données de configuration confidentielles telles que les mots de passe, .NET Core fournit secret Manager. Pour les secrets de production, nous vous recommandons Azure Key Vault.

Pour plus d’informations, consultez Configuration dans ASP.NET Core.

Environnements

Les environnements d’exécution, tels que Development, Staginget Production, sont une notion de première classe dans ASP.NET Core. Spécifiez l’environnement dans lequel une application s’exécute en définissant la variable d’environnement ASPNETCORE_ENVIRONMENT . ASP.NET Core lit la variable d’environnement au démarrage de l’application et stocke la valeur dans une implémentation IWebHostEnvironment. Cette implémentation est disponible n’importe où dans une application via l’injection de dépendances (DI).

L’exemple suivant configure l’application pour fournir des informations détaillées sur les erreurs lors de l’exécution dans l’environnement Development :

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.MapDefaultControllerRoute();
        endpoints.MapRazorPages();
    });
}

Pour plus d’informations, consultez Utiliser plusieurs environnements dans ASP.NET Core.

Journalisation

ASP.NET Core prend en charge une API de journalisation qui fonctionne avec un large éventail de fournisseurs de journalisation intégrés et tiers. Les fournisseurs disponibles sont les suivants :

  • Console
  • Débogage
  • Suivi des événements sur Windows
  • Journal des événements Windows
  • TraceSource
  • Azure App Service
  • Azure Application Insights

Pour créer des journaux, résolvez un ILogger<TCategoryName> service à partir de l’injection de dépendances (DI) et appelez des méthodes de journalisation telles que LogInformation. Exemple :

public class TodoController : ControllerBase
{
    private readonly ILogger _logger;

    public TodoController(ILogger<TodoController> logger)
    {
        _logger = logger;
    }

    [HttpGet("{id}", Name = "GetTodo")]
    public ActionResult<TodoItem> GetById(string id)
    {
        _logger.LogInformation(LoggingEvents.GetItem, "Getting item {Id}", id);
        
        // Item lookup code removed.
        
        if (item == null)
        {
            _logger.LogWarning(LoggingEvents.GetItemNotFound, "GetById({Id}) NOT FOUND", id);
            return NotFound();
        }
        
        return item;
    }
}

Les méthodes de journalisation telles que LogInformation la prise en charge de n’importe quel nombre de champs. Ces champs sont couramment utilisés pour construire un message string, mais certains fournisseurs de journalisation les envoient à un magasin de données en tant que champs distincts. Cette fonctionnalité permet aux fournisseurs de journalisation d’implémenter la journalisation sémantique, également appelée journalisation structurée.

Pour plus d’informations, consultez Journalisation dans .NET Core et ASP.NET Core.

Routage

Un itinéraire est un modèle d’URL qui est mappé à un gestionnaire. Le gestionnaire est généralement une Razor page, une méthode d’action dans un contrôleur MVC ou un middleware. Le routage ASP.NET Core vous permet de contrôler les URL utilisées par votre application.

Pour plus d’informations, consultez Routage dans ASP.NET Core.

Gestion des erreurs

ASP.NET Core offre des fonctionnalités intégrées pour gérer des erreurs, telles que :

  • Une page d’exceptions du développeur
  • Pages d’erreur personnalisées
  • Pages de codes d’état statique
  • Gestion des exceptions de démarrage

Pour plus d’informations, consultez Gérer les erreurs dans ASP.NET Core.

Effectuer des requêtes HTTP

Une implémentation de IHttpClientFactory est disponible pour la création d’instances HttpClient. La fabrique :

  • Fournit un emplacement central pour le nommage et la configuration d’instance de HttpClient logiques. Par exemple, inscrivez et configurez un client github pour accéder à GitHub. Inscrivez et configurez un client par défaut à d’autres fins.
  • Prend en charge l’inscription et le chaînage de plusieurs gestionnaires de délégation pour créer un pipeline de middlewares pour les requêtes sortantes. Ce modèle est similaire au pipeline d’intergiciel entrant de ASP.NET Core. Le modèle fournit un mécanisme permettant de gérer les problèmes inter-coupes pour les requêtes HTTP, notamment la mise en cache, la gestion des erreurs, la sérialisation et la journalisation.
  • S’intègre à Polly, une bibliothèque tierce populaire pour la gestion des erreurs temporaires.
  • Gère le regroupement et la durée de vie des instances sous-jacentes HttpClientHandler pour éviter les problèmes DNS courants qui se produisent lors de la gestion HttpClient manuelle des durées de vie.
  • Ajoute une expérience de journalisation configurable par le biais ILogger de toutes les demandes envoyées par les clients créés par la fabrique.

Pour plus d’informations, consultez Effectuer des requêtes HTTP à l’aide d’IHttpClientFactory dans ASP.NET Core.

Racine de contenu

La racine de contenu est le chemin d’accès de base pour :

  • Exécutable hébergeant l’application (.exe).
  • Assemblys compilés qui composent l’application (.dll).
  • Fichiers de contenu utilisés par l’application, tels que :
    • Razor fichiers (.cshtml, .razor)
    • Fichiers de configuration (.json, .xml)
    • Fichiers de données (.db)
  • La racine web, généralement le dossier wwwroot .

Pendant le développement, la racine de contenu correspond par défaut au répertoire racine du projet. Ce répertoire est également le chemin d’accès de base pour les fichiers de contenu de l’application et la racine web. Spécifiez une autre racine de contenu en définissant son chemin lors de la génération de l’hôte. Pour plus d’informations, consultez Racine de contenu.

Racine web

La racine web est le chemin d’accès de base pour les fichiers de ressources statiques publics, tels que :

  • Feuilles de style (.css)
  • JavaScript (.js)
  • Images (.png, .jpg)

Par défaut, les fichiers statiques sont servis uniquement à partir du répertoire racine web et de ses sous-répertoires. Le chemin racine web est défini par défaut sur {content root}/wwwroot. Spécifiez une autre racine web en définissant son chemin d’accès lors de la génération de l’hôte. Pour plus d’informations, consultez Racine web.

Empêcher la publication de fichiers dans wwwroot avec l’élément< de projet de contenu> dans le fichier projet. L’exemple suivant empêche la publication de contenu dans wwwroot/local et ses sous-répertoires :

<ItemGroup>
  <Content Update="wwwroot\local\**\*.*" CopyToPublishDirectory="Never" />
</ItemGroup>

Dans Razor.cshtml les fichiers, tilde-slash (~/) pointe vers la racine web. Un chemin d’accès commençant par ~/ est appelé chemin d’accès virtuel.

Pour plus d’informations, consultez Fichiers statiques dans ASP.NET Core.