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, y compris l’injection de dépendances (DI), la configuration et les intergiciels.

Pour des conseils sur les principes fondamentaux sur Blazor, qui complètent ou remplacent les conseils de cet article, voir les principes fondamentaux d'ASP.NET CoreBlazor.

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

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

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

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

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 démarrage de l’application dans ASP.NET Core et ASP.NET Core Blazor démarrage.

Injection de dépendances (services)

ASP.NET Core intègre un mécanisme d’injection de dépendance (DI) qui rend les services configurés disponibles dans toute l’application pour l’inversion de contrôle (IoC).

var builder = WebApplication.CreateBuilder(args);

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

builder.Services.AddServerSideBlazor();

@inject NavigationManager Navigation

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

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

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

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

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

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

Si le conteneur D DI intégré ne répond pas à vos besoins, un conteneur IoC tiers peut être utilisé à la place.

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

Environments

Les environnements d’exécution sont disponibles dans ASP.NET Core, tels que :

• Development: Lorsque l’application est en développement local.
• Staging: Lorsque l’application est préparée pour le déploiement.
• Production: Lorsque l’application active est en cours d’exécution pour les utilisateurs.

Spécifiez l’environnement dans lequel une application s’exécute en définissant la ASPNETCORE_ENVIRONMENT variable d’environnement sur l’hôte où l’application est en cours d’exécution. ASP.NET Core lit la variable d’environnement au démarrage de l’application et stocke la valeur pour contrôler l’exécution du code autour de l’application.

if (!app.Environment.IsDevelopment())
{
    ...
}

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

    ...
}

Pour plus d’informations, consultez ASP.NET Core environnements d’exécution et ASP.NET Core Blazor environnements.

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, puis appelle le middleware suivant dans le pipeline, ou met fin à la requête.

Par convention, les composants intergiciels sont ajoutés au pipeline en appelant une méthode d’extension commençant par «Use ». Dans l’exemple suivant représentant une partie d’un pipeline de traitement des demandes, l’intergiciel pour la gestion des exceptions (UseExceptionHandler), le protocole HSTS (UseHstsHTTP Strict Transport Security) et la redirection HTTPS (UseHttpsRedirection) sont appelés. Deux des intergiciels sont déclenchés uniquement lorsque l’application n’est pas en cours de développement local dans l’environnement Development , par exemple lorsque l’application est intermédiaire pour le déploiement (l’environnement Staging ) ou en production (l’environnement 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 comprend un vaste ensemble de middlewares intégrés. Vous pouvez également créer des composants intergiciels personnalisés pour répondre aux spécifications spéciales de traitement des demandes d’une application. Pour plus d’informations, consultez ASP.NET Core intergiciel.

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, par exemple :

• Une implémentation serveur HTTP
• Composants d’intergiciel
• Logging
• Services d’injection de dépendances
• Configuration

var builder = WebApplication.CreateBuilder(args);

...

var app = builder.Build();

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

Pour plus d’informations, consultez les ressources suivantes :

• hôte générique .NET dans ASP.NET Core (recommandé)
• hôte web ASP.NET Core (pour la compatibilité descendante)

Scénarios non web

L’hôte générique permet à d’autres types d’applications d’utiliser des extensions de framework multi-coupe, telles que la journalisation, l’injection de dépendances (DI), la configuration et la gestion de la durée de vie des applications. Pour plus d’informations, consultez Hôte générique .NET dans ASP.NET Core et Tâches en arrière-plan avec des services hébergés dans ASP.NET Core.

Servers

Une application ASP.NET Core utilise une implémentation de serveur HTTP pour écouter les requêtes HTTP. Le serveur expose les requêtes à l’application sous la forme d’un ensemble de fonctionnalités de requête composées en un HttpContext.

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

Windows

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 2.0 ou les versions ultérieures, Kestrel peut être exécuté en tant que serveur de périphérie 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 pour Windows qui n’est pas utilisé avec IIS.

macOS et Linux

ASP.NET Core fournit l’implémentation du serveur multiplateforme Kestrel. Dans ASP.NET Core 2.0 ou les versions ultérieures, Kestrel peut s’exécuter en tant que serveur de périphérie public exposé directement à Internet. Kestrel est souvent exécuté dans une configuration de proxy inverse avec Nginx ou Apache.

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 des fichiers JSON (.json), des fichiers XML (.xml), des variables d’environnement et des arguments de ligne de commande. Vous pouvez créer 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 fichiers de paramètres d’application (par exemple, appsettings.json), les variables d’environnement et la ligne de commande.

Lorsque la configuration de l’application est chargée, les valeurs des variables d’environnement remplacent les valeurs des fichiers de paramètres d’application. L’API Options est disponible pour lire les valeurs de configuration associées.

Pour gérer les données de configuration confidentielles telles que les mots de passe dans l’environnement Development , .NET fournit le Gestionnaire de secrets. Pour les secrets de production, nous vous recommandons d’utiliser Azure Key Vault.

Pour plus d’informations, consultez les ressources suivantes :

• Configuration dans ASP.NET Core
• configuration d’ASP.NET Core Blazor
• Azure Key Vault (documentation ASP.NET Core)

Logging

ASP.NET Core prend en charge une API de journalisation qui fonctionne avec divers fournisseurs de journalisation :

• Console
• Debug
• Suivi des événements sur Windows
• Journal des événements Windows
• TraceSource
• Azure App Service
• Azure Application Insights
• Fournisseurs tiers

Pour créer des logs, résolvez un service ILogger<TCategoryName> depuis l’injection de dépendances (DI) et appelez des méthodes de journalisation, telles que LogInformation. Un objet logger et un fournisseur de console pour cet objet logger sont automatiquement stockés dans le conteneur DI lorsque la méthode WebApplication.CreateBuilder est appelée.

L’exemple suivant montre comment obtenir une instance de journalisation à partir de di et l’utiliser dans un Weather composant (Weather.razor) d’une Blazor application qui signale des données météorologiques :

@inject ILogger<Weather> Logger

...

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

        ...
    }
}

Pour plus d’informations, notamment des conseils de routage pour les applications Razor Pages et MVC, consultez Journalisation dans .NET et ASP.NET Core et journalisation dans ASP.NET CoreBlazor.

Routing

Le routage dans ASP.NET Core est un mécanisme qui mappe les requêtes entrantes à des points de terminaison spécifiques dans une application. Il vous permet de définir des modèles d’URL qui correspondent à différents composants, tels que des composants Razor, des pages Razor, des actions de contrôleur MVC ou des intergiciels.

La méthode UseRouting ajoute un intergiciel de routage au pipeline de requête. Ce middleware traite les informations de routage et détermine le point de terminaison approprié pour chaque requête. Dans les applications utilisant l’hôte minimal, UseRouting n’est pas explicitement appelée dans le code du développeur, sauf si vous souhaitez modifier l’ordre de traitement des intergiciels.

Pour plus d’informations, consultez les ressources suivantes :

• Routing dans ASP.NET Core
• ASP.NET Core Blazorroutage
• navigation de ASP.NET Core Blazor

Gérer les 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 et Gérer les erreurs dans les applications ASP.NET CoreBlazor.

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, utilisez un client par défaut pour la plupart des demandes de données de l'application avec une API web et inscrivez un autre client configuré pour accéder à GitHub.
• 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 de middleware entrant d’ASP.NET Core. Le modèle fournit un mécanisme permettant de gérer les problèmes transversaux 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 de HttpClientHandler sous-jacentes pour éviter les problèmes DNS courants qui se produisent durant la gestion manuelle des durées de vie de HttpClient.
• Ajoute une expérience de journalisation configurable (via ILogger) pour toutes les requêtes envoyées via les clients créés par la fabrique.

Pour plus d’informations, consultez les requêtes HTTP avec IHttpClientFactory - ASP.NET Core et appeler une API web à partir d’une application ASP.NET CoreBlazor.

Racine du contenu

La racine du contenu est le chemin de base pour :

• Exécutable hébergeant l’application (.exe).
• Assemblages compilés qui constituent l’application (.dll).
• Fichiers de contenu utilisés par l’application, tels que Razor les fichiers (.cshtml, .razor), les fichiers de configuration (.json, .xmlet les fichiers de données)..db
• La racine web, qui correspond généralement au dossier wwwroot.

Durant le développement, la racine du 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 .NET hôte générique dans ASP.NET Core et servez des fichiers statiques dans des applications ASP.NET Core.

Racine web

La racine web est le chemin d’accès de base pour les fichiers de ressources publiques, statiques, tels que les feuilles de style, les fichiers JavaScript et les images.

Par défaut, les fichiers statiques sont uniquement servis à 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, où l’espace réservé {CONTENT ROOT} est la racine de contenu. Spécifiez une autre racine web en définissant son chemin au moment de la génération de l’hôte. Vous pouvez également empêcher la publication de fichiers dans wwwroot avec l’<Content>élément de projet dans le fichier de projet de l’application.

Dans les fichiers Razor.cshtml, ~/ 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 .NET hôte générique dans ASP.NET Core et servez des fichiers statiques dans des applications ASP.NET Core.

Comment télécharger un exemple

La plupart des articles et tutoriels contiennent des liens vers des exemples de code.

1. Téléchargez le fichier zip du dépôt ASP.NET.
2. Décompressez le fichier AspNetCore.Docs-main.zip.
3. Pour accéder à l’exemple d’application d’un article dans le référentiel décompressé, utilisez l’URL du lien de l’exemple de cet article. En règle générale, l’exemple de lien d’un article apparaît en haut de l’article avec le texte de lien Afficher ou télécharger l’exemple de code.

Pour obtenir un exemple d’application unique et uniquement sa dernière validation, utilisez git sparse-checkout.

Dans l’exemple suivant pour le Blazor dépôt GitHub des exemples, la commande git sparse-checkout set spécifie le chemin d’accès vers le dossier d’exemple :

• Remplacez l’espace {VERSION FOLDER} réservé par le dossier de version.
• Remplacez l’espace réservé {SAMPLE FOLDER} par le dossier d’exemple.

Dans un interpréteur de commandes, accédez au dossier dans lequel vous souhaitez cloner l’exemple. Exécutez les commandes suivantes dans l’interpréteur de commandes en passant à la commande git sparse-checkout set le chemin du dossier version/sample :

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}

L’exemple PowerShell suivant obtient l’exemple 10.0 Blazor Web App et le place dans le dossier documents de l’utilisateur à l’aide du chemin d’accès de ~/documents PowerShell pour la commande 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

Directives de préprocesseur dans l’exemple de code

Pour montrer plusieurs scénarios, les exemples d’applications utilisent les directives pré-processeur #define et #if-#else/#elif-#endif pour compiler et exécuter différentes sections de l’exemple de code de manière sélective. Pour ces exemples qui utilisent cette approche, définissez la directive #define en haut des fichiers C# pour définir le symbole associé au scénario que vous souhaitez exécuter. Certains exemples exigent que vous définissiez le symbole en haut de plusieurs fichiers afin d’exécuter un scénario.

Par exemple, la liste des symboles #define suivante indique que les quatre scénarios sont disponibles (un scénario par symbole). La configuration actuelle de l’exemple exécute le scénario TemplateCode :

#define TemplateCode // or LogFromMain or ExpandDefault or FilterInCode

Pour que l’exemple exécute le scénario ExpandDefault, définissez le symbole ExpandDefault et laissez les symboles restants commentés :

#define ExpandDefault // TemplateCode or LogFromMain or FilterInCode

Pour plus d’informations sur l’utilisation des directives de préprocesseur C# pour compiler de manière sélective des sections de code, consultez #define (référence C#) et #if (référence C#).

Régions dans l’exemple de code

Certains exemples d’applications contiennent des sections de code entourées de directives #region et #endregion C#. Le système de génération de documentation injecte ces régions dans les rubriques de documentation rendues.

Les noms de région contiennent généralement le mot « extrait de code ». L’exemple suivant montre une région nommée snippet_WebHostDefaults:

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

L’extrait de code C# précédent est référencé dans le fichier markdown de la rubrique avec la ligne suivante :

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

Vous pouvez ignorer ou supprimer en toute sécurité les directives #region et #endregion qui entourent le code. Ne modifiez pas le code dans ces directives si vous envisagez d’exécuter les exemples de scénarios décrits dans la rubrique.

Pour plus d’informations, consultez Contribuer à la documentation ASP.NET : extraits de code.

DOM (Document Object Model)

Les références au modèle objet document tout au long de ce jeu de documentation utilisent l’abréviation DOM.

Pour plus d’informations, consultez présentation de la documentation DOM (MDN) et de la spécification W3C (Document Object Model Specification) de niveau 1.

Multiples d’octets

. Les tailles d'octet .NET utilisent des préfixes métriques pour les multiples non décimaux d'octets en fonction des puissances de 1024.

Demandes de support

Seuls les problèmes liés à la documentation sont appropriés pour le dépôt dotnet/AspNetCore.Docs. Pour la prise en charge des produits, n’ouvrez pas de problème de documentation. Demandez de l’aide par un ou plusieurs des canaux de support suivants :

• Stack Overflow pour ASP.NET Core (étiqueté : asp.net-core)
• Stack Overflow pour Blazor (avec le tag : blazor)
• Équipe ASP.NET Core Slack générale
• Blazor Gitter

Pour un bogue potentiel dans l’infrastructure ou les commentaires sur les produits, ouvrez un problème pour l’unité de produit ASP.NET Core dans dotnet/aspnetcore Problèmes. Les rapports de bogues nécessitent généralement les éléments suivants :

• Explication du problème : suivez les instructions du modèle de problème GitHub fourni par l’unité de produit lors de l’ouverture du problème.
• Projet de repro minimal : placez un projet sur GitHub à l'intention des ingénieurs de l'unité produit pour qu'ils puissent le télécharger et l'exécuter. Placez un lien croisé vers le projet dans le commentaire d’ouverture du problème.

Pour un problème potentiel avec un article, ouvrez un problème de documentation. Pour signaler un problème de documentation, utilisez le lien de commentaires Ouvrir un problème de documentation en bas de l’article. Les métadonnées ajoutées à votre problème fournissent des données de suivi et envoient un ping automatique à l’auteur de l’article. Si le sujet a été discuté avec l’unité de produit avant l’ouverture du problème de documentation, placez un lien croisé vers le problème d’ingénierie dans le commentaire d’ouverture du problème de documentation.

Les problèmes GitHub concernant la documentation Blazor sont automatiquement marqués pour triage dans le projet Blazor.Docs (dotnet/AspNetCore.Docsdépôt GitHub). Patientez un peu avant d’obtenir une réponse, en particulier pendant les week-ends et les jours fériés. En règle générale, les auteurs de documentation répondent dans les 24 h les jours de semaine.

Pour des problèmes ou des commentaires concernant Visual Studio, utilisez les options Signaler un problème ou Suggérer une fonctionnalité depuis Visual Studio pour ouvrir des problèmes internes de Visual Studio. Pour plus d’informations, consultez Visual Studio Commentaires.

Pour des problèmes avec Visual Studio Code, demandez de l’aide sur les forums de soutien de la communauté. Pour les rapports de bogues et les commentaires sur les produits, ouvrez un problème sur le microsoft/vscode GitHub référentiel.

Contenu connexe