Omówienie podstaw platformy ASP.NET Core

Ten artykuł zawiera omówienie podstaw tworzenia aplikacji ASP.NET Core, w tym wstrzykiwania zależności (DI), konfiguracji i oprogramowania pośredniczącego.

Aby uzyskać wskazówki dotyczące podstaw Blazor, które uzupełniają lub zastępują te zawarte w tym artykule, zobacz podstawy ASP.NET Core 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();
        });
    }
}

Aby uzyskać więcej informacji, zobacz Uruchamianie aplikacji w ASP.NET Core i uruchamianie platformy ASP.NET CoreBlazor.

Wstrzykiwanie zależności (usługi)

ASP.NET Core obejmuje wbudowane wstrzykiwanie zależności (DI), dzięki któremu skonfigurowane usługi są dostępne w całej aplikacji na potrzeby odwrócenia sterowania (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();
}

Jeśli wbudowany kontener di nie spełnia Twoich potrzeb, można zamiast tego użyć kontenera IoC innej firmy.

Aby uzyskać więcej informacji, zobacz Wstrzykiwanie zależności w ASP.NET Core i wstrzykiwanie zależności ASP.NET CoreBlazor.

Environments

W środowisku ASP.NET Core dostępne są środowiska uruchomieniowe, takie jak:

• Development: Gdy aplikacja działa w lokalnym środowisku programistycznym.
• Staging: Gdy aplikacja jest przygotowana do wdrożenia.
• Production: Gdy aplikacja na żywo jest uruchomiona dla użytkowników.

Określ środowisko, w którym działa aplikacja, ustawiając zmienną ASPNETCORE_ENVIRONMENT środowiskową na hoście, na którym działa aplikacja. ASP.NET Core odczytuje zmienną środowiskową podczas uruchamiania aplikacji i przechowuje wartość w celu kontrolowania wykonywania kodu wokół aplikacji.

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

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

    ...
}

Aby uzyskać więcej informacji, zobacz ASP.NET Core środowiska uruchomieniowe i środowiska ASP.NET CoreBlazor.

Middleware

Potok obsługi żądań składa się z serii składników oprogramowania pośredniczącego. Każdy składnik wykonuje operacje na HttpContext i albo wywołuje kolejne middleware w potoku, albo przerywa żądanie.

Zgodnie z konwencją składniki oprogramowania pośredniczącego są dodawane do potoku przez wywołanie metody rozszerzenia rozpoczynającej się od "Use". W poniższym przykładzie reprezentującym część potoku przetwarzania żądań wywoływane są oprogramowanie pośredniczące do obsługi wyjątków (UseExceptionHandler), protokółUseHstsHTTP Strict Transport Security (HSTS) i przekierowanie HTTPS (UseHttpsRedirection). Dwa elementy oprogramowania pośredniczącego są uruchamiane tylko wtedy, gdy aplikacja nie działa w lokalnym środowisku Development, na przykład w środowisku przejściowym aplikacji (Staging) lub w środowisku produkcyjnym (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();

Platforma ASP.NET Core posiada bogaty zestaw wbudowanego oprogramowania pośredniczącego. Możesz również utworzyć niestandardowe składniki oprogramowania pośredniczącego, aby spełnić specjalne specyfikacje przetwarzania żądań aplikacji. Aby uzyskać więcej informacji, zobacz ASP.NET Core oprogramowanie pośredniczące.

Host

Podczas uruchamiania aplikacja ASP.NET Core tworzy hosta. Host zawiera wszystkie zasoby aplikacji, takie jak:

• Wdrożenia serwera HTTP
• Składniki oprogramowania pośredniczącego
• Logging
• Usługi wstrzykiwania zależności
• 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>();
            });
}

Aby uzyskać więcej informacji, zobacz następujące zasoby:

• host ogólny .NET w ASP.NET Core (zalecane)
• ASP.NET Core host sieci Web (dla zachowania zgodności z poprzednimi wersjami)

Scenariusze inne niż internetowe

Host ogólny umożliwia innym typom aplikacji korzystanie z rozszerzeń platform krzyżowych, takich jak rejestrowanie, wstrzykiwanie zależności (DI), konfiguracja i zarządzanie okresem istnienia aplikacji. Aby uzyskać więcej informacji, zobacz sekcję Host ogólny .NET na platformie ASP.NET Core oraz Zadania w tle z usługami hostowanymi w ASP.NET Core.

Servers

Aplikacja platformy ASP.NET Core wykorzystuje wdrożenie serwera HTTP do nasłuchiwania żądań HTTP. Serwer udostępnia żądania do aplikacji jako zestaw funkcji żądań skomponowanych w ramach HttpContext.

Aby uzyskać więcej informacji, zobacz Implementacja serwera internetowego w środowisku ASP.NET Core.

Windows

Platforma ASP. NET Core obsługuje następujące wdrożenia serwera:

• Serwer Kestrel to wieloplatformowy serwer internetowy. Kestrel jest często uruchamiany w konfiguracji reverse proxy przy użyciu IIS. Na platformie ASP.NET Core w wersji 2.0 lub nowszej serwer Kestrel może być uruchamiany jako publiczny serwer brzegowy uwidoczniony bezpośrednio w Internecie.
• Serwer HTTP IIS to serwer dla systemu Windows wykorzystujący IIS. Na tym serwerze aplikacja ASP.NET Core i usługi IIS są uruchamiane w ramach tego samego procesu.
• HTTP.sys jest serwerem systemu Windows, który nie jest używany z usługami IIS.

macOS i Linux

Platforma ASP.NET Core udostępnia międzyplatformowe wdrożenia serwera Kestrel. Na platformie ASP.NET Core w wersji 2.0 lub nowszej serwer Kestrel może działać jako publiczny serwer brzegowy uwidoczniony bezpośrednio w Internecie. Kestrel jest często uruchamiany w konfiguracji reverse proxy z Nginx lub Apache.

Configuration

ASP.NET Core udostępnia mechanizm konfiguracji, który pobiera ustawienia w postaci par nazwa–wartość z uporządkowanego zestawu dostawców konfiguracji. Wbudowani dostawcy konfiguracji są dostępni dla różnych źródeł, takich jak pliki JSON (.json), pliki XML (.xml), zmienne środowiskowe i argumenty wiersza polecenia. Możesz utworzyć niestandardowych dostawców konfiguracji, aby obsługiwać inne źródła.

Domyślnie aplikacje ASP.NET Core są skonfigurowane do odczytywania z plików ustawień aplikacji (na przykład appsettings.json), zmiennych środowiskowych i wiersza polecenia.

Po załadowaniu konfiguracji aplikacji wartości ze zmiennych środowiskowych zastępują wartości z plików ustawień aplikacji. Interfejs Options API jest dostępny do odczytu powiązanych wartości konfiguracyjnych.

Do zarządzania poufnymi danymi konfiguracji, takimi jak hasła w Development środowisku, platforma .NET udostępnia program Secret Manager. W przypadku wpisów tajnych używanych w środowisku produkcyjnym zalecamy korzystanie z usługi Azure Key Vault.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Konfiguracja w programie ASP.NET Core
• Konfiguracja Blazor na platformie ASP.NET Core
• Azure Key Vault (dokumentacja ASP.NET Core)

Logging

ASP.NET Core obsługuje interfejs API rejestrowania, który współpracuje z różnymi dostawcami rejestrowania:

• Console
• Debug
• Śledzenie zdarzeń w systemie Windows
• Dzienniki zdarzeń systemu Windows
• TraceSource
• Azure App Service
• aplikacja systemu Azure Insights
• Zewnętrzni dostawcy

Aby tworzyć wpisy dziennika, pobierz usługę ILogger<TCategoryName> z mechanizmu wstrzykiwania zależności (DI) i wywołaj metody rejestrowania, takie jak LogInformation. Obiekt loggera i dostawca konsoli dla loggera są automatycznie przechowywane w kontenerze DI po wywołaniu metody WebApplication.CreateBuilder.

Poniższy przykład pokazuje, jak uzyskać instancję rejestratora z DI i użyć jej w komponencie Weather (Blazor) aplikacji Weather.razor, która raportuje dane pogodowe:

@inject ILogger<Weather> Logger

...

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

        ...
    }
}

Aby uzyskać więcej informacji, w tym wskazówki dotyczące routingu dla Razor aplikacji Pages i MVC, zobacz Rejestrowanie w .NET i ASP.NET Core i rejestrowanie ASP.NET CoreBlazor.

Routing

Routing w ASP.NET Core to mechanizm mapujący żądania przychodzące na określone punkty końcowe w aplikacji. Umożliwia definiowanie wzorców adresów URL odpowiadających różnym składnikom, takim jak składniki Razor, strony Razor, akcje kontrolera MVC lub oprogramowanie pośredniczące.

Metoda UseRouting dodaje oprogramowanie pośredniczące routingu do potoku żądania. To oprogramowanie pośredniczące przetwarza informacje o routingu i określa odpowiedni punkt końcowy dla każdego żądania. W aplikacjach korzystających z hosta minimalnego nie jest jawnie wywoływany w kodzie dewelopera, UseRouting chyba że chcesz zmienić kolejność przetwarzania oprogramowania pośredniczącego.

Aby uzyskać więcej informacji, zobacz następujące zasoby:

• Routing w ASP.NET Core
• ASP.NET Core Blazor — routing
• ASP.NET Core Blazor nawigacja

Zarządzanie błędami

Platforma ASP.NET Core ma wbudowane funkcje obsługi błędów, takie jak:

• Strona wyjątków dla deweloperów
• Niestandardowe strony błędów
• Statyczne strony kodów stanu
• Obsługa wyjątków uruchamiania

Aby uzyskać więcej informacji, zobacz Obsługa błędów w ASP.NET Core i Obsługa błędów w aplikacjach ASP.NET CoreBlazor.

Tworzenie żądań HTTP

Dostępna jest implementacja IHttpClientFactory do tworzenia wystąpień HttpClient. Fabryka

• Zapewnia centralną lokalizację nazewnictwa i konfigurowania wystąpień logicznych HttpClient. Na przykład polegaj na domyślnym kliencie dla większości żądań danych aplikacji za pomocą internetowego interfejsu API i zarejestruj innego skonfigurowanego klienta na potrzeby uzyskiwania dostępu do GitHub.
• Obsługuje rejestrację i łańczenie wielu obsług delegowania w celu utworzenia potoku middleware dla żądań wychodzących. Schemat ten jest podobny do potoku middleware dla ruchu przychodzącego na platformie ASP.NET Core. Ten wzorzec zapewnia mechanizm zarządzania przekrojowymi kwestiami dotyczącymi żądań HTTP, w tym buforowaniem, obsługą błędów, serializacją i rejestrowaniem.
• Integruje się z usługą Polly, popularną biblioteką innej firmy na potrzeby obsługi błędów przejściowych.
• Zarządza buforowaniem i cyklem życia podstawowych wystąpień HttpClientHandler w celu uniknięcia typowych problemów serwera DNS występujących podczas ręcznego zarządzania cyklami życia HttpClient.
• Dodaje konfigurowalny system logowania przy użyciu ILogger dla wszystkich żądań wysyłanych przez klientów utworzonych przez fabrykę.

Aby uzyskać więcej informacji, zobacz Żądania HTTP przy użyciu IHttpClientFactory — ASP.NET Core i Wywoływanie internetowego interfejsu API z aplikacji Blazor ASP.NET Core.

Katalog główny zawartości

Katalog główny zawartości to ścieżka podstawowa dla:

• Plik wykonywalny hostująca aplikację (.exe).
• Skompilowane zestawy tworzące aplikację (.dll).
• Pliki zawartości używane przez aplikację, takie jak Razor pliki (.cshtml, .razor), pliki konfiguracji (.json, .xml) i pliki danych (.db).
• Katalog główny sieci Web, który jest zazwyczaj folderem wwwroot .

Podczas programowania katalog główny zawartości domyślnie przyjmuje wartość katalogu głównego projektu. Ten katalog jest również ścieżką podstawową zarówno dla plików zawartości aplikacji, jak i katalogu głównego sieci Web. Określ inny katalog główny zawartości, ustawiając jego ścieżkę podczas kompilowania hosta.

Aby uzyskać więcej informacji, zobacz Host generyczny platformy .NET w ASP.NET Core i Serwowanie plików statycznych w aplikacjach ASP.NET Core.

Katalog główny sieci Web

Katalog główny witryny to ścieżka bazowa dla publicznie dostępnych zasobów statycznych, takich jak arkusze stylów, pliki JavaScript i obrazy.

Domyślnie pliki statyczne są obsługiwane tylko z katalogu głównego sieci Web i jego podkatalogów. Domyślna ścieżka katalogu głównego sieci Web to {CONTENT ROOT}/wwwroot, gdzie symbol zastępczy {CONTENT ROOT} jest katalogiem głównym zawartości. Określ inny internetowy katalog główny, ustawiając jego ścieżkę podczas tworzenia hosta. Możesz również zapobiec publikowaniu plików w wwwroot za pomocą <Content> elementu projektu w pliku projektu aplikacji.

W plikach Razor.cshtml znak ~/ wskazuje internetowy katalog główny. Ścieżka rozpoczynająca się od ~/ jest nazywana ścieżką wirtualną.

Aby uzyskać więcej informacji, zobacz Host generyczny platformy .NET w ASP.NET Core i Udostępnianie plików statycznych w aplikacjach ASP.NET Core.

Jak pobrać próbkę

Wiele artykułów i samouczków zawiera linki do kodu przykładowego.

1. Pobierz plik zip repozytorium ASP.NET.
2. Rozpakuj AspNetCore.Docs-main.zip plik.
3. Aby uzyskać dostęp do przykładowej aplikacji artykułu w rozpakowanym repozytorium, użyj adresu URL w linku do przykładu w artykule, aby ułatwić nawigację do folderu przykładu. Zazwyczaj przykładowy link artykułu jest wyświetlany w górnej części artykułu z linkiem Wyświetl lub pobierz przykładowy kod.

Aby uzyskać pojedynczą przykładową aplikację i tylko ostatni commit, użyj git sparse-checkout.

W poniższym przykładzie dla repozytorium GitHub z przykładami Blazor polecenie git sparse-checkout set określa ścieżkę do folderu przykładu:

• Zastąp symbol zastępczy {VERSION FOLDER} folderem wersji.
• Zastąp symbol zastępczy {SAMPLE FOLDER} folderem przykładowym.

W wierszu polecenia przejdź do folderu, w którym chcesz sklonować przykładowe repozytorium. Wykonaj następujące polecenia w powłoce systemowej, przekazując ścieżkę do folderu version/sample do polecenia 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}

Poniższy przykład programu PowerShell pobiera przykład w wersji 10.0 Blazor Web App i umieszcza go w folderze Dokumenty użytkownika przy użyciu ścieżki programu PowerShell ~/documents dla polecenia zmiany katalogu (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

Dyrektywy preprocesora w przykładowym kodzie

Aby zademonstrować wiele scenariuszy, przykładowe aplikacje używają #define dyrektyw preprocesora i #if-#else/#elif-#endif do selektywnego kompilowania i uruchamiania różnych sekcji przykładowego kodu. W przypadku tych przykładów, które korzystają z tego podejścia, ustaw dyrektywę #define w górnej części plików języka C#, aby zdefiniować symbol skojarzony ze scenariuszem, który chcesz uruchomić. Niektóre przykłady wymagają zdefiniowania symbolu w górnej części wielu plików w celu uruchomienia scenariusza.

Na przykład następująca lista symboli #define wskazuje, że są dostępne cztery scenariusze (jeden scenariusz na symbol). Bieżąca konfiguracja przykładowa uruchamia scenariusz TemplateCode:

#define TemplateCode // or LogFromMain or ExpandDefault or FilterInCode

Aby zmienić przykład, aby uruchomić scenariusz ExpandDefault, skonfiguruj symbol ExpandDefault i pozostaw pozostałe symbole zakomentowane.

#define ExpandDefault // TemplateCode or LogFromMain or FilterInCode

Aby uzyskać więcej informacji na temat używania dyrektyw preprocesora języka C# do selektywnego kompilowania sekcji kodu, zobacz #define (odwołanie w C#) i #if (odwołanie w C#).

Regiony w przykładowym kodzie

Niektóre przykładowe aplikacje zawierają sekcje kodu otoczone dyrektywami #region i #endregion języka C#. System kompilacji dokumentacji wprowadza te regiony do renderowanych tematów dokumentacji.

Nazwy regionów zwykle zawierają słowo "fragment kodu". W poniższym przykładzie pokazano region o nazwie snippet_WebHostDefaults:

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

Powyższy fragment kodu w języku C# jest odwołany w pliku markdown tematu za pomocą następującej linii:

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

Możesz bezpiecznie zignorować lub usunąć dyrektywy #region i #endregion, które otaczają kod. Nie zmieniaj kodu w tych dyrektywach, jeśli planujesz uruchomić przykładowe scenariusze opisane w temacie.

Aby uzyskać więcej informacji, zobacz Współtworzenie dokumentacji ASP.NET: fragmenty kodu.

Model obiektów dokumentu (DOM)

Odwołania do modelu obiektów dokumentów w tym zestawie dokumentacji używają skrótu DOM.

Aby uzyskać więcej informacji, zobacz Wprowadzenie do dokumentacji MODELU DOM (MDN) i Specyfikacji modelu obiektów dokumentów na poziomie 1 (W3C).

Wielokrotny bajt

Rozmiary bajtów w platformie .NET używają przedrostków metrycznych dla wielokrotności nie dziesiętnej bajtów na podstawie potęg liczby 1024.

Prośby o pomoc techniczną

Tylko problemy związane z dokumentacją są odpowiednie dla repozytorium dotnet/AspNetCore.Docs. W celu uzyskania pomocy technicznej dotyczącej produktów nie otwieraj problemu z dokumentacją. Poszukaj pomocy za pośrednictwem co najmniej jednego z następujących kanałów pomocy technicznej:

• Stack Overflow dla ASP.NET Core (oznakowane: asp.net-core)
• Stack Overflow dla Blazor (oznaczone tagiem: blazor)
• Ogólny zespół ASP.NET Core Slack
• Blazor Gitter

W przypadku potencjalnej usterki w frameworku lub opinii o produkcie, zgłoś problem dotyczący jednostki produktu ASP.NET Core w sekcji dotnet/aspnetcore Problemy. Raporty o błędach zwykle wymagają następujących elementów:

• Jasne wyjaśnienie problemu: postępuj zgodnie z instrukcjami w szablonie problemu w serwisie GitHub udostępnionym dla jednostki produktu podczas otwierania problemu.
• Minimalny projekt reprodukcji: Umieść projekt na GitHubie, aby inżynierowie jednostki produktowej mogli go pobrać i uruchomić. Utwórz wzajemne połączenie między projektem a otwierającym komentarzem zagadnienia.

W przypadku potencjalnego problemu z artykułem otwórz problem z dokumentacją. Aby otworzyć problem z dokumentacją, użyj linku Otwórz opinię dotyczącą problemu z dokumentacją w dolnej części artykułu. Metadane dodane do zgłoszenia udostępniają dane śledzenia i automatycznie powiadamiają autora artykułu. Jeśli temat został omówiony z jednostką produktu przed otwarciem problemu z dokumentacją, umieść link krzyżowy do problemu inżynieryjnego w komentarzu otwierającym problem z dokumentacją.

Problemy w serwisie GitHub dotyczące dokumentacji Blazor są automatycznie oznaczane do klasyfikacji w projekcie Blazor.Docs (repozytorium dotnet/AspNetCore.Docs w serwisie GitHub). Poczekaj nieco na odpowiedź, zwłaszcza w weekendy i święta. Zwykle autorzy dokumentacji reagują w ciągu 24 godzin w dni powszednie.

W przypadku problemów lub opinii dotyczących Visual Studio użyj gestów Raportuj problem lub Zaproponuj funkcję za pomocą Visual Studio, które otwierają zgłoszenia wewnętrzne dotyczące Visual Studio. Aby uzyskać więcej informacji, zobacz Visual Studio Feedback.

W przypadku problemów z programem Visual Studio Code poproś o pomoc techniczną na forach pomocy technicznej społeczności. W przypadku raportów o usterce i opinii o produktach otwórz problem w repozytorium microsoft/vscode GitHub.

Dodatkowe zasoby