Dela via


översikt över grunderna i ASP.NET Core

Note

Det här är inte den senaste versionen av den här artikeln. För den aktuella utgåvan, se .NET 9-versionen av den här artikeln.

Warning

Den här versionen av ASP.NET Core stöds inte längre. Mer information finns i .NET och .NET Core Support Policy. För den aktuella utgåvan, se .NET 9-versionen av den här artikeln.

Important

Den här informationen gäller en förhandsversionsprodukt som kan ändras avsevärt innan den släpps kommersiellt. Microsoft lämnar inga garantier, uttryckliga eller underförstådda, med avseende på den information som tillhandahålls här.

För den aktuella utgåvan, se .NET 9-versionen av den här artikeln.

Den här artikeln innehåller en översikt över grunderna för att skapa ASP.NET Core-appar, inklusive beroendeinmatning (DI), konfiguration, mellanprogram med mera.

Vägledning för Blazor-grunder, som kompletterar eller ersätter vägledningen i den här artikeln, finns i ASP.NET Core-grunder Blazor.

Program.cs

ASP.NET Core-appar som skapats med webbmallarna innehåller programmets startkod i filen Program.cs. Filen Program.cs är där.

  • Tjänster som krävs av appen konfigureras.
  • Appens pipeline för hantering av begäranden definieras som en serie mellanprogramkomponenter.

Följande appstartkod stöder flera apptyper:

using WebAll.Components;

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

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

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

app.UseAuthorization();

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

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

app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode();

app.UseAntiforgery();

app.Run();

Beroendeinmatning (tjänster)

ASP.NET Core har inbyggd beroendeinjektion (DI) som gör konfigurerade tjänster tillgängliga överallt i en app. Tjänster läggs till i DI-containern med WebApplicationBuilder.Services, builder.Services i föregående kod. När WebApplicationBuilder instansieras läggs många ramverkstjänster till automatiskt. builder är en WebApplicationBuilder i följande kod:

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

I föregående kod lägger CreateBuilder till konfiguration, loggning och många andra tjänster till DI-containern. DI-ramverket tillhandahåller en instans av en begärd tjänst vid körningstid.

Följande kod lägger till en anpassad DbContext- och Blazor-komponenter i DI-containern:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContextFactory<BlazorWebAppMoviesContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("MoviesContext") 
        ?? throw new InvalidOperationException("Connection string not found.")));

builder.Services.AddQuickGridEntityFrameworkAdapter();

builder.Services.AddDatabaseDeveloperPageExceptionFilter();

// Add services to the container.
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents();

var app = builder.Build();

Under Blazor Web Apps löses tjänster ofta med DI vid körning genom att använda direktivet @inject i en Razor-komponent, som visas i följande exempel.

@page "/movies"
@rendermode InteractiveServer
@using Microsoft.EntityFrameworkCore
@using Microsoft.AspNetCore.Components.QuickGrid
@using BlazorWebAppMovies.Models
@using BlazorWebAppMovies.Data
@implements IAsyncDisposable
@inject IDbContextFactory<BlazorWebAppMovies.Data.BlazorWebAppMoviesContext> DbFactory

<PageTitle>Index</PageTitle>

<h1>Index</h1>

<div>
    <input type="search" @bind="titleFilter" @bind:event="oninput" />
</div>

<p>
    <a href="movies/create">Create New</a>
</p>

<QuickGrid Class="table" Items="FilteredMovies" Pagination="pagination">
    <PropertyColumn Property="movie => movie.Title" Sortable="true" />
    <PropertyColumn Property="movie => movie.ReleaseDate" Title="Release Date" />
    <PropertyColumn Property="movie => movie.Genre" />
    <PropertyColumn Property="movie => movie.Price" />
    <PropertyColumn Property="movie => movie.Rating" />

    <TemplateColumn Context="movie">
        <a href="@($"movies/edit?id={movie.Id}")">Edit</a> |
        <a href="@($"movies/details?id={movie.Id}")">Details</a> |
        <a href="@($"movies/delete?id={movie.Id}")">Delete</a>
    </TemplateColumn>
</QuickGrid>

<Paginator State="pagination" />

@code {
    private BlazorWebAppMoviesContext context = default!;
    private PaginationState pagination = new PaginationState { ItemsPerPage = 10 };
    private string titleFilter = string.Empty;

    private IQueryable<Movie> FilteredMovies =>
        context.Movie.Where(m => m.Title!.Contains(titleFilter));

    protected override void OnInitialized()
    {
        context = DbFactory.CreateDbContext();
    }

    public async ValueTask DisposeAsync() => await context.DisposeAsync();
}

I föregående kod:

  • Direktivet @inject används.
  • Tjänsten löses i OnInitialized-metoden och tilldelas till variabeln context.
  • context-tjänsten skapar FilteredMovie-listan.

Ett annat sätt att lösa en tjänst från DI är att använda konstruktorinmatning. Följande Razor Pages-kod använder konstruktorinmatning för att lösa databaskontexten och en loggare från DI:

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

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

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

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

I föregående kod tar konstruktorn IndexModel en parameter av typen RazorPagesMovieContext, som löses vid körning till variabeln _context. Kontextobjektet används för att skapa en lista över filmer i metoden OnGetAsync.

Mer information finns i ASP.NET Core Blazor beroendeinmatning och Beroendeinmatning i ASP.NET Core.

Middleware

Pipelinen för hantering av begäranden består av en serie mellanprogramskomponenter. Varje komponent utför åtgärder på en HttpContext och anropar antingen nästa mellanprogram i pipelinen eller avslutar begäran.

Enligt konventionen läggs en mellanprogramskomponent till i pipelinen genom att en Use{Feature} tilläggsmetod anropas. Användningen av metoder med namnet Use{Feature} för att lägga till mellanprogram i en app visas i följande kod:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContextFactory<BlazorWebAppMoviesContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("MoviesContext") 
        ?? throw new InvalidOperationException("Connection string not found.")));

builder.Services.AddQuickGridEntityFrameworkAdapter();

builder.Services.AddDatabaseDeveloperPageExceptionFilter();

// Add services to the container.
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents();

var app = builder.Build();

using (var scope = app.Services.CreateScope())
{
    var services = scope.ServiceProvider;

    SeedData.Initialize(services);
}

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error", createScopeForErrors: true);
    app.UseHsts();
    app.UseMigrationsEndPoint();
}
app.UseHttpsRedirection();

app.UseAntiforgery();

app.MapStaticAssets();
app.MapRazorComponents<App>()
    .AddInteractiveServerRenderMode();

app.Run();

Mer information finns i ASP.NET Core Middleware.

Host

När en ASP.NET Core-app startar bygger den en värd. Värden kapslar in alla appens resurser, till exempel:

  • En HTTP-serverimplementering
  • Mellanprogramskomponenter
  • Logging
  • Tjänster för beroendeinjektion
  • Configuration

Det finns tre olika värdar som kan köra en ASP.NET Core-app:

Typerna ASP.NET Core WebApplication och WebApplicationBuilder rekommenderas och används i alla ASP.NET Core-mallar. WebApplication fungerar på samma sätt som generiska .NET-värden och exponerar många av gränssnitten, men kräver färre återanrop för att konfigurera. ASP.NET Core WebHost är endast tillgänglig för bakåtkompatibilitet.

Följande exempel instansierar en WebApplication och tilldelar den till en variabel med namnet app:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddDbContextFactory<BlazorWebAppMoviesContext>(options =>
    options.UseSqlServer(builder.Configuration.GetConnectionString("MoviesContext") 
        ?? throw new InvalidOperationException("Connection string not found.")));

builder.Services.AddQuickGridEntityFrameworkAdapter();

builder.Services.AddDatabaseDeveloperPageExceptionFilter();

// Add services to the container.
builder.Services.AddRazorComponents()
    .AddInteractiveServerComponents();

var app = builder.Build();

Metoden WebApplicationBuilder.Build konfigurerar en värd med en uppsättning standardalternativ, till exempel:

  • Använd Kestrel som webbserver och aktivera IIS-integrering.
  • Läs in konfiguration från appsettings.json, miljövariabler, kommandoradsargument och andra konfigurationskällor.
  • Skicka loggutdata till konsolen och debuggproviders.

Scenarier som inte är webb

Med den generiska värden kan andra typer av appar använda övergripande ramverkstillägg, till exempel loggning, beroendeinmatning (DI), konfiguration och hantering av appens livslängd. För mer information, se .NET Generisk Värd i ASP.NET Core och Backgrundsuppgifter med värdtjänster i ASP.NET Core.

Servers

En ASP.NET Core-app använder en HTTP-serverimplementering för att lyssna efter HTTP-begäranden. Servern visar begäranden till appen som en uppsättning begärandefunktioner sammansatta i en HttpContext.

ASP.NET Core tillhandahåller följande serverimplementeringar:

  • Kestrel är en plattformsoberoende webbserver. Kestrel körs ofta i en omvänd proxykonfiguration med hjälp av IIS-. I ASP.NET Core 2.0 eller senare kan Kestrel köras som en offentlig edge-server som exponeras direkt mot Internet.
  • IIS HTTP Server är en server för Windows som använder IIS. Med den här servern körs ASP.NET Core-appen och IIS i samma process.
  • HTTP.sys är en server för Windows som inte används med IIS.

Mer information finns i webbserverimplementeringar i ASP.NET Core.

Configuration

ASP.NET Core tillhandahåller ett konfigurationsramverk som hämtar inställningar som namn/värde-par från en ordnad uppsättning konfigurationsproviders. Inbyggda konfigurationsprovidrar är tillgängliga för en mängd olika källor, till exempel .json filer, .xml filer, miljövariabler och kommandoradsargument. Skriv anpassade konfigurationsprovidrar för att stödja andra källor.

Som standardär ASP.NET Core-appar konfigurerade för att läsa från appsettings.json, miljövariabler, kommandoraden med mera. När appens konfiguration läses in åsidosätter värden från miljövariabler värden från appsettings.json.

För att hantera konfidentiella konfigurationsdata, till exempel lösenord i utvecklingsmiljön, tillhandahåller .NET Secret Manager. För produktionshemligheter rekommenderar vi Azure Key Vault-.

Mer information finns i Configuration i ASP.NET Core.

Environments

Exekveringsmiljöer, till exempel Development, Stagingoch Production, är tillgängliga i ASP.NET Core. Ange den miljö som en app körs i genom att ange ASPNETCORE_ENVIRONMENT miljövariabeln. ASP.NET Core läser miljövariabeln vid appstart och lagrar värdet i en IWebHostEnvironment implementering. Den här implementeringen är tillgänglig var som helst i en app via beroendeinmatning (DI).

I följande exempel konfigureras undantagshanteraren och HTTP Strict Transport Security Protocol (HSTS) mellanprogram när inte körs i Development miljö:

if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error", createScopeForErrors: true);
    app.UseHsts();
    app.UseMigrationsEndPoint();
}

Mer information finns i ASP.NET Core-körningsmiljöer.

Logging

ASP.NET Core stöder ett loggnings-API som fungerar med en mängd olika inbyggda och tredje parts loggningsproviders. Tillgängliga leverantörer är:

  • Console
  • Debug
  • Händelsespårning i Windows
  • Windows-händelselogg
  • TraceSource
  • Azure App Service
  • Azure Application Insights

Om du vill skapa loggar löser du en ILogger<TCategoryName>-tjänst från beroendeinmatning (DI) och anropar loggningsmetoder som LogInformation. I följande exempel visas hur du hämtar och använder en loggare i en .razor fil för en sida i en Blazor Web App. Ett loggningsobjekt och en konsolprovider för det lagras automatiskt i DI-containern när CreateBuilder-metoden anropas i Program.cs.

@page "/weather"
@attribute [StreamRendering]
@inject ILogger<Weather> Logger

<PageTitle>Weather</PageTitle>

<h1>Weather</h1>

<p>This component demonstrates showing data and logging.</p>

@if (forecasts == null)
{
    <p><em>Loading...</em></p>
}
else
{
    <table class="table">
        <thead>
            <tr>
                <th>Date</th>
                <th aria-label="Temperature in Celsius">Temp. (C)</th>
                <th aria-label="Temperature in Fahrenheit">Temp. (F)</th>
                <th>Summary</th>
            </tr>
        </thead>
        <tbody>
            @foreach (var forecast in forecasts)
            {
                <tr>
                    <td>@forecast.Date.ToShortDateString()</td>
                    <td>@forecast.TemperatureC</td>
                    <td>@forecast.TemperatureF</td>
                    <td>@forecast.Summary</td>
                </tr>
            }
        </tbody>
    </table>
}

@code {
    private WeatherForecast[]? forecasts;

    protected override async Task OnInitializedAsync()
    {
        // Simulate asynchronous loading to demonstrate streaming rendering
       
        await Task.Delay(500);

        Logger.LogInformation("This is an information log message.");
        Logger.LogWarning("This is a warning log message.");
        Logger.LogError("This is an error log message.");

        var startDate = DateOnly.FromDateTime(DateTime.Now);
        var summaries = new[] { "Freezing", "Bracing", "Chilly",
            "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching" };
        forecasts = Enumerable.Range(1, 5).Select(index => new WeatherForecast
        {
            Date = startDate.AddDays(index),
            TemperatureC = Random.Shared.Next(-20, 55),
            Summary = summaries[Random.Shared.Next(summaries.Length)]
        }).ToArray();
    }

    private class WeatherForecast
    {
        public DateOnly Date { get; set; }
        public int TemperatureC { get; set; }
        public string? Summary { get; set; }
        public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
    }
}

Mer information finns i Loggning i .NET och ASP.NET Core.

Routing

Routning i ASP.NET Core är en mekanism som mappar inkommande begäranden till specifika slutpunkter i ett program. Det gör att du kan definiera URL-mönster som motsvarar olika komponenter, till exempel Blazor komponenter, Razor sidor, MVC-kontrollantåtgärder eller mellanprogram.

Metoden UseRouting(IApplicationBuilder) lägger till mellanprogram för routning i begärandepipelinen. Det här mellanprogrammet bearbetar routningsinformationen och avgör lämplig slutpunkt för varje begäran. Du behöver inte uttryckligen anropa UseRouting om du inte vill ändra i vilken ordning mellanprogrammet bearbetas.

För mer information, se Routing i ASP.NET Core och ASP.NET Core Blazor routing och navigering.

Felhantering

ASP.NET Core har inbyggda funktioner för att hantera fel, till exempel:

  • En undantagssida för utvecklare
  • Anpassade felsidor
  • Statiska statuskodsidor
  • Undantagshantering vid start

Mer information finns i Hantera fel i ASP.NET Core.

Att göra HTTP-förfrågningar

En implementering av IHttpClientFactory är tillgänglig för att skapa HttpClient instanser. Fabriken:

  • Tillhandahåller en central plats för att namnge och konfigurera logiska HttpClient instanser. Du kan till exempel registrera och konfigurera en github--klient för åtkomst till GitHub. Registrera och konfigurera en standardklient för andra ändamål.
  • Stöder registrering och länkning av flera delegerande hanterare för att skapa en pipeline för mellanprogram för utgående begäran. Det här mönstret liknar ASP.NET Cores inkommande mellanprogramspipeline. Mönstret ger en mekanism för att hantera övergripande problem för HTTP-begäranden, inklusive cachelagring, felhantering, serialisering och loggning.
  • Integrerar med Polly, ett populärt bibliotek från tredje part för tillfällig felhantering.
  • Hanterar pooler och livslängden för underliggande HttpClientHandler instanser för att undvika vanliga DNS-problem som uppstår vid hantering av HttpClient livslängd manuellt.
  • Lägger till en konfigurerbar loggningsupplevelse via ILogger för alla begäranden som skickas via klienter som skapats av fabriken.

Mer information finns i Gör HTTP-begäranden med IHttpClientFactory i ASP.NET Core.

Innehållsrot

Innehållsroten är bassökvägen för:

  • Det körbara programmet som kör appen (.exe).
  • Kompilerade sammansättningar som utgör appen (.dll).
  • Innehållsfiler som används av appen, till exempel:
    • Razor filer (.cshtml, .razor)
    • Konfigurationsfiler (.json, .xml)
    • Datafiler (.db)
  • Webbrotenwwwroot, vanligtvis mappen.

Under utvecklingen är innehållsroten som standard i projektets rotkatalog. Den här katalogen är också bassökvägen för både appens innehållsfiler och webbroten. Ange en annan innehållsrot genom att ange sökvägen när att skapa värden. Mer information finns i Innehållsrot.

Webbrot

Webbroten är bassökvägen för offentliga, statiska resursfiler, till exempel:

  • Formatmallar (.css)
  • JavaScript (.js)
  • Bilder (.png, .jpg)

Som standard hanteras statiska filer endast från webbrotkatalogen och dess underkataloger. Webbrotsökvägen är som standard {CONTENT ROOT}/wwwroot, där platshållaren {CONTENT ROOT} är innehållsroten. Ange en annan webbroten genom att ange dess sökväg när du bygger värden . Mer information finns i Web Root.

Förhindra publicering av filer i wwwroot med projektobjektet i projektfilen.<Content> I följande exempel förhindras publicering av innehåll i wwwroot/local och dess underkataloger:

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

I filer märkta Razor.cshtml pekar ~/ på webbrooten. En sökväg som börjar med ~/ kallas för en virtuell sökväg.

För mer information, se statiska filer i ASP.NET Core.

Så här laddar du ned ett exempel

Många av artiklarna och självstudierna innehåller länkar till exempelkod.

  1. Ladda ner ASP.NET-kodförrådets zip-fil.
  2. Packa upp AspNetCore.Docs-main.zip-filen.
  3. Om du vill komma åt en artikels exempelapp på den uppackade lagringsplatsen använder du URL:en i artikelns exempellänk för att navigera till exempelmappen. Vanligtvis visas en artikels exempellänk överst i artikeln med länktexten Visa eller ladda ned exempelkod.

Förprocessordirektiv i exempelkod

För att demonstrera flera scenarier använder exempelappar direktiven #define och #if-#else/#elif-#endif förprocessor för att selektivt kompilera och köra olika delar av exempelkoden. För de exempel som använder den här metoden anger du #define-direktivet överst i C#-filerna för att definiera symbolen som är associerad med det scenario som du vill köra. Vissa exempel kräver att du definierar symbolen överst i flera filer för att kunna köra ett scenario.

Följande #define symbollista anger till exempel att fyra scenarier är tillgängliga (ett scenario per symbol). Aktuell exempelkonfiguration kör scenariot TemplateCode:

#define TemplateCode // or LogFromMain or ExpandDefault or FilterInCode

Om du vill ändra exemplet för att köra ExpandDefault scenariot definierar du ExpandDefault-symbolen och lämnar de återstående symbolerna utkommenterade:

#define ExpandDefault // TemplateCode or LogFromMain or FilterInCode

Mer information om hur du använder C#-förprocessordirektiv för att selektivt kompilera kodavsnitt finns i #define (C#-referens) och #if (C#-referens).

Regioner i exempelkod

Vissa exempelappar innehåller kodavsnitt omgivna av #region - och #endregion C#-direktiv. Dokumentationens byggsystem matar in dessa regioner i de renderade dokumentationsämnena.

Regionnamn innehåller vanligtvis ordet "kodfragment". I följande exempel visas en region med namnet snippet_WebHostDefaults:

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

Det föregående C#-kodfragmentet refereras till i ämnets markdown-fil med följande rad:

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

Du kan ignorera eller ta bort direktiven #region och #endregion som omger koden på ett säkert sätt. Ändra inte koden i dessa direktiv om du planerar att köra de exempelscenarier som beskrivs i ämnet.

Mer information finns i Bidra till ASP.NET dokumentation: Kodfragment.

Ytterligare resurser

grunderna i ASP.NET Core Blazor

Den här artikeln innehåller en översikt över grunderna för att skapa ASP.NET Core-appar, inklusive beroendeinmatning (DI), konfiguration, mellanprogram med mera.

Program.cs

ASP.NET Core-appar som skapats med webbmallarna innehåller programmets startkod i filen Program.cs. Filen Program.cs är där.

  • Tjänster som krävs av appen konfigureras.
  • Appens pipeline för hantering av begäranden definieras som en serie mellanprogramkomponenter.

Följande appstartkod stöder:

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

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

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

app.UseAuthorization();

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

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

app.Run();

Beroendeinmatning (tjänster)

ASP.NET Core innehåller beroendeinjektion (DI) som gör konfigurerade tjänster tillgängliga genom en app. Tjänster läggs till i DI-containern med WebApplicationBuilder.Services, builder.Services i föregående kod. När WebApplicationBuilder instansieras läggs många ramverkstjänster till. builder är en WebApplicationBuilder i följande kod:

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

I den markerade koden ovan har builder konfiguration, loggning och många andra tjänster lagts till i DI-containern.

Följande kod lägger till Razor Pages, MVC-styrenheter med vyer och en anpassad DbContext till DI-containern:

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

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

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

var app = builder.Build();

Tjänster löses vanligtvis från DI med konstruktorinmatning. DI-ramverket tillhandahåller en instans av den här tjänsten under körning.

I följande kod används konstruktorinmatning för att lösa databaskontexten och loggaren från DI:

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

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

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

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

Middleware

Pipelinen för hantering av begäranden består av en serie mellanprogramskomponenter. Varje komponent utför åtgärder på en HttpContext och anropar antingen nästa mellanprogram i pipelinen eller avslutar begäran.

Enligt konventionen läggs en mellanprogramskomponent till i pipelinen genom att en Use{Feature} tilläggsmetod anropas. Mellanprogram som läggs till i appen är markerat i följande kod:

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

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

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

app.UseAuthorization();

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

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

app.Run();

Mer information finns i ASP.NET Core Middleware.

Host

När en ASP.NET Core-app startar bygger den en värd. Värden kapslar in alla appens resurser, till exempel:

  • En HTTP-serverimplementering
  • Mellanprogramskomponenter
  • Logging
  • Tjänster för beroendeinjektion
  • Configuration

Det finns tre olika värdar som kan köra en ASP.NET Core-app:

Typerna ASP.NET Core WebApplication och WebApplicationBuilder rekommenderas och används i alla ASP.NET Core-mallar. WebApplication fungerar på samma sätt som .NET Generic Hosten och exponerar många av samma gränssnitt, men kräver färre callback-funktioner för att konfigurera. ASP.NET Core WebHost är endast tillgänglig för bakåtkompatibilitet.

I följande exempel instansieras en WebApplication:

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

Metoden WebApplicationBuilder.Build konfigurerar en värd med en uppsättning standardalternativ, till exempel:

  • Använd Kestrel som webbserver och aktivera IIS-integrering.
  • Läs in konfiguration från appsettings.json, miljövariabler, kommandoradsargument och andra konfigurationskällor.
  • Skicka loggutdata till konsolen och debuggproviders.

Scenarier som inte är webb

Med den generiska värden kan andra typer av appar använda övergripande ramverkstillägg, till exempel loggning, beroendeinmatning (DI), konfiguration och hantering av appens livslängd. För mer information, se .NET Generisk Värd i ASP.NET Core och Backgrundsuppgifter med värdtjänster i ASP.NET Core.

Servers

En ASP.NET Core-app använder en HTTP-serverimplementering för att lyssna efter HTTP-begäranden. Servern visar begäranden till appen som en uppsättning begärandefunktioner sammansatta i en HttpContext.

ASP.NET Core tillhandahåller följande serverimplementeringar:

  • Kestrel är en plattformsoberoende webbserver. Kestrel körs ofta i en omvänd proxykonfiguration med hjälp av IIS-. I ASP.NET Core 2.0 eller senare kan Kestrel köras som en offentlig edge-server som exponeras direkt mot Internet.
  • IIS HTTP Server är en server för Windows som använder IIS. Med den här servern körs ASP.NET Core-appen och IIS i samma process.
  • HTTP.sys är en server för Windows som inte används med IIS.

Mer information finns i webbserverimplementeringar i ASP.NET Core.

Configuration

ASP.NET Core tillhandahåller ett konfigurationsramverk som hämtar inställningar som namn/värde-par från en ordnad uppsättning konfigurationsproviders. Inbyggda konfigurationsprovidrar är tillgängliga för en mängd olika källor, till exempel .json filer, .xml filer, miljövariabler och kommandoradsargument. Skriv anpassade konfigurationsprovidrar för att stödja andra källor.

Som standardär ASP.NET Core-appar konfigurerade för att läsa från appsettings.json, miljövariabler, kommandoraden med mera. När appens konfiguration läses in åsidosätter värden från miljövariabler värden från appsettings.json.

För att hantera konfidentiella konfigurationsdata, till exempel lösenord, tillhandahåller .NET Secret Manager. För produktionshemligheter rekommenderar vi Azure Key Vault-.

Mer information finns i Configuration i ASP.NET Core.

Environments

Exekveringsmiljöer, till exempel Development, Stagingoch Production, är tillgängliga i ASP.NET Core. Ange den miljö som en app körs i genom att ange ASPNETCORE_ENVIRONMENT miljövariabeln. ASP.NET Core läser miljövariabeln vid appstart och lagrar värdet i en IWebHostEnvironment implementering. Den här implementeringen är tillgänglig var som helst i en app via beroendeinmatning (DI).

I följande exempel konfigureras undantagshanteraren och HTTP Strict Transport Security Protocol (HSTS) mellanprogram när inte körs i Development miljö:

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

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

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

app.UseAuthorization();

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

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

app.Run();

Mer information finns i ASP.NET Core-körningsmiljöer.

Logging

ASP.NET Core stöder ett loggnings-API som fungerar med en mängd olika inbyggda och tredje parts loggningsproviders. Tillgängliga leverantörer är:

  • Console
  • Debug
  • Händelsespårning i Windows
  • Windows-händelselogg
  • TraceSource
  • Azure App Service
  • Azure Application Insights

Om du vill skapa loggar löser du en ILogger<TCategoryName>-tjänst från beroendeinmatning (DI) och anropar loggningsmetoder som LogInformation. Till exempel:

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

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

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

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

Mer information finns i Loggning i .NET och ASP.NET Core.

Routing

En rutt är en URL-mall som mappas till en hanterare. Hanteraren är vanligtvis en Razor sida, en åtgärdsmetod i en MVC-styrenhet eller ett mellanprogram. ASP.NET Core-routning ger dig kontroll över de URL:er som används av din app.

Följande kod, som genereras av webbprogrammallen ASP.NET Core, anropar UseRouting:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Mer information finns i Routning i ASP.NET Core.

Felhantering

ASP.NET Core har inbyggda funktioner för att hantera fel, till exempel:

  • En undantagssida för utvecklare
  • Anpassade felsidor
  • Statiska statuskodsidor
  • Undantagshantering vid start

Mer information finns i Hantera fel i ASP.NET Core.

Att göra HTTP-förfrågningar

En implementering av IHttpClientFactory är tillgänglig för att skapa HttpClient instanser. Fabriken:

  • Tillhandahåller en central plats för att namnge och konfigurera logiska HttpClient instanser. Du kan till exempel registrera och konfigurera en github--klient för åtkomst till GitHub. Registrera och konfigurera en standardklient för andra ändamål.
  • Stöder registrering och länkning av flera delegerande hanterare för att skapa en pipeline för mellanprogram för utgående begäran. Det här mönstret liknar ASP.NET Cores inkommande mellanprogramspipeline. Mönstret ger en mekanism för att hantera övergripande problem för HTTP-begäranden, inklusive cachelagring, felhantering, serialisering och loggning.
  • Integrerar med Polly, ett populärt bibliotek från tredje part för tillfällig felhantering.
  • Hanterar pooler och livslängden för underliggande HttpClientHandler instanser för att undvika vanliga DNS-problem som uppstår vid hantering av HttpClient livslängd manuellt.
  • Lägger till en konfigurerbar loggningsupplevelse via ILogger för alla begäranden som skickas via klienter som skapats av fabriken.

Mer information finns i Gör HTTP-begäranden med IHttpClientFactory i ASP.NET Core.

Innehållsrot

Innehållsroten är bassökvägen för:

  • Det körbara programmet som kör appen (.exe).
  • Kompilerade sammansättningar som utgör appen (.dll).
  • Innehållsfiler som används av appen, till exempel:
    • Razor filer (.cshtml, .razor)
    • Konfigurationsfiler (.json, .xml)
    • Datafiler (.db)
  • Den webbroten, vanligtvis mappen wwwroot.

Under utvecklingen är innehållsroten som standard i projektets rotkatalog. Den här katalogen är också bassökvägen för både appens innehållsfiler och webbroten. Ange en annan innehållsrot genom att ange sökvägen när att skapa värden. Mer information finns i Innehållsrot.

Webbrot

Webbroten är bassökvägen för offentliga, statiska resursfiler, till exempel:

  • Formatmallar (.css)
  • JavaScript (.js)
  • Bilder (.png, .jpg)

Som standard hanteras statiska filer endast från webbrotkatalogen och dess underkataloger. Webbrotsökvägen är som standard {content root}/wwwroot. Ange en annan webbroten genom att ange dess sökväg när du bygger värden . Mer information finns i Web Root.

Förhindra publicering av filer i wwwroot- med projektobjektet <Innehåll> i projektfilen. I följande exempel förhindras publicering av innehåll i wwwroot/lokal och dess underkataloger:

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

I filer märkta Razor.cshtml pekar ~/ på webbrooten. En sökväg som börjar med ~/ kallas för en virtuell sökväg.

För mer information, se statiska filer i ASP.NET Core.

Den här artikeln innehåller en översikt över grunderna för att skapa ASP.NET Core-appar, inklusive beroendeinmatning (DI), konfiguration, mellanprogram med mera.

Startklassen

Klassen Startup är där:

  • Tjänster som krävs av appen konfigureras.
  • Appens pipeline för hantering av begäranden definieras som en serie mellanprogramkomponenter.

Här är ett exempel på en Startup-klass:

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

För mer information, se start av app i ASP.NET Core.

Beroendeinmatning (tjänster)

ASP.NET Core innehåller ett inbyggt di-ramverk (dependency injection) som gör konfigurerade tjänster tillgängliga i en app. En loggningskomponent är till exempel en tjänst.

Kod för att konfigurera (eller registrera) tjänster läggs till i metoden Startup.ConfigureServices. Till exempel:

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

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

Tjänster löses vanligtvis från DI med konstruktorinmatning. Med konstruktorinmatning deklarerar en klass en konstruktorparameter av antingen den typ som krävs eller ett gränssnitt. DI-ramverket tillhandahåller en instans av den här tjänsten under körning.

I följande exempel används konstruktorinmatning för att lösa en RazorPagesMovieContext från DI:

public class IndexModel : PageModel
{
    private readonly RazorPagesMovieContext _context;

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

    // ...

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

Om den inbyggda IoC-containern (Inversion of Control) inte uppfyller alla appbehov kan en IoC-container från tredje part användas i stället.

Mer information finns i Beroendeinmatning i ASP.NET Core.

Middleware

Pipelinen för hantering av begäranden består av en serie mellanprogramskomponenter. Varje komponent utför åtgärder på en HttpContext och anropar antingen nästa mellanprogram i pipelinen eller avslutar begäran.

Enligt konventionen läggs en mellanprogramskomponent till i pipelinen genom att en Use... tilläggsmetod anropas i metoden Startup.Configure. Om du till exempel vill aktivera återgivning av statiska filer anropar du UseStaticFiles.

I följande exempel konfigureras en pipeline för hantering av begäranden:

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

    app.UseRouting();

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

ASP.NET Core innehåller en omfattande uppsättning inbyggda mellanprogram. Anpassade mellanprogramskomponenter kan också skrivas.

Mer information finns i ASP.NET Core Middleware.

Host

När en ASP.NET Core-app startar bygger den en värd. Värden kapslar in alla appens resurser, till exempel:

  • En HTTP-serverimplementering
  • Mellanprogramskomponenter
  • Logging
  • Tjänster för beroendeinjektion
  • Configuration

Det finns två olika värdar:

  • Generisk .NET-värd
  • ASP.NET Core webbvärd

Den generiska .NET-värden rekommenderas. ASP.NET Core Web Host är endast tillgänglig för bakåtkompatibilitet.

I följande exempel skapas en generisk .NET-värd:

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

Metoderna CreateDefaultBuilder och ConfigureWebHostDefaults konfigurerar en värd med en uppsättning standardalternativ, till exempel:

  • Använd Kestrel som webbserver och aktivera IIS-integrering.
  • Läs in konfiguration från appsettings.json, appsettings.{Environment}.json, miljövariabler, kommandoradsargument och andra konfigurationskällor.
  • Skicka loggutdata till konsolen och debuggproviders.

Mer information finns i .NET Generic Host i ASP.NET Core.

Scenarier som inte är webb

Med den generiska värden kan andra typer av appar använda övergripande ramverkstillägg, till exempel loggning, beroendeinmatning (DI), konfiguration och hantering av appens livslängd. För mer information, se .NET Generisk Värd i ASP.NET Core och Backgrundsuppgifter med värdtjänster i ASP.NET Core.

Servers

En ASP.NET Core-app använder en HTTP-serverimplementering för att lyssna efter HTTP-begäranden. Servern visar begäranden till appen som en uppsättning begärandefunktioner sammansatta i en HttpContext.

ASP.NET Core tillhandahåller följande serverimplementeringar:

  • Kestrel är en plattformsoberoende webbserver. Kestrel körs ofta i en omvänd proxykonfiguration med hjälp av IIS-. I ASP.NET Core 2.0 eller senare kan Kestrel köras som en offentlig edge-server som exponeras direkt mot Internet.
  • IIS HTTP Server är en server för Windows som använder IIS. Med den här servern körs ASP.NET Core-appen och IIS i samma process.
  • HTTP.sys är en server för Windows som inte används med IIS.

Mer information finns i webbserverimplementeringar i ASP.NET Core.

Configuration

ASP.NET Core tillhandahåller ett konfigurationsramverk som hämtar inställningar som namn/värde-par från en ordnad uppsättning konfigurationsproviders. Inbyggda konfigurationsprovidrar är tillgängliga för en mängd olika källor, till exempel .json filer, .xml filer, miljövariabler och kommandoradsargument. Skriv anpassade konfigurationsprovidrar för att stödja andra källor.

Som standardär ASP.NET Core-appar konfigurerade för att läsa från appsettings.json, miljövariabler, kommandoraden med mera. När appens konfiguration läses in åsidosätter värden från miljövariabler värden från appsettings.json.

Det bästa sättet att läsa relaterade konfigurationsvärden är att använda mönstret alternativ. Mer information finns i Bind hierarkiska konfigurationsdata med hjälp av alternativmönstret.

För att hantera konfidentiella konfigurationsdata, till exempel lösenord, tillhandahåller .NET Secret Manager. För produktionshemligheter rekommenderar vi Azure Key Vault-.

Mer information finns i Configuration i ASP.NET Core.

Environments

Körningsmiljöer, till exempel Development, Stagingoch Production, är ett förstklassigt begrepp i ASP.NET Core. Ange den miljö som en app körs i genom att ange ASPNETCORE_ENVIRONMENT miljövariabeln. ASP.NET Core läser miljövariabeln vid appstart och lagrar värdet i en IWebHostEnvironment implementering. Den här implementeringen är tillgänglig var som helst i en app via beroendeinmatning (DI).

I följande exempel konfigureras appen för att tillhandahålla detaljerad felinformation när den körs i Development-miljön:

public void Configure(IApplicationBuilder app, IWebHostEnvironment env)
{
    if (env.IsDevelopment())
    {
        app.UseDeveloperExceptionPage();
    }
    else
    {
        app.UseExceptionHandler("/Error");
        app.UseHsts();
    }

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

    app.UseRouting();

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

Mer information finns i ASP.NET Core-körningsmiljöer.

Logging

ASP.NET Core stöder ett loggnings-API som fungerar med en mängd olika inbyggda och tredje parts loggningsproviders. Tillgängliga leverantörer är:

  • Console
  • Debug
  • Händelsespårning i Windows
  • Windows-händelselogg
  • TraceSource
  • Azure App Service
  • Azure Application Insights

Om du vill skapa loggar löser du en ILogger<TCategoryName>-tjänst från beroendeinmatning (DI) och anropar loggningsmetoder som LogInformation. Till exempel:

public class TodoController : ControllerBase
{
    private readonly ILogger _logger;

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

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

Loggningsmetoder som LogInformation stöder valfritt antal fält. Dessa fält används ofta för att skapa ett meddelande string, men vissa loggningsproviders skickar dessa till ett datalager som separata fält. Den här funktionen gör det möjligt för loggningsleverantörer att implementera semantisk loggning, även kallat strukturerad loggning.

Mer information finns i Loggning i .NET och ASP.NET Core.

Routing

En rutt är en URL-mall som mappas till en hanterare. Hanteraren är vanligtvis en Razor sida, en åtgärdsmetod i en MVC-styrenhet eller ett mellanprogram. ASP.NET Core-routning ger dig kontroll över de URL:er som används av din app.

Mer information finns i Routning i ASP.NET Core.

Felhantering

ASP.NET Core har inbyggda funktioner för att hantera fel, till exempel:

  • En undantagssida för utvecklare
  • Anpassade felsidor
  • Statiska statuskodsidor
  • Undantagshantering vid start

Mer information finns i Hantera fel i ASP.NET Core.

Att göra HTTP-förfrågningar

En implementering av IHttpClientFactory är tillgänglig för att skapa HttpClient instanser. Fabriken:

  • Tillhandahåller en central plats för att namnge och konfigurera logiska HttpClient instanser. Du kan till exempel registrera och konfigurera en github--klient för åtkomst till GitHub. Registrera och konfigurera en standardklient för andra ändamål.
  • Stöder registrering och länkning av flera delegerande hanterare för att skapa en pipeline för mellanprogram för utgående begäran. Det här mönstret liknar ASP.NET Cores inkommande mellanprogramspipeline. Mönstret ger en mekanism för att hantera övergripande problem för HTTP-begäranden, inklusive cachelagring, felhantering, serialisering och loggning.
  • Integrerar med Polly, ett populärt bibliotek från tredje part för tillfällig felhantering.
  • Hanterar pooler och livslängden för underliggande HttpClientHandler instanser för att undvika vanliga DNS-problem som uppstår vid hantering av HttpClient livslängd manuellt.
  • Lägger till en konfigurerbar loggningsupplevelse via ILogger för alla begäranden som skickas via klienter som skapats av fabriken.

Mer information finns i Gör HTTP-begäranden med IHttpClientFactory i ASP.NET Core.

Innehållsrot

Innehållsroten är bassökvägen för:

  • Det körbara programmet som kör appen (.exe).
  • Kompilerade sammansättningar som utgör appen (.dll).
  • Innehållsfiler som används av appen, till exempel:
    • Razor filer (.cshtml, .razor)
    • Konfigurationsfiler (.json, .xml)
    • Datafiler (.db)
  • Den webbroten, vanligtvis mappen wwwroot.

Under utvecklingen är innehållsroten som standard i projektets rotkatalog. Den här katalogen är också bassökvägen för både appens innehållsfiler och webbroten. Ange en annan innehållsrot genom att ange sökvägen när att skapa värden. Mer information finns i Innehållsrot.

Webbrotsmapp

Webbroten är bassökvägen för offentliga, statiska resursfiler, till exempel:

  • Formatmallar (.css)
  • JavaScript (.js)
  • Bilder (.png, .jpg)

Som standard hanteras statiska filer endast från webbrotkatalogen och dess underkataloger. Webbrotsökvägen är som standard {content root}/wwwroot. Ange en annan webbroten genom att ange dess sökväg när du bygger värden . Mer information finns i Web Root.

Förhindra publicering av filer i wwwroot- med projektobjektet <Innehåll> i projektfilen. I följande exempel förhindras publicering av innehåll i wwwroot/lokal och dess underkataloger:

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

I Razor.cshtml filer pekar tilde-slash (~/) till webbrooten. En sökväg som börjar med ~/ kallas för en virtuell sökväg.

För mer information, se statiska filer i ASP.NET Core.

Så här laddar du ned ett exempel

Många av artiklarna och självstudierna innehåller länkar till exempelkod.

  1. Ladda ner ASP.NET-kodförrådets zip-fil.
  2. Packa upp AspNetCore.Docs-main.zip-filen.
  3. Om du vill komma åt en artikels exempelapp på den uppackade lagringsplatsen använder du URL:en i artikelns exempellänk för att navigera till exempelmappen. Vanligtvis visas en artikels exempellänk överst i artikeln med länktexten Visa eller ladda ned exempelkod.

Förprocessordirektiv i exempelkod

För att demonstrera flera scenarier använder exempelappar direktiven #define och #if-#else/#elif-#endif förprocessor för att selektivt kompilera och köra olika delar av exempelkoden. För de exempel som använder den här metoden anger du #define-direktivet överst i C#-filerna för att definiera symbolen som är associerad med det scenario som du vill köra. Vissa exempel kräver att du definierar symbolen överst i flera filer för att kunna köra ett scenario.

Följande #define symbollista anger till exempel att fyra scenarier är tillgängliga (ett scenario per symbol). Aktuell exempelkonfiguration kör scenariot TemplateCode:

#define TemplateCode // or LogFromMain or ExpandDefault or FilterInCode

Om du vill ändra exemplet för att köra ExpandDefault scenariot definierar du ExpandDefault-symbolen och lämnar de återstående symbolerna utkommenterade:

#define ExpandDefault // TemplateCode or LogFromMain or FilterInCode

Mer information om hur du använder C#-förprocessordirektiv för att selektivt kompilera kodavsnitt finns i #define (C#-referens) och #if (C#-referens).

Regioner i exempelkod

Vissa exempelappar innehåller kodavsnitt omgivna av #region - och #endregion C#-direktiv. Dokumentationens byggsystem matar in dessa regioner i de renderade dokumentationsämnena.

Regionnamn innehåller vanligtvis ordet "kodfragment". I följande exempel visas en region med namnet snippet_WebHostDefaults:

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

Det föregående C#-kodfragmentet refereras till i ämnets markdown-fil med följande rad:

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

Du kan ignorera eller ta bort direktiven #region och #endregion som omger koden på ett säkert sätt. Ändra inte koden i dessa direktiv om du planerar att köra de exempelscenarier som beskrivs i ämnet.

Mer information finns i Bidra till ASP.NET dokumentation: Kodfragment.

Den här artikeln innehåller en översikt över grunderna för att skapa ASP.NET Core-appar, inklusive beroendeinmatning (DI), konfiguration, mellanprogram med mera.

Vägledning för Blazor grunder, som kompletterar eller ersätter vägledningen i den här noden, finns i ASP.NET Core Blazor Core-grunder.

Program.cs

ASP.NET Core-appar som skapats med webbmallarna innehåller programmets startkod i filen Program.cs. Filen Program.cs är där.

  • Tjänster som krävs av appen konfigureras.
  • Appens pipeline för hantering av begäranden definieras som en serie mellanprogramkomponenter.

Följande appstartkod stöder:

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

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

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

app.UseAuthorization();

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

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

app.Run();

Beroendeinmatning (tjänster)

ASP.NET Core innehåller beroendeinjektion (DI) som gör konfigurerade tjänster tillgängliga genom en app. Tjänster läggs till i DI-containern med WebApplicationBuilder.Services, builder.Services i föregående kod. När WebApplicationBuilder instansieras läggs många ramverkstjänster till. builder är en WebApplicationBuilder i följande kod:

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

I den markerade koden ovan har builder konfiguration, loggning och många andra tjänster lagts till i DI-containern.

Följande kod lägger till Razor Pages, MVC-styrenheter med vyer och en anpassad DbContext till DI-containern:

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

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

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

var app = builder.Build();

Tjänster löses vanligtvis från DI med konstruktorinmatning. DI-ramverket tillhandahåller en instans av den här tjänsten under körning.

I följande kod används konstruktorinmatning för att lösa databaskontexten och loggaren från DI:

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

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

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

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

Middleware

Pipelinen för hantering av begäranden består av en serie mellanprogramskomponenter. Varje komponent utför åtgärder på en HttpContext och anropar antingen nästa mellanprogram i pipelinen eller avslutar begäran.

Enligt konventionen läggs en mellanprogramskomponent till i pipelinen genom att en Use{Feature} tilläggsmetod anropas. Mellanprogram som läggs till i appen är markerat i följande kod:

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

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

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

app.UseAuthorization();

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

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

app.Run();

Mer information finns i ASP.NET Core Middleware.

Host

När en ASP.NET Core-app startar bygger den en värd. Värden kapslar in alla appens resurser, till exempel:

  • En HTTP-serverimplementering
  • Mellanprogramskomponenter
  • Logging
  • Tjänster för beroendeinjektion
  • Configuration

Det finns tre olika värdar som kan köra en ASP.NET Core-app:

Typerna ASP.NET Core WebApplication och WebApplicationBuilder rekommenderas och används i alla ASP.NET Core-mallar. WebApplication fungerar på samma sätt som .NET Generic Hosten och exponerar många av samma gränssnitt, men kräver färre callback-funktioner för att konfigurera. ASP.NET Core WebHost är endast tillgänglig för bakåtkompatibilitet.

I följande exempel instansieras en WebApplication:

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

Metoden WebApplicationBuilder.Build konfigurerar en värd med en uppsättning standardalternativ, till exempel:

  • Använd Kestrel som webbserver och aktivera IIS-integrering.
  • Läs in konfiguration från appsettings.json, miljövariabler, kommandoradsargument och andra konfigurationskällor.
  • Skicka loggutdata till konsolen och debuggproviders.

Scenarier som inte är webb

Med den generiska värden kan andra typer av appar använda övergripande ramverkstillägg, till exempel loggning, beroendeinmatning (DI), konfiguration och hantering av appens livslängd. För mer information, se .NET Generisk Värd i ASP.NET Core och Backgrundsuppgifter med värdtjänster i ASP.NET Core.

Servers

En ASP.NET Core-app använder en HTTP-serverimplementering för att lyssna efter HTTP-begäranden. Servern visar begäranden till appen som en uppsättning begärandefunktioner sammansatta i en HttpContext.

ASP.NET Core tillhandahåller följande serverimplementeringar:

  • Kestrel är en plattformsoberoende webbserver. Kestrel körs ofta i en omvänd proxykonfiguration med hjälp av IIS-. I ASP.NET Core 2.0 eller senare kan Kestrel köras som en offentlig edge-server som exponeras direkt mot Internet.
  • IIS HTTP Server är en server för Windows som använder IIS. Med den här servern körs ASP.NET Core-appen och IIS i samma process.
  • HTTP.sys är en server för Windows som inte används med IIS.

Mer information finns i webbserverimplementeringar i ASP.NET Core.

Configuration

ASP.NET Core tillhandahåller ett konfigurationsramverk som hämtar inställningar som namn/värde-par från en ordnad uppsättning konfigurationsproviders. Inbyggda konfigurationsprovidrar är tillgängliga för en mängd olika källor, till exempel .json filer, .xml filer, miljövariabler och kommandoradsargument. Skriv anpassade konfigurationsprovidrar för att stödja andra källor.

Som standardär ASP.NET Core-appar konfigurerade för att läsa från appsettings.json, miljövariabler, kommandoraden med mera. När appens konfiguration läses in åsidosätter värden från miljövariabler värden från appsettings.json.

För att hantera konfidentiella konfigurationsdata, till exempel lösenord, tillhandahåller .NET Secret Manager. För produktionshemligheter rekommenderar vi Azure Key Vault-.

Mer information finns i Configuration i ASP.NET Core.

Environments

Exekveringsmiljöer, till exempel Development, Stagingoch Production, är tillgängliga i ASP.NET Core. Ange den miljö som en app körs i genom att ange ASPNETCORE_ENVIRONMENT miljövariabeln. ASP.NET Core läser miljövariabeln vid appstart och lagrar värdet i en IWebHostEnvironment implementering. Den här implementeringen är tillgänglig var som helst i en app via beroendeinmatning (DI).

I följande exempel konfigureras undantagshanteraren och HTTP Strict Transport Security Protocol (HSTS) mellanprogram när inte körs i Development miljö:

var builder = WebApplication.CreateBuilder(args);

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

var app = builder.Build();

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

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

app.UseAuthorization();

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

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

app.Run();

Mer information finns i ASP.NET Core-körningsmiljöer.

Logging

ASP.NET Core stöder ett loggnings-API som fungerar med en mängd olika inbyggda och tredje parts loggningsproviders. Tillgängliga leverantörer är:

  • Console
  • Debug
  • Händelsespårning i Windows
  • Windows-händelselogg
  • TraceSource
  • Azure App Service
  • Azure Application Insights

Om du vill skapa loggar löser du en ILogger<TCategoryName>-tjänst från beroendeinmatning (DI) och anropar loggningsmetoder som LogInformation. Till exempel:

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

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

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

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

Mer information finns i Loggning i .NET och ASP.NET Core.

Routing

En rutt är en URL-mall som mappas till en hanterare. Hanteraren är vanligtvis en Razor sida, en åtgärdsmetod i en MVC-styrenhet eller ett mellanprogram. ASP.NET Core-routning ger dig kontroll över de URL:er som används av din app.

Följande kod, som genereras av webbprogrammallen ASP.NET Core, anropar UseRouting:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorPages();

var app = builder.Build();

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

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

app.UseRouting();

app.UseAuthorization();

app.MapRazorPages();

app.Run();

Mer information finns i Routning i ASP.NET Core.

Felhantering

ASP.NET Core har inbyggda funktioner för att hantera fel, till exempel:

  • En undantagssida för utvecklare
  • Anpassade felsidor
  • Statiska statuskodsidor
  • Undantagshantering vid start

Mer information finns i Hantera fel i ASP.NET Core.

Att göra HTTP-förfrågningar

En implementering av IHttpClientFactory är tillgänglig för att skapa HttpClient instanser. Fabriken:

  • Tillhandahåller en central plats för att namnge och konfigurera logiska HttpClient instanser. Du kan till exempel registrera och konfigurera en github--klient för åtkomst till GitHub. Registrera och konfigurera en standardklient för andra ändamål.
  • Stöder registrering och länkning av flera delegerande hanterare för att skapa en pipeline för mellanprogram för utgående begäran. Det här mönstret liknar ASP.NET Cores inkommande mellanprogramspipeline. Mönstret ger en mekanism för att hantera övergripande problem för HTTP-begäranden, inklusive cachelagring, felhantering, serialisering och loggning.
  • Integrerar med Polly, ett populärt bibliotek från tredje part för tillfällig felhantering.
  • Hanterar pooler och livslängden för underliggande HttpClientHandler instanser för att undvika vanliga DNS-problem som uppstår vid hantering av HttpClient livslängd manuellt.
  • Lägger till en konfigurerbar loggningsupplevelse via ILogger för alla begäranden som skickas via klienter som skapats av fabriken.

Mer information finns i Gör HTTP-begäranden med IHttpClientFactory i ASP.NET Core.

Innehållsrot

Innehållsroten är bassökvägen för:

  • Det körbara programmet som kör appen (.exe).
  • Kompilerade sammansättningar som utgör appen (.dll).
  • Innehållsfiler som används av appen, till exempel:
    • Razor filer (.cshtml, .razor)
    • Konfigurationsfiler (.json, .xml)
    • Datafiler (.db)
  • Den webbroten, vanligtvis mappen wwwroot.

Under utvecklingen är innehållsroten som standard i projektets rotkatalog. Den här katalogen är också bassökvägen för både appens innehållsfiler och webbroten. Ange en annan innehållsrot genom att ange sökvägen när att skapa värden. Mer information finns i Innehållsrot.

Webbroten

Webbroten är bassökvägen för offentliga, statiska resursfiler, till exempel:

  • Formatmallar (.css)
  • JavaScript (.js)
  • Bilder (.png, .jpg)

Som standard hanteras statiska filer endast från webbrotkatalogen och dess underkataloger. Webbrotsökvägen är som standard {content root}/wwwroot. Ange en annan webbroten genom att ange dess sökväg när du bygger värden . Mer information finns i Web Root.

Förhindra publicering av filer i wwwroot- med projektobjektet <Innehåll> i projektfilen. I följande exempel förhindras publicering av innehåll i wwwroot/lokal och dess underkataloger:

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

I filer märkta Razor.cshtml pekar ~/ på webbrooten. En sökväg som börjar med ~/ kallas för en virtuell sökväg.

För mer information, se statiska filer i ASP.NET Core.

Så här laddar du ned ett exempel

Många av artiklarna och självstudierna innehåller länkar till exempelkod.

  1. Ladda ner ASP.NET-kodförrådets zip-fil.
  2. Packa upp AspNetCore.Docs-main.zip-filen.
  3. Om du vill komma åt en artikels exempelapp på den uppackade lagringsplatsen använder du URL:en i artikelns exempellänk för att navigera till exempelmappen. Vanligtvis visas en artikels exempellänk överst i artikeln med länktexten Visa eller ladda ned exempelkod.

Förprocessordirektiv i exempelkod

För att demonstrera flera scenarier använder exempelappar direktiven #define och #if-#else/#elif-#endif förprocessor för att selektivt kompilera och köra olika delar av exempelkoden. För de exempel som använder den här metoden anger du #define-direktivet överst i C#-filerna för att definiera symbolen som är associerad med det scenario som du vill köra. Vissa exempel kräver att du definierar symbolen överst i flera filer för att kunna köra ett scenario.

Följande #define symbollista anger till exempel att fyra scenarier är tillgängliga (ett scenario per symbol). Aktuell exempelkonfiguration kör scenariot TemplateCode:

#define TemplateCode // or LogFromMain or ExpandDefault or FilterInCode

Om du vill ändra exemplet för att köra ExpandDefault scenariot definierar du ExpandDefault-symbolen och lämnar de återstående symbolerna utkommenterade:

#define ExpandDefault // TemplateCode or LogFromMain or FilterInCode

Mer information om hur du använder C#-förprocessordirektiv för att selektivt kompilera kodavsnitt finns i #define (C#-referens) och #if (C#-referens).

Regioner i exempelkod

Vissa exempelappar innehåller kodavsnitt omgivna av #region - och #endregion C#-direktiv. Dokumentationens byggsystem matar in dessa regioner i de renderade dokumentationsämnena.

Regionnamn innehåller vanligtvis ordet "kodfragment". I följande exempel visas en region med namnet snippet_WebHostDefaults:

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

Det föregående C#-kodfragmentet refereras till i ämnets markdown-fil med följande rad:

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

Du kan ignorera eller ta bort direktiven #region och #endregion som omger koden på ett säkert sätt. Ändra inte koden i dessa direktiv om du planerar att köra de exempelscenarier som beskrivs i ämnet.

Mer information finns i Bidra till ASP.NET dokumentation: Kodfragment.