Panoramica dei concetti fondamentali di ASP.NET Core

Questo articolo offre una panoramica dei concetti fondamentali per la creazione di app ASP.NET Core, tra cui inserimento delle dipendenze (DI), configurazione e middleware.

Per la guida sui fondamentali di Blazor, che aggiunge o sostituisce le linee guida in questo articolo, vedere ASP.NET Core nozioni fondamentali Blazor.

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

Per altre informazioni, vedere Avvio dell'app in ASP.NET Core e ASP.NET Core Blazor avvio.

Iniezione di dipendenze (servizi)

ASP.NET Core include la funzionalità integrata di dependency injection (DI), che rende disponibili i servizi configurati in tutta l'applicazione per Inversion of Control (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();
}

Se il contenitore DI predefinito non soddisfa le tue esigenze, è possibile utilizzare invece un contenitore IoC di terze parti.

Per altre informazioni, vedere Inserimento delle dipendenze in ASP.NET Core e ASP.NET Core Blazor inserimento delle dipendenze.

Environments

Gli ambienti di esecuzione sono disponibili in ASP.NET Core, ad esempio:

• Development: quando l'app è in fase di sviluppo locale.
• Staging: Quando l'app viene preparata per la distribuzione.
• Production: quando l'app dinamica è in esecuzione per gli utenti.

Specificare l'ambiente in cui è in esecuzione un'app impostando la ASPNETCORE_ENVIRONMENT variabile di ambiente nell'host in cui è in esecuzione l'app. ASP.NET Core legge la variabile di ambiente all'avvio dell'app e archivia il valore per controllare l'esecuzione del codice nell'app.

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

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

    ...
}

Per altre informazioni, vedi ambienti di runtime di ASP.NET Core e ambienti di ASP.NET Core Blazor.

Middleware

La pipeline di gestione delle richieste è strutturata come una serie di componenti middleware. Ogni componente esegue operazioni su un HttpContext e richiama il middleware successivo nella pipeline oppure termina la richiesta.

Per convenzione, i componenti middleware vengono aggiunti alla pipeline richiamando un metodo di estensione che inizia con "Use". Nell'esempio seguente che rappresenta parte di una pipeline di elaborazione delle richieste, viene chiamato il middleware per la gestione delle eccezioni (UseExceptionHandler), il protocollo HSTS (HTTP Strict Transport Security) (UseHsts) e il reindirizzamento HTTPS (UseHttpsRedirection). Due dei middleware vengono attivati solo quando l'app non è in fase di sviluppo locale nell'ambiente Development , ad esempio quando l'app viene gestita per la distribuzione (l'ambiente Staging ) o nell'ambiente di produzione (ambiente 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 include un'ampia gamma di middleware predefiniti. È anche possibile creare componenti middleware personalizzati per soddisfare le specifiche speciali di elaborazione delle richieste di un'app. Per altre informazioni, vedere ASP.NET Core middleware.

Host

All'avvio, un'app ASP.NET Core crea un host. L'host incapsula tutte le risorse dell'app, ad esempio:

• Un'implementazione del server HTTP
• Componenti middleware
• Logging
• Servizi di iniezione di dipendenze
• 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>();
            });
}

Per ulteriori informazioni, vedi le seguenti risorse:

• .NET host generico in ASP.NET Core (scelta consigliata)
• ASP.NET Core Host Web (per compatibilità con le versioni precedenti)

Scenari non Web

L'host generico consente ad altri tipi di app di usare estensioni del framework trasversali, ad esempio la registrazione, l'inserimento delle dipendenze (DI), la configurazione e la gestione della durata delle app. Per altre informazioni, vedere Host generico .NET in ASP.NET Core e Attività in background con servizi ospitati in ASP.NET Core.

Servers

Un'app ASP.NET Core usa un'implementazione del server HTTP per l'ascolto delle richieste HTTP. Il server espone le richieste all'app come set di funzionalità di richiesta composte in un oggetto HttpContext.

Per altre informazioni, vedere Implementazioni del server Web in ASP.NET Core.

Windows

ASP.NET Core include le implementazioni server seguenti:

• Kestrel è un server Web multipiattaforma. Kestrel viene spesso eseguito in una configurazione di proxy inverso tramite IIS. In ASP.NET Core 2.0 o versione successiva Kestrel può essere eseguito come server perimetrale pubblico esposto direttamente a Internet.
• Server HTTP IIS è un server per Windows che usa IIS. Con questo server l'app ASP.NET Core e IIS sono eseguiti nello stesso processo.
• HTTP.sys è un server per Windows che non viene usato con IIS.

macOS e Linux

ASP.NET Core fornisce l'implementazione del server multipiattaforma Kestrel. In ASP.NET Core 2.0 o versione successiva Kestrel può essere eseguito come server perimetrale pubblico esposto direttamente a Internet. Kestrel viene spesso eseguito in una configurazione del proxy inverso con Nginx o Apache.

Configuration

ASP.NET Core fornisce un framework di configurazione che ottiene le impostazioni come coppie nome-valore da un set ordinato di provider di configurazione. I provider di configurazione predefiniti sono disponibili per un'ampia gamma di origini, ad esempio file JSON (.json), file XML (.xml), variabili di ambiente e argomenti della riga di comando. È possibile creare provider di configurazione personalizzati per supportare altre origini.

Per impostazione predefinita, le app ASP.NET Core sono configurate per la lettura dai file delle impostazioni dell'app (ad esempio , appsettings.json), le variabili di ambiente e la riga di comando.

Quando viene caricata la configurazione dell'app, i valori delle variabili di ambiente sostituiscono i valori dai file di impostazioni dell'app. L'API Opzioni è disponibile per la lettura dei valori di configurazione correlati.

Per la gestione dei dati di configurazione riservati, ad esempio le password nell'ambiente Development , .NET fornisce Secret Manager. Per i segreti di produzione, è consigliabile usare Azure Key Vault.

Per ulteriori informazioni, vedi le seguenti risorse:

• La configurazione in ASP.NET Core
• Configurazione Blazor di ASP.NET Core
• Azure Key Vault (documentazione di ASP.NET Core)

Logging

ASP.NET Core supporta un'API di registrazione che funziona con un'ampia gamma di provider di registrazione:

• Console
• Debug
• Tracciamento degli Eventi su Windows
• Registro eventi di Windows
• TraceSource
• Servizio app di Azure
• applicazione Azure Insights
• Fornitori di terze parti

Per creare log, risolvere un servizio ILogger<TCategoryName> dall'iniezione di dipendenze (DI) e chiamare i metodi di registrazione, ad esempio LogInformation. Un oggetto logger e un provider della console per l'oggetto logger vengono registrati automaticamente nel contenitore DI quando viene chiamato il metodo WebApplication.CreateBuilder.

L'esempio seguente illustra come ottenere un'istanza di registrazione dall'inserimento delle dipendenze e usarla in un Weather componente (Weather.razor) di un'app Blazor che segnala i dati meteo:

@inject ILogger<Weather> Logger

...

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

        ...
    }
}

Per altre informazioni, incluse le linee guida per il routing per Razor le app Pages e MVC, vedere Registrazione in .NET e ASP.NET Core eASP.NET Core Blazor registrazione.

Routing

Il routing in ASP.NET Core è un meccanismo che esegue il mapping delle richieste in ingresso a endpoint specifici in un'app. Consente di definire modelli url che corrispondono a componenti diversi, ad esempio componenti Razor, pagine Razor, azioni del controller MVC o middleware.

Il metodo UseRouting aggiunge il middleware di routing alla pipeline di richiesta. Questo middleware elabora le informazioni di routing e determina l'endpoint appropriato per ogni richiesta. Nelle app che usano l'host minimo, UseRouting non viene chiamato in modo esplicito nel codice dello sviluppatore, a meno che non si voglia modificare l'ordine di elaborazione del middleware.

Per ulteriori informazioni, vedi le seguenti risorse:

• Routing in ASP.NET Core
• ASP.NET Core Blazor routing
• Navigazione ASP.NET Core Blazor

Gestire gli errori

ASP.NET Core dispone di funzionalità predefinite per la gestione degli errori, ad esempio:

• Una pagina delle eccezioni per gli sviluppatori
• Pagine di errore personalizzate
• Pagine dei codici di stato statiche
• Gestione delle eccezioni durante l'avvio

Per altre informazioni, vedere Gestire gli errori in ASP.NET Core e Gestire gli errori nelle app ASP.NET CoreBlazor.

Effettuare richieste HTTP

Un'implementazione di IHttpClientFactory è disponibile per la creazione di istanze HttpClient. La fabbrica:

• Offre una posizione centrale per la denominazione e la configurazione di istanze logiche di HttpClient. Ad esempio, fare affidamento su un client predefinito per la maggior parte delle richieste di dati dell'app con un'API Web e registrare un client configurato diverso per l'accesso a GitHub.
• Supporta la registrazione e il concatenamento di più gestori di delega per creare una pipeline di middleware per le richieste in uscita. Questo modello è simile alla pipeline di middleware in ingresso di ASP.NET Core. Il modello offre un meccanismo per gestire le problematiche trasversali relative alle richieste HTTP, tra cui memorizzazione nella cache, gestione degli errori, serializzazione e registrazione.
• Si integra con Polly, una popolare libreria di terze parti per la gestione degli errori temporanei.
• Gestisce il pooling e la durata delle istanze di HttpClientHandler sottostanti per evitare problemi DNS comuni che si verificano quando le durate di HttpClient vengono gestite manualmente.
• Aggiunge un'esperienza di registrazione configurabile tramite ILogger per tutte le richieste inviate attraverso i client creati dalla factory.

Per altre informazioni, vedere Richieste HTTP con IHttpClientFactory - ASP.NET Core e Chiamare un'API Web da un'app ASP.NET CoreBlazor.

Radice del contenuto

La radice del contenuto è il percorso di base per:

• Eseguibile che ospita l'app (.exe).
• Assembly compilati che costituiscono l'app (.dll).
• File di contenuto usati dall'app, ad esempio Razor file (.cshtml, .razor), file di configurazione (.json, .xml) e file di dati (.db).
• La radice web, che in genere corrisponde alla cartella wwwroot.

Durante lo sviluppo, per impostazione predefinita la radice del contenuto è la directory radice del progetto. Questa directory è anche il percorso di base per i file di contenuto dell'app e la radice Web. Specificare una radice del contenuto diversa impostandone il percorso durante la compilazione dell'host.

Per altre informazioni, vedere .NET Host generico in ASP.NET Core e Gestire file statici nelle app ASP.NET Core.

Radice del sito

La radice Web è il percorso di base per i file di risorse statici pubblici, ad esempio fogli di stile, file JavaScript e immagini.

Per impostazione predefinita, i file statici vengono gestiti solo dalla directory radice Web e dalle relative sottodirectory. Per impostazione predefinita, il percorso radice Web è {CONTENT ROOT}/wwwroot, dove il segnaposto {CONTENT ROOT} è la radice del contenuto. Specificare una radice Web diversa impostandone il percorso durante la compilazione dell'host. È anche possibile impedire la pubblicazione dei file in wwwroot con <Content>l'elemento di progetto nel file di progetto dell'app.

Nei file Razor.cshtml, ~/ punta alla radice web. Un percorso che inizia con ~/ viene definito percorso virtuale.

Per altre informazioni, vedere .NET Host generico in ASP.NET Core e Gestire file statici nelle app ASP.NET Core.

Come scaricare un esempio

Molti articoli ed esercitazioni includono collegamenti al codice di esempio.

1. Scaricare il file ZIP del repository ASP.NET.
2. Decomprimere il file AspNetCore.Docs-main.zip.
3. Per accedere a un'app di esempio di un articolo nel repository decompresso, utilizzare l'URL fornito nel link di esempio dell'articolo per navigare alla cartella dell'esempio. In genere, il collegamento di esempio di un articolo viene visualizzato nella parte superiore dell'articolo con il testo del collegamento Visualizza o scarica il codice di esempio.

Per ottenere una singola app di esempio e solo il relativo ultimo commit, usare git sparse-checkout.

Nell'esempio seguente per gli Blazor esempi GitHub repository, il git sparse-checkout set comando specifica il percorso della cartella di esempio:

• Sostituire il segnaposto {VERSION FOLDER} con la cartella della versione.
• Sostituire il segnaposto {SAMPLE FOLDER} con la cartella di esempio.

In una shell di comando, passare alla cartella in cui si desidera clonare l'esempio. Eseguire i comandi seguenti nella shell dei comandi passando il percorso della cartella version/sample al git sparse-checkout set comando:

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'esempio di PowerShell seguente ottiene l'esempio 10.0 Blazor Web App e lo inserisce nella cartella documenti dell'utente usando il percorso di ~/documents PowerShell per il 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

Direttive per il preprocessore nel codice di esempio

Per illustrare più scenari, le app di esempio usano le #define direttive del preprocessore e #if-#else/#elif-#endif per compilare ed eseguire in modo selettivo sezioni diverse del codice di esempio. Per gli esempi che usano questo approccio, impostare la #define direttiva all'inizio dei file C# per definire il simbolo associato allo scenario da eseguire. Alcuni esempi richiedono la definizione del simbolo nella parte superiore di più file per eseguire uno scenario.

Ad esempio, l'elenco di simboli #define seguente indica che sono disponibili quattro scenari, ovvero uno scenario per simbolo. La configurazione di esempio corrente esegue lo scenario TemplateCode:

#define TemplateCode // or LogFromMain or ExpandDefault or FilterInCode

Per modificare l'esempio in modo che venga eseguito lo scenario ExpandDefault, definire il simbolo ExpandDefault e lasciare i simboli rimanenti con commento:

#define ExpandDefault // TemplateCode or LogFromMain or FilterInCode

Per altre informazioni sull'uso delle direttive del preprocessore C# per compilare in modo selettivo le sezioni di codice, vedere #define (Riferimenti per C#) e #if (Riferimenti per C#).

Aree nel codice di esempio

Alcune app di esempio contengono sezioni di codice racchiuse tra #region e #endregion direttive C#. Il sistema di compilazione della documentazione inserisce queste aree negli argomenti della documentazione di cui è stato eseguito il rendering.

I nomi delle aree in genere contengono la parola "frammento". L'esempio seguente mostra un'area denominata snippet_WebHostDefaults:

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

Il frammento di codice C# precedente viene fatto riferimento nel file markdown dell'argomento con la riga seguente:

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

È possibile ignorare o rimuovere le direttive #region e #endregion che circondano il codice. Non modificare il codice all'interno di queste direttive se si prevede di eseguire gli scenari di esempio descritti nell'argomento.

Per altre informazioni, vedere Contribuire alla documentazione di ASP.NET: Frammenti di codice.

DOM (Document Object Model)

I riferimenti al modello a oggetti documento in questo set di documentazione usano l'abbreviazione DOM.

Per altre informazioni, vedere Introduction to the DOM (MDN documentation) and Level 1 Document Object Model Specification (W3C).

Multipli di byte

Le dimensioni dei byte in .NET utilizzano prefissi metrici per multipli non decimali di byte basati su potenze di 1024.

Richieste di supporto

Solo i problemi correlati alla documentazione sono appropriati per il repository dotnet/AspNetCore.Docs. Per il supporto al prodotto, non aprire un problema relativo alla documentazione. Richiedere assistenza tramite uno o più dei canali di supporto seguenti:

• Stack Overflow per ASP.NET Core (con tag: asp.net-core)
• Stack Overflow di Blazor (contrassegnato con il tag: blazor)
• Team generale di ASP.NET Core su Slack
• Blazor Gitter

Per un potenziale bug nel framework o per fornire feedback sul prodotto, aprire una segnalazione per l'unità del prodotto ASP.NET Core nella sezione dotnet/aspnetcore issues. I report sui bug richiedono in genere quanto segue:

• Spiegazione chiara del problema: seguire le istruzioni nel modello di problema GitHub fornito dall'unità del prodotto quando si apre il problema.
• Progetto minimo per la riproduzione: pubblicare un progetto su GitHub che gli ingegneri dell'unità di prodotto possano scaricare ed eseguire. Collegare il progetto al commento di apertura dell'issue.

Per un potenziale problema con un articolo, aprire un problema di documentazione. Per aprire un problema di documentazione, usare il collegamento Open a documentation issue feedback (Apri un problema di documentazione) nella parte inferiore dell'articolo. I metadati aggiunti al problema forniscono dati di tracciamento e eseguono automaticamente il ping dell'autore dell'articolo. Se l'argomento è stato discusso con l'unità prodotto prima di aprire il problema della documentazione, inserire un collegamento incrociato al problema di progettazione nel commento di apertura del problema della documentazione.

I problemi di GitHub relativi alla documentazione di Blazor vengono contrassegnati automaticamente per il triage nel progetto Blazor.Docs (repository di dotnet/AspNetCore.Docs GitHub). Attendere un breve periodo di tempo per ricevere una risposta, soprattutto nei fine settimana e nei giorni festivi. In genere, gli autori della documentazione rispondono entro 24 ore nei giorni feriali.

Per problemi o feedback su Visual Studio, utilizzare le gesture Segnala un problema o Suggerisci una funzionalità da Visual Studio stesso, che aprono delle segnalazioni interne per Visual Studio. Per altre informazioni, vedere Visual Studio Feedback.

Per problemi relativi a Visual Studio Code, chiedere supporto nei forum di supporto della community. Per i report sui bug e il feedback sul prodotto, aprire un problema nel microsoft/vscode repository GitHub.

Contenuti correlati