Nyheter i ASP.NET Core i .NET 11

Den här artikeln belyser de viktigaste ändringarna i ASP.NET Core i .NET 11 med länkar till relevant dokumentation.

Den här artikeln uppdateras när nya förhandsversioner görs tillgängliga.

Blazor

I det här avsnittet beskrivs nya funktioner för Blazor.

Ny `DisplayName` komponent och stöd för `[Display]` och `[DisplayName]` attribut

Komponenten DisplayName kan användas för att visa egenskapsnamn från metadataattribut:

[Required, DisplayName("Production Date")]
public DateTime ProductionDate { get; set; }

Attributet [Display] för modellklassegenskapen stöds:

[Required, Display(Name = "Production Date")]
public DateTime ProductionDate { get; set; }

Av de två metoderna [Display] rekommenderas attributet, vilket gör ytterligare egenskaper tillgängliga. Attributet [Display] gör det också möjligt att tilldela en resurstyp för lokalisering. När båda attributen finns [Display] har företräde framför [DisplayName]. Om inget av attributen finns, återgår komponenten till egenskapsnamnet.

Använd komponenten DisplayName i etiketter eller tabellrubriker:

<label>
    <DisplayName For="@(() => Model!.ProductionDate)" />
    <InputDate @bind-Value="Model!.ProductionDate" />
</label>

Blazor Format för startalternativ för webbskript stöds nu för Blazor Server och Blazor WebAssembly skript

Skriptalternativobjektet Blazor Web App (blazor.web.js) som skickas till Blazor.start() använder följande format sedan .NET 8 släpptes:

Blazor.start({
  ssr: { ... },
  circuit: { ... },
  webAssembly: { ... },
});

Blazor Server Nu kan (blazor.server.js) och Blazor WebAssembly (blazor.webassembly.js) skript använda samma alternativformat.

I följande exempel visas formatet för tidigare alternativ, som fortfarande stöds:

Blazor.start({
  loadBootResource: function (...) {
      ...
    },
  });

Det nyligen stödda alternativformatet för föregående exempel:

Blazor.start({
  webAssembly: {
    loadBootResource: function (...) {
      ...
    },
  },
});

Mer information finns i ASP.NET Core Blazor start.

Ny `BasePath` komponent

Blazor Web Apps kan använda den nya BasePath komponenten (<BasePath />) för att automatiskt återge HTML-elementet för appens appbassökväg (<base href>). För mer information, se basvägen för ASP.NET Core-app Blazor.

Infogad JS händelsehanterare har tagits bort från komponenten `NavMenu`

Den infogade JS händelsehanterare som växlar visning av navigeringslänkar finns inte längre i komponenten NavMenu i projektmallen Blazor Web App . Appar som genereras från projektmallen använder nu en samlokaliserad JS modul för att visa eller dölja navigationsfältet på den renderade sidan. Den nya metoden förbättrar CSP-efterlevnaden (Content Security Policy) eftersom det inte kräver att CSP inkluderar en osäker hash för den infogade JS.

Information om hur du migrerar en befintlig app till .NET 11, inklusive att anta den nya JS modulmetoden för navigeringsfältets växlare, finns i guiden Migrera från ASP.NET Core i .NET 10 till ASP.NET Core i .NET 11.

`NavigateTo` och `NavLink` stöd för relativ navigering

Med den nya RelativeToCurrentUri parametern (standard: false) för NavigationManager.NavigateTo och komponentenNavLink kan du navigera till URI:er i förhållande till den aktuella sidsökvägen i stället för appens bas-URI.

Överväg följande kapslade slutpunkter:

/docs
- /getting-started
  - /installation
  - /configuration

När webbläsarens URI är /docs/getting-started/installation och du vill navigera användaren till /docs/getting-started/configurationomdirigeras NavigateTo("/configuration") till /configuration i appens rot i stället för den relativa sökvägen på /docs/getting-started/configuration. Ställ in RelativeToCurrentUri med NavigateTo eller NavLink-komponenten för önskad navigation:

Navigation.NavigateTo("/configuration", new NavigationOptions
{
    RelativeToCurrentUri = true
});

<NavLink href="configuration" RelativeToCurrentUri="true">Configuration</NavLink>

Spara temporära data mellan HTTP-begäranden under statisk återgivning på serversidan (statisk SSR)

För att spara tillfälliga data mellan HTTP-begäranden under statisk rendering på serversidan (statisk SSR), stödjer Blazor TempData. TempData är perfekt för scenarier som flash-meddelanden efter formuläröverföringar, överföring av data under omdirigeringar (POST-Redirect-GET mönster) och engångsmeddelanden.

TempData är tillgängligt när AddRazorComponents anropas i appens Program-fil och tillhandahålls som ett kaskadvärde med [CascadingParameter]-attributet.

[CascadingParameter]
public ITempData? TempData { get; set; }

Mer information finns i ASP.NET Core-tillståndshantering Blazor på serversidan.

Ny Web Worker-mall (`webworker`)

Blazor WebAssembly appar kan utföra tung databehandling på klienten, men om du gör det i användargränssnittstråden störs användargränssnittsåtergivningen och användarupplevelsen påverkas negativt. I .NET 10 lade vi till en artikel med en exempelapp för att underlätta avlastning av tungt arbete från användargränssnittstråden till en webbarbetare. För .NET 11 har vi lagt till .NET Web Worker-projektmallen (webworker), som tillhandahåller infrastruktur för att köra .NET-kod i en webbarbetare. Mer information finns i ASP.NET Core Blazor med .NET på Web Workers.

Blazor Hybrid

I det här avsnittet beskrivs nya funktioner för Blazor Hybrid.

Versionsinformation visas i det här avsnittet när förhandsgranskade funktioner blir tillgängliga.

SignalR

I det här avsnittet beskrivs nya funktioner för SignalR.

Minimala API:er

I det här avsnittet beskrivs nya funktioner för minimala API:er.

OpenAPI

I det här avsnittet beskrivs nya funktioner för OpenAPI.

Beskriva binärfilsvar

ASP.NET Core 11 introducerar stöd för att generera OpenAPI-beskrivningar för åtgärder som returnerar binära filsvar. Det här stödet mappar FileContentResult resultattypen till ett OpenAPI-schema med type: string och format: binary.

Minimala API:er
Controllers

Produces<T> Använd tilläggsmetoden med T för FileContentResult för att ange svarstyp och innehållstyp:

app.MapPost("/filecontentresult", () =>
{
    var content = "This endpoint returns a FileContentResult!"u8.ToArray();
    return TypedResults.File(content);
})
.Produces<FileContentResult>(contentType: MediaTypeNames.Application.Octet);

ProducesResponseType<T> Använd attributet med T för FileContentResult för att ange svarstyp och innehållstyp:

[HttpPost("filecontentresult")]
[ProducesResponseType<FileContentResult>(StatusCodes.Status200OK, MediaTypeNames.Application.Octet)]
public IActionResult PostFileContentResult()
{
    var content = "This endpoint returns a FileContentResult!"u8.ToArray();
    return new FileContentResult(content, MediaTypeNames.Application.Octet);
}

Det genererade OpenAPI-dokumentet beskriver slutpunktssvaret som:

responses:
  '200':
    description: OK
    content:
      application/octet-stream:
        schema:
          $ref: '#/components/schemas/FileContentResult'

FileContentResult Definieras i components/schemas som:

components:
  schemas:
    FileContentResult:
      type: string
      format: binary

OpenAPI 3.2.0-stöd (brytande ändring)

Microsoft.AspNetCore.OpenApi stöder nu OpenAPI 3.2.0 genom en uppdaterad beroende av Microsoft.OpenApi 3.3.1. Den här uppdateringen innehåller icke-bakåtkompatibla ändringar från det underliggande biblioteket. Mer information finns i uppgraderingsguiden för Microsoft.OpenApi.

Om du vill generera ett OpenAPI 3.2.0-dokument anger du versionen när du anropar AddOpenApi:

builder.Services.AddOpenApi(options =>
{
    options.OpenApiVersion = Microsoft.OpenApi.OpenApiSpecVersion.OpenApi3_2;
});

Efterföljande uppdateringar drar nytta av nya funktioner i 3.2.0-specifikationen, till exempel stöd för objektschema för strömningshändelser.

Tack @baywet för detta bidrag!

Autentisering och auktorisering

I det här avsnittet beskrivs nya funktioner för autentisering och auktorisering.

`TimeProvider` stöd i ASP.NET Core Identity

ASP.NET Core Identity använder nu TimeProvider istället för DateTime och DateTimeOffset för alla tidsrelaterade åtgärder. Den här ändringen gör Identity komponenterna mer testbara och ger bättre kontroll över tid i tester och specialiserade scenarier.

I följande exempel visas hur du använder en falsk TimeProvider för att testa Identity funktioner:

// In tests
var fakeTimeProvider = new FakeTimeProvider(
    new DateTimeOffset(2024, 1, 1, 0, 0, 0, TimeSpan.Zero));

services.AddSingleton<TimeProvider>(fakeTimeProvider);
services.AddIdentity<IdentityUser, IdentityRole>();

// Identity will now use the fake time provider

Med hjälp TimeProviderav kan du enklare skriva deterministiska tester för tidskänsliga Identity funktioner som förfallotid för token, varaktighet för utelåsning och validering av säkerhetsstämpel.

Härled visningsnamn för nyckel från autentisering

ASP.NET Core Identity härleder nu automatiskt vänliga visningsnamn för passerkoder baserat på deras AAGUID (Authenticator Attestation GUID). Inbyggda mappningar ingår för de vanligaste lösenordsautentiseringarna, inklusive Google Password Manager, iCloud Keychain, Windows Hello, 1Password och Bitwarden.

För kända autentiserare tilldelas namnet automatiskt utan att användaren uppmanas att göra det. För okända autentiserare omdirigeras användaren till en namnbytessida. Utöka mappningarna genom att lägga till poster i PasskeyAuthenticators ordboken i projektet.

Miscellaneous

I det här avsnittet beskrivs diverse nya funktioner i .NET 11.

`IOutputCachePolicyProvider` gränssnitt

ASP.NET Core i .NET 11 tillhandahåller gränssnittet [IOutputCachePolicyProvider](https://source.dot.net/#Microsoft.AspNetCore.OutputCaching/[IOutputCachePolicyProvider.cs](https://source.dot.net/#Microsoft.AspNetCore.OutputCaching/IOutputCachePolicyProvider.cs)" för implementering av logik för val av anpassad cachelagringsprincip för utdata. Med hjälp av det här gränssnittet kan appar fastställa standardprincipen för grundläggande cachelagring, kontrollera om det finns namngivna principer och stödja avancerade scenarier där principer måste lösas dynamiskt. Exempel är inläsningsprinciper från externa konfigurationskällor, databaser eller tillämpning av klientspecifika cachelagringsregler.

Följande kod visar IOutputCachePolicyProvider gränssnittet:

public interface IOutputCachePolicyProvider
{
    IReadOnlyList<IOutputCachePolicy> GetBasePolicies();
    ValueTask<IOutputCachePolicy?> GetPolicyAsync(string policyName);
}

Tack @lqlive för detta bidrag!

Certifikat för automatisk förtroendeutveckling i WSL

Konfigurationen av utvecklingscertifikatet litar nu automatiskt på certifikat i WSL-miljöer (Windows-undersystem för Linux). När du kör dotnet dev-certs https --trust i WSL installeras certifikatet automatiskt och är betrott i både WSL-miljön och Windows, vilket eliminerar manuell förtroendekonfiguration.

# Automatically trusts certificates in both WSL and Windows
dotnet dev-certs https --trust

Den här förbättringen effektiviserar utvecklingsupplevelsen när du använder WSL, vilket tar bort en gemensam friktionspunkt för utvecklare som arbetar i Linux-miljöer i Windows.

Tack @StickFun för detta bidrag!

Intern OpenTelemetry-spårning för ASP.NET Core

ASP.NET Core lägger nu internt till OpenTelemetry-semantiska konventionsattribut till HTTP-serveraktiviteten, i linje med HTTP-serverintervallspecifikationen OpenTelemetry. Alla obligatoriska attribut ingår som standard och matchar de metadata som tidigare endast var tillgängliga via OpenTelemetry.Instrumentation.AspNetCore biblioteket.

Om du vill samla in inbyggda spårningsdata prenumererar du på aktivitetskällan Microsoft.AspNetCore i din OpenTelemetry-konfiguration:

builder.Services.AddOpenTelemetry()
    .WithTracing(tracing => tracing
        .AddSource("Microsoft.AspNetCore")
        .AddConsoleExporter());

Inget ytterligare instrumentationsbibliotek (till exempel OpenTelemetry.Instrumentation.AspNetCore) behövs. Ramverket fyller nu i semantiska konventionsattribut direkt på begärandeaktiviteten, till exempel http.request.method, url.path, http.response.status_codeoch server.address.

Om du inte vill att OpenTelemetry-attribut ska läggas till i aktiviteten kan du inaktivera det genom att ställa in AppContext-växeln Microsoft.AspNetCore.Hosting.SuppressActivityOpenTelemetryData på true.

Prestandaförbättringar

Kestrel's HTTP/1.1-begärandeparser använder nu en kodväg som inte kastar undantag vid hantering av felaktigt formaterade begäranden. I stället för att BadHttpRequestException kasta på varje parsningsfel returnerar parsern en resultat struct som anger lyckade, ofullständiga eller feltillstånd. I scenarier med många felaktiga begäranden – till exempel portgenomsökning, skadlig trafik eller felkonfigurerade klienter – eliminerar detta dyra kostnader för undantagshantering och förbättrar dataflödet med upp till 20–40%. Det påverkar inte giltig bearbetning av begäranden.

HTTP-loggningsmellanprogrammet poolar nu sina ResponseBufferingStream instanser, vilket minskar allokering per begäran när loggning av svarstext eller interceptorer aktiveras.

Brytande förändringar

Använd artiklarna i Icke-bakåtkompatibla ändringar i .NET för att hitta icke-bakåtkompatibla ändringar som kan gälla när du uppgraderar en app till en nyare version av .NET.

Feedback

Var den här sidan till hjälp?

Last updated on 2026-03-16