Übersicht über Grundlagen von ASP.NET Core

Note

Dies ist nicht die neueste Version dieses Artikels. Die aktuelle Version finden Sie in der .NET 10-Version dieses Artikels.

Warning

Diese Version von ASP.NET Core wird nicht mehr unterstützt. Weitere Informationen finden Sie in der Supportrichtlinie für .NET und .NET Core. Die aktuelle Version finden Sie in der .NET 10-Version dieses Artikels.

Dieser Artikel enthält eine Übersicht über die Grundlagen zum Erstellen von ASP.NET Core-Apps, einschließlich Abhängigkeitsinjektion (Dependency Injection, DI), Konfiguration und Middleware.

Informationen zu Blazor wichtigen Anleitungen, die die Anleitungen in diesem Artikel ergänzen oder ersetzen, finden Sie unter ASP.NET CoreBlazor – Grundlagen.

Die `Program`-Datei.

ASP.NET Core apps, die aus den Projektvorlagen des Frameworks erstellt wurden, enthalten Startcode in der Program Datei (Program.cs). Für die Datei Program gilt Folgendes:

werden die von der App erforderlichen Dienste konfiguriert.
Die Anforderungsverarbeitungspipeline der App wird als eine Reihe von Middleware-Komponenten definiert.

Der folgende App-Startcode unterstützt zwei App-Typen:

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

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

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

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

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

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

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

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

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

// Run the app
app.Run();

Note

Mit zusätzlicher Konfiguration in der Program Datei können ASP.NET Core Apps Seiten, MVC und Web-API mit Controllern unterstützenRazor.

Der folgende App-Startcode unterstützt zwei App-Typen:

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

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

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

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

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

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

// Add antiforgery middleware
app.UseAntiforgery();

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

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

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

// Run the app
app.Run();

Note

Mit zusätzlicher Konfiguration in der Program Datei können ASP.NET Core Apps Seiten, MVC und Web-API mit Controllern unterstützenRazor.

Der folgende App-Startcode unterstützt mehrere App-Typen:

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

Der nachstehende App-Startcode unterstützt Folgendes:

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

Die `Startup`-Klasse

Die Startup-Klasse (Startup.cs) ist die Stelle, an der:

Dienste, die von der App benötigt werden, werden in der ConfigureServices Methode konfiguriert.
Die Anforderungsverarbeitungspipeline der App wird in der Configure Methode als eine Reihe von Middleware-Komponenten definiert.

Der nachstehende App-Startcode unterstützt Folgendes:

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

Weitere Informationen finden Sie unter App-Start in ASP.NET Core und ASP.NET Core Blazor Start.

Abhängigkeitsinjektion (Dienste)

ASP.NET Core verfügt über eine integrierte Abhängigkeitsinjektion (DI), die konfigurierte Dienste in der gesamten App für Inversion of Control (IoC) verfügbar macht.

Wenn die Instanziierung von WebApplicationBuilder durch Aufrufen von WebApplication.CreateBuilder erfolgt, werden vom Framework bereitgestellte Dienste automatisch hinzugefügt, z. B. Dienste für Konfiguration und Protokollierung:

var builder = WebApplication.CreateBuilder(args);

Zusätzliche Dienste werden dem DI-Container mit WebApplicationBuilder.Serviceshinzugefügt. Im folgenden Beispiel werden BlazorDienste registriert:

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

builder.Services.AddServerSideBlazor();

Das DI-Framework stellt Instanzen angeforderter Dienste zur Laufzeit bereit. In Blazor Apps werden Dienste häufig zur Laufzeit aus DI mithilfe der @inject Direktive in einer Razor Komponentendatei (.razor) aufgelöst. Im folgenden Beispiel verwendet die Komponente die Abstraktion NavigationManager, um eine Instanz des Navigations-Managers abzurufen, der zum Abfragen und Verwalten der URI-Navigation verwendet wird, um den Benutzer beim Auswählen der Schaltfläche zu einer Produktseite unter /products zu navigieren:

@inject NavigationManager Navigation

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

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

Eine weitere Möglichkeit, einen Dienst über DI aufzulösen, ist die Verwendung der Konstruktorinjektion. Im folgenden Beispiel verwendet der primäre Konstruktor (C# 12 oder höher) Parameter der Typen AppDbContext und ILogger<OrderProcessor> löst sie zur Laufzeit in die context Und logger Variablen (die Instanzen der Datenbank und protokollierungsabstraktionen) auf. Die Datenbankkontextinstanz wird verwendet, um alle Bestellungen zu verarbeiten, in denen sich das IsProcessed Feld in der Datenbank befindet false , und jede verarbeitete Bestellung wird mithilfe der Loggerinstanz als Informationen mit der Auftrags-ID (OrderId) protokolliert:

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

Sie können Abhängigkeiten auch direkt in die Lambda-Parameter von minimalen API-Endpunkten einfügen. Im folgenden Beispiel wird eine Liste von Todoelementen vom /todos Endpunkt zurückgegeben. Mit einer Loggerinstanz für ILogger<Program> werden Informationen protokolliert, und die Datenbankinstanz für AppDbContext wird verwendet, um die Liste der Todo-Elemente aus der Datenbank für die Antwort abzurufen:

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

Wenn die Host.CreateDefaultBuilderProgram Datei aufgerufen wird, wird automatisch eine neue Instanz der HostBuilder Klasse mit vom Framework bereitgestellten Diensten initialisiert, z. B. Dienste für Konfiguration und Protokollierung:

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

Zusätzliche Dienste werden der Dienstsammlung des DI-Containers (Startup.ConfigureServices) in der Methode IServiceCollection (Startup.cs) hinzugefügt. Im folgenden Beispiel werden MVC- und Razor Pages-Dienste registriert:

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

Dienste werden üblicherweise mit einer Constructor Injection aus der DI aufgelöst. Bei der Constructor Injection deklariert eine Klasse einen Konstruktorparameter des erforderlichen Typs oder einer Schnittstelle. Das DI-Framework stellt eine Instanz des Diensts zur Laufzeit bereit.

Wenn der integrierte DI-Container Ihre Anforderungen nicht erfüllt, kann stattdessen ein IoC-Container eines Drittanbieters verwendet werden.

Weitere Informationen finden Sie unter Dependency Injection in ASP.NET Core und ASP.NET Core Blazor Abhängigkeitsinjektion.

Environments

Ausführungsumgebungen sind in ASP.NET Core verfügbar, z. B.:

Development: Wenn sich die App in der lokalen Entwicklung befindet.
Staging: Wenn die App für die Bereitstellung vorbereitet wird.
Production: Wenn die App für Benutzer live ist.

Geben Sie die Umgebung an, in der eine App ausgeführt wird, indem Sie die ASPNETCORE_ENVIRONMENT Umgebungsvariable auf dem Host festlegen, auf dem die App ausgeführt wird. ASP.NET Core liest die Umgebungsvariable beim App-Start und speichert den Wert zum Steuern der Codeausführung in der App.

Entwicklercode kann nach einer bestimmten Umgebung suchen. Im folgenden Program Dateibeispiel wird der Code im Ausführungsblock nur ausgeführt, wenn die App nicht in der Development Umgebung ausgeführt wird:

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

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

    ...
}

Weitere Informationen finden Sie unter ASP.NET Core Laufzeitumgebungen und ASP.NET Core Blazor Umgebungen.

Middleware

Die Pipeline zur Anforderungsverarbeitung besteht aus mehreren Middlewarekomponenten. Jede Komponente führt Vorgänge in einem HttpContext aus und ruft anschließend entweder die nächste Middleware in der Pipeline auf oder beendet die Anforderung.

Standardmäßig werden Middleware-Komponenten zur Pipeline hinzugefügt, indem sie eine Erweiterungsmethode aufrufen, die mit "Use" beginnt. Im folgenden Beispiel, das Teil einer Anforderungsverarbeitungspipeline darstellt, werden Middleware für die Ausnahmebehandlung (), das HTTP Strict Transport Security (HSTS)-Protokoll (UseHsts) und die HTTPS-Umleitung (UseHttpsRedirection) aufgerufen.UseExceptionHandler Zwei der Middleware-Komponenten werden nur ausgelöst, wenn die App nicht in der lokalen Entwicklungsumgebung (Development) ausgeführt wird, etwa wenn die App für die Bereitstellung vorbereitet ist (die Staging-Umgebung) oder in der Produktion (die Production-Umgebung):

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 enthält zahlreiche integrierte Middlewareanwendungen. Sie können auch benutzerdefinierte Middleware-Komponenten erstellen, um die speziellen Anforderungsverarbeitungsspezifikationen einer App zu erfüllen. Weitere Informationen finden Sie unter ASP.NET Core Middleware.

Host

Beim Start erstellt eine ASP.NET Core-App einen Host. Der Host kapselt alle Ressourcen der App, zum Beispiel:

eine HTTP-Serverimplementierung
Middleware-Komponenten
Logging
DI-Dienste
Configuration

Es gibt drei verschiedene Hosts, die eine ASP.NET Core-App ausführen können:

ASP.NET Core WebApplication (auch als Minimalhost bezeichnet)
Generischer .NET-Host
ASP.NET Core WebHost

Die ASP.NET Core WebApplication und WebApplicationBuilder Typen werden empfohlen und in allen ASP.NET Core Projektvorlagen verwendet. WebApplication verhält sich ähnlich wie der .NET Generic Host und macht viele der gleichen Schnittstellen verfügbar, erfordert jedoch weniger Rückrufe zum Konfigurieren. Die ASP.NET Core WebHost ist nur aus Gründen der Abwärtskompatibilität verfügbar.

Im folgenden Beispiel wird ein WebApplication instanziiert und einer Variablen mit dem Namen app zugewiesen:

var builder = WebApplication.CreateBuilder(args);

...

var app = builder.Build();

Die WebApplicationBuilder.Build Methode konfiguriert einen Host mit einer Reihe von Standardoptionen, z. B.:

Verwendung Kestrel als Webserver und Aktivieren der IIS-Integration.
Lädt Konfiguration aus App-Einstellungsdateien (z. B. appsettings.json), Umgebungsvariablen, Befehlszeilenargumenten und anderen Konfigurationsquellen.
Einrichten der Protokollierung und Leiten der Protokollausgabe an die Konsole und an Debug-Protokollierungsanbieter.

Es gibt zwei Hosts:

Der generische .NET-Host wird empfohlen. Der ASP.NET Core-Webhost ist nur für Abwärtskompatibilität verfügbar.

Die CreateDefaultBuilder Methoden und ConfigureWebHostDefaults Methoden im folgenden Beispiel konfigurieren einen Host mit einer Reihe von Standardoptionen, z. B.:

Verwendung Kestrel als Webserver und Aktivieren der IIS-Integration.
Lädt Konfiguration aus App-Einstellungsdateien (z. B. appsettings.json), Umgebungsvariablen, Befehlszeilenargumenten und anderen Konfigurationsquellen.
Einrichten der Protokollierung und Leiten der Protokollausgabe an die Konsole und an Debug-Protokollierungsanbieter.

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

Weitere Informationen finden Sie in den folgenden Ressourcen:

.NET Generischer Host in ASP.NET Core (empfohlen)
ASP.NET Core-Webhost (Aus Gründen der Abwärtskompatibilität)

Nicht-Webszenarien

Der generische Host ermöglicht es anderen Arten von Apps, frameworkübergreifende Erweiterungen zu verwenden, z. B. Protokollierung, Abhängigkeitseinfügung (DI), Konfiguration und Verwaltung der App-Lebensdauer. Weitere Informationen finden Sie unter Generischer .NET-Host in ASP.NET Core und Hintergrundtasks mit gehosteten Diensten in ASP.NET Core.

Servers

Eine ASP.NET Core-App verwendet eine HTTP-Serverimplementierung zum Lauschen auf HTTP-Anforderungen. Der Server sendet Anforderungen an die App in Form von mehreren Anforderungsfunktionen in einem HttpContext.

Weitere Informationen finden Sie unter Webserverimplementierungen in ASP.NET Core.

Windows

Die folgenden Serverimplementierungen werden von ASP.NET Core bereitgestellt:

Kestrel ist ein plattformübergreifender Webserver. Kestrel wird häufig in einer Reverseproxykonfiguration mit IIS ausgeführt. In ASP.NET Core 2.0 oder höher kann Kestrel als öffentlich zugänglicher Edgeserver ausgeführt werden, der direkt mit dem Internet verbunden ist.
Der IIS-HTTP-Server ist ein Server für Windows, der IIS verwendet. Mit diesem Server werden die ASP.NET Core-App und IIS im gleichen Prozess ausgeführt.
HTTP.sys ist ein Server für Windows, der nicht mit IIS verwendet wird.

macOS und Linux

ASP.NET Core bietet die plattformübergreifende Serverimplementierung von Kestrel. In ASP.NET Core 2.0 oder höher kann Kestrel als öffentlich zugänglicher Edgeserver ausgeführt werden, der direkt mit dem Internet verbunden ist. Kestrel wird häufig in einer Reverseproxykonfiguration mit Nginx oder Apache ausgeführt.

Configuration

ASP.NET Core stellt ein Konfigurationsframework bereit, das Einstellungen als Name-Wert-Paare aus einer sortierten Gruppe von Konfigurationsanbietern abruft. Integrierte Konfigurationsanbieter sind für eine Vielzahl von Quellen verfügbar, z. B. JSON-Dateien (.json), XML-Dateien (.xml), Umgebungsvariablen und Befehlszeilenargumente. Sie können benutzerdefinierte Konfigurationsanbieter erstellen, um andere Quellen zu unterstützen.

Standardmäßig sind ASP.NET Core Apps so konfiguriert, dass sie aus App-Einstellungsdateien (z. Bappsettings.json. ), Umgebungsvariablen und der Befehlszeile gelesen werden.

Wenn die App-Konfiguration geladen wird, überschreiben Werte aus Umgebungsvariablen Werte aus App-Einstellungsdateien. Die Options-API steht zum Lesen verwandter Konfigurationswerte zur Verfügung.

Zum Verwalten vertraulicher Konfigurationsdaten wie Kennwörter in der Development Umgebung stellt .NET den geheimen Manager bereit. Für geheime Produktionsgeheimnisse empfehlen wir die Verwendung von Azure Key Vault.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Logging

ASP.NET Core unterstützt eine Protokollierungs-API, die mit einer Vielzahl von Protokollierungsanbietern funktioniert:

Console
Debug
Ereignisablaufverfolgung unter Windows
Windows-Ereignisprotokoll
TraceSource
Azure App Service
Azure-Anwendung Insights
Drittanbieter

Um Protokolle zu erstellen, lösen Sie einen ILogger<TCategoryName>-Dienst aus der Abhängigkeitsinjektion (DI) auf und rufen Sie Protokollierungsmethoden auf, z. B. LogInformation. Ein Loggerobjekt und ein Konsolenanbieter für das Loggerobjekt werden automatisch im DI-Container gespeichert, wenn die WebApplication.CreateBuilder Methode aufgerufen wird.

Das folgende Beispiel zeigt, wie Sie eine Protokollierungsinstanz von DI abrufen und in einer Weather Komponente (Weather.razor) einer Blazor App verwenden, die Wetterdaten meldet:

@inject ILogger<Weather> Logger

...

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

        ...
    }
}

Weitere Informationen, einschließlich Routenanleitungen für Razor Pages und MVC-Apps, finden Sie unter Logging in .NET and ASP.NET Core und ASP.NET Core Blazor logging.

Routing

Routing in ASP.NET Core ist ein Mechanismus, der eingehende Anforderungen bestimmten Endpunkten in einer App zuordnet. Sie können URL-Muster definieren, die verschiedenen Komponenten entsprechen, z. B. Razor Komponenten, Razor Seiten, MVC-Controlleraktionen oder Middleware.

Die Methode UseRouting fügt der Anforderungspipeline Routingmiddleware hinzu. Diese Middleware verarbeitet die Routinginformationen und bestimmt den entsprechenden Endpunkt für jede Anforderung. In Anwendungen, die den Minimal Host verwenden, wird UseRouting im Entwicklerscode nicht explizit aufgerufen, es sei denn, Sie möchten die Reihenfolge der Middlewareverarbeitung ändern.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Fehler behandeln

ASP.NET Core verfügt über integrierte Funktionen zur Fehlerbehandlung wie beispielsweise:

eine Seite mit Ausnahmen für Entwickler
Benutzerdefinierte Fehlerseiten
statische Statuscodeseiten
Fehlerbehandlung während des Starts

Weitere Informationen finden Sie unter Behandeln von Fehlern in ASP.NET Core und Behandeln von Fehlern in ASP.NET Core Blazor Apps.

Übermitteln von HTTP-Anforderungen

Eine Implementierung von IHttpClientFactory ist verfügbar zum Erstellen von HttpClient-Instanzen. Die Factory:

Ein zentraler Ort für das Benennen und Konfigurieren logischer HttpClient-Instanzen wird damit geboten. Verwenden Sie beispielsweise einen Standardclient für die meisten Datenanforderungen der App mit einer Web-API und registrieren Sie einen anderen konfigurierten Client für den Zugriff auf GitHub.
Unterstützt die Registrierung und Verkettung von mehreren delegierenden Handlern, um eine Pipeline für die Middleware für ausgehende Anforderungen zu erstellen. Dieses Muster ähnelt der eingehenden Middlewarepipeline von ASP.NET Core. Das Muster bietet einen Mechanismus zum Verwalten von übergreifenden Belangen für HTTP-Anforderungen, einschließlich der Zwischenspeicherung, Fehlerbehandlung, Serialisierung und Protokollierung.
Integriert in Polly, eine beliebte Drittanbieterbibliothek für vorübergehende Fehlerbehandlung.
Das Pooling und die Lebensdauer von zugrunde liegenden HttpClientHandler-Instanzen werden verwaltet, um gängige DNS-Probleme zu vermeiden, die bei der manuellen Verwaltung der HttpClient-Lebensdauer auftreten.
Eine konfigurierbare Protokollierungsfunktion wird über ILogger für alle Anforderungen hinzugefügt, die über Clients gesendet werden, die von der Factory erstellt wurden.

Weitere Informationen finden Sie unter HTTP-Anforderungen mit IHttpClientFactory – ASP.NET Core und Aufrufen einer Web-API aus einer ASP.NET Core-AppBlazor.

Inhaltsstammverzeichnis

Der Inhaltsstamm ist der Basispfad für:

Die ausführbare Datei, die die App hosten (.exe).
Kompilierte Assemblys, aus denen die App besteht (.dll).
Inhaltsdateien, die von der App verwendet werden, wie z. B. Razor-Dateien (.cshtml, .razor), Konfigurationsdateien (.json, .xml) und Datendateien (.db).
Der Webstamm, der in der Regel der wwwroot Ordner ist.

Während der Entwicklung wird standardmäßig das Stammverzeichnis des Projekts als Inhaltsstamm verwendet. Dieses Verzeichnis ist auch der Basispfad sowohl für die Inhaltsdateien der App als auch für den Webstamm. Geben Sie einen anderen Inhaltsstamm an, indem Sie den Pfad beim Erstellen des Hosts festlegen.

Weitere Informationen finden Sie unter .NET Generic Host in ASP.NET Core und Serve Static Files in ASP.NET Core Apps.

Webstammverzeichnis

Der Webstamm ist der Basispfad für öffentliche, statische Ressourcendateien wie Stylesheets, JavaScript-Dateien und Bilder.

Standardmäßig werden statische Dateien nur aus dem Webstammverzeichnis und seinen Unterverzeichnissen bereitgestellt. Der Webstammpfad ist standardmäßig auf {CONTENT ROOT}/wwwroot festgelegt, wobei der Platzhalter {CONTENT ROOT} der Inhaltsstamm ist. Sie können einen anderen Webstamm festlegen, indem Sie den entsprechenden Pfad beim Erstellen des Hosts festlegen. Sie können auch das Veröffentlichen von Dateien in wwwroot mit dem <Content>Projektelement in der Projektdatei der App verhindern.

In Razor.cshtml-Dateien verweist ~/ auf den Webstamm. Ein Pfad, der beginnt, ~/ wird als virtueller Pfad bezeichnet.

Weitere Informationen finden Sie unter .NET Generic Host in ASP.NET Core und Serve Static Files in ASP.NET Core Apps.

Wie man ein Beispiel herunterlädt

Viele der Artikel und Lernprogramme enthalten Links zum Beispielcode.

Laden Sie die zip-Datei des ASP.NET Repositorys herunter.
Entzippen Sie die AspNetCore.Docs-main.zip Datei.
Um auf die Beispiel-App eines Artikels im entzippten Repository zuzugreifen, verwenden Sie die URL im Beispiellink des Artikels, um Sie beim Navigieren zum Ordner des Beispiels zu unterstützen. In der Regel wird oben im Artikel ein Beispiellink mit dem Linktext "Ansicht" oder "Beispielcode herunterladen" angezeigt.

Um eine einzelne Beispiel-App und nur den letzten Commit zu erhalten, verwenden Sie git sparse-checkout.

Im folgenden Beispiel für die Blazor Beispiele GitHub Repository gibt der git sparse-checkout set Befehl den Pfad zum Beispielordner an:

Ersetzen Sie den {VERSION FOLDER} Platzhalter durch den Versionsordner.
Ersetzen Sie den {SAMPLE FOLDER} Platzhalter durch den Beispielordner.

Navigieren Sie in einer Befehlsshell zu dem Ordner, in dem Sie das Beispiel klonen möchten. Führen Sie die folgenden Befehle in der Befehlsshell aus, die den Pfad des Versions-/Beispielordners an den git sparse-checkout set Befehl übergeben:

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}

Im folgenden PowerShell-Beispiel wird das 10.0-Beispiel Blazor Web App abgerufen und unter Verwendung des ~/documents-Pfads von PowerShell für den Befehl zum Wechseln des Verzeichnisses (cd) im Ordner „Dokumente“ des Benutzers abgelegt:

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

Präprozessordirektiven im Beispielcode

Um mehrere Szenarien zu veranschaulichen, verwenden Beispiel-Apps die #define Direktiven und #if-#else/#elif-#endif Präprozessoren, um verschiedene Abschnitte des Beispielcodes selektiv zu kompilieren und auszuführen. Legen Sie für diese Beispiele, die diesen Ansatz verwenden, die #define Direktive oben in den C#-Dateien fest, um das Dem Szenario zugeordnete Symbol zu definieren, das Sie ausführen möchten. Bei einigen Beispielen muss das Symbol oben in mehreren Dateien definiert werden, um ein Szenario auszuführen.

Die folgende #define Symbolliste gibt beispielsweise an, dass vier Szenarien verfügbar sind (ein Szenario pro Symbol). Die aktuelle Beispielkonfiguration führt das TemplateCode Szenario aus:

#define TemplateCode // or LogFromMain or ExpandDefault or FilterInCode

Um das Beispiel für die Ausführung des ExpandDefault Szenarios zu ändern, definieren Sie das ExpandDefault Symbol, und lassen Sie die verbleibenden Symbole auskommentiert:

#define ExpandDefault // TemplateCode or LogFromMain or FilterInCode

Weitere Informationen zur Verwendung von C#-Präprozessordirektiven zum selektiven Kompilieren von Codeabschnitten finden Sie unter #define (C#-Referenz) und #if (C#-Referenz).

Regionen im Beispielcode

Einige Beispiel-Apps enthalten Codeabschnitte, die von #region - und #endregion C#-Direktiven umgeben sind. Das Dokumentationsbuildsystem fügt diese Regionen in die gerenderten Dokumentationsthemen ein.

Regionsnamen enthalten in der Regel das Wort "Snippet". Das folgende Beispiel zeigt eine Region mit dem Namen snippet_WebHostDefaults.

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

Auf den vorherigen C#-Codeausschnitt wird in der Markdowndatei des Themas mit der folgenden Zeile verwiesen:

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

Sie können die Direktiven #region und #endregion, die den Code umgeben, sicher ignorieren oder entfernen. Ändern Sie den Code in diesen Direktiven nicht, wenn Sie die im Thema beschriebenen Beispielszenarien ausführen möchten.

Weitere Informationen finden Sie unter "Mitwirken zur ASP.NET Dokumentation: Codeausschnitte".

Dokumentobjektmodell (DOM)

Verweise auf das Dokumentobjektmodell in diesem Dokumentationssatz verwenden die Abkürzung DOM.

Weitere Informationen finden Sie unter Einführung in das DOM (MDN-Dokumentation) und Spezifikation des Document Object Model, Stufe 1 (W3C).

Byte-Vielfache

.NET-Bytegrößen verwenden metrische Präfixe für nicht dezimale Byte-Vielfache, die auf Potenzen von 1024 basieren.

Name (Abkürzung)	Größe	Example
Kilobyte (KB)	1.024 Bytes	1 KB = 1.024 Bytes
Megabyte (MB)	1.024² Bytes	1 MB = 1.048.576 Bytes
Gigabyte (GB)	1.024³ bytes	1 GB = 1.073.741.824 Bytes

Supportanfragen

Nur dokumentationsbezogene Probleme sind für das Repository dotnet/AspNetCore.Docs geeignet. Öffnen Sie für Produktsupport kein Problem in der Dokumentation. Suchen Sie Hilfe über einen oder mehrere der folgenden Supportkanäle:

Bei einem potenziellen Fehler im Framework oder für Produktfeedback können Sie ein Ticket für die ASP.NET Core-Produktgruppe unter dotnet/aspnetcore-Issues öffnen. Fehlerberichte erfordern in der Regel Folgendes:

Eine klare Erläuterung des Problems: Folgen Sie den Anweisungen in der GitHub-Problemvorlage, die vom Produktteam beim Erstellen des Problems bereitgestellt wird.
Minimales Repro-Projekt: Platzieren Sie ein Projekt auf GitHub für die Produkteinheitstechniker, um es herunterzuladen und auszuführen. Verknüpfen Sie das Projekt mit dem Eröffnungskommentar des Issues.

Wenn es ein mögliches Problem mit einem Artikel gibt, öffnen Sie ein Issue zur Dokumentation. Um ein Dokumentationsproblem zu melden, verwenden Sie den Link Dokumentationsproblem öffnen unten im Artikel. Die Metadaten, die Sie zu Ihrem Problem hinzufügen, liefern Daten zur Nachverfolgung und benachrichtigen automatisch den Autor bzw. die Autorin des Artikels. Wenn das Thema vor der Eröffnung des Dokumentationsproblems mit der Produkteinheit besprochen wurde, fügen Sie im Eröffnungskommentar des Dokumentationsproblems einen Querverweis auf das technische Problem ein.

GitHub-Issues für die Blazor-Dokumentation werden automatisch für die Selektierung im Blazor.Docs-Projekt (dotnet/AspNetCore.Docs GitHub-Repository) markiert. Sie müssen mit einer kurzen Wartezeit rechnen, insbesondere an Wochenenden und Feiertagen. Normalerweise antworten Dokumentationsautoren an Wochentagen binnen 24 Stunden.

Wenn Sie Probleme oder Feedback zu Visual Studio haben, verwenden Sie die Gesten Problem melden oder Feature vorschlagen in Visual Studio, über die Sie interne Probleme für Visual Studio öffnen können. Weitere Informationen finden Sie unter Visual Studio Feedback.

Wenn Sie Probleme mit Visual Studio Code haben, bitten Sie in den Supportforen der Community um Unterstützung. Öffnen Sie für Fehlerberichte und Produktfeedback ein Problem im microsoft/vscode GitHub Repo.

Weitere Ressourcen

Feedback

War diese Seite hilfreich?

Last updated on 2026-09-05

Übersicht über Grundlagen von ASP.NET Core

Die Program-Datei.

Die Startup-Klasse

Abhängigkeitsinjektion (Dienste)

Environments

Middleware

Host

Nicht-Webszenarien

Servers

Windows

macOS und Linux

Configuration

Logging

Routing

Fehler behandeln

Übermitteln von HTTP-Anforderungen

Inhaltsstammverzeichnis

Webstammverzeichnis

Wie man ein Beispiel herunterlädt

Präprozessordirektiven im Beispielcode

Regionen im Beispielcode

Dokumentobjektmodell (DOM)

Byte-Vielfache

Supportanfragen

Weitere Ressourcen

Feedback

Zusätzliche Ressourcen

Die `Program`-Datei.

Die `Startup`-Klasse