Megosztás a következőn keresztül:

A ASP.NET Core 8.0 újdonságai

  • Cikk

Ez a cikk a ASP.NET Core 8.0 legfontosabb változásait emeli ki a vonatkozó dokumentációra mutató hivatkozásokkal.

Blazor

Komplett webes felhasználói felület

A .NET 8 kiadásával a Blazor egy teljes körű webes felhasználói felületi keretrendszer olyan alkalmazások fejlesztéséhez, amelyek az összetevő vagy az oldal szintjén renderelik a tartalmat a következőkkel:

  • Statikus kiszolgálói renderelés (más néven statikus kiszolgálóoldali renderelés, statikus SSR) statikus HTML-fájl létrehozása a kiszolgálón.
  • Interaktív kiszolgálómegjelenítés (más néven interaktív kiszolgálóoldali renderelés, interaktív SSR), amely interaktív összetevőket hoz létre a kiszolgálón való előrendeléssel.
  • Interaktív WebAssembly-renderelés (más néven ügyféloldali renderelés, CSR, amely mindig interaktívnak számít), hogy interaktív összetevőket hozzon létre az ügyfélen, a kiszolgálón való előrenderelés mellett.
  • Interaktív automatikus (automatikus) renderelés a kiszolgálóoldali ASP.NET Core-futtatókörnyezet tartalommegjelenítéshez és interaktivitáshoz való kezdeti használatához. Az ügyfél .NET WebAssembly futtatókörnyezete a Blazor csomag letöltése és a WebAssembly-futtatókörnyezet aktiválása után használható későbbi rendereléshez és interaktivitáshoz. Az interaktív automatikus renderelés általában a leggyorsabb alkalmazásindítási élményt nyújtja.

Az interaktív renderelési módok alapértelmezés szerint előrendelik a tartalmat is.

További információkért lásd a következő cikkeket:

A Blazor dokumentációban szereplő példák frissültek Blazor Web Apps-ben való használatra. A Blazor Server példák a .NET 7-es vagy korábbi verziójú tartalomban maradnak.

Új cikk a statikus kiszolgálóoldali rendereléssel rendelkező osztálykódtárakról (statikus SSR)

Hozzáadtunk egy új cikket, amely a Razor osztálykódtárak (RCL-k) összetevőtárainak szerkesztését ismerteti statikus kiszolgálóoldali rendereléssel (statikus SSR).

További információ: ASP.NET Core Razor osztálykódtárak (RCLs) statikus kiszolgálóoldali rendereléssel (statikus SSR).

Új cikk a HTTP-gyorsítótárazással kapcsolatos problémákról

Felvettünk egy új cikket, amely ismerteti a HTTP-gyorsítótárazással kapcsolatos gyakori problémákat, amelyek Blazor alkalmazások nagyobb verziókra való frissítésekor és a HTTP-gyorsítótárazási problémák megoldásában jelentkezhetnek.

További információért lásd: HTTP-gyorsítótárazási problémák elkerülése az ASP.NET Core Blazor alkalmazásokfrissítésekor.

Új Blazor Web App sablon

Bevezettünk egy új Blazor projektsablont: a Blazor Web App sablont. Az új sablon egyetlen kiindulópontot biztosít Blazor összetevők használatával bármilyen stílusú webes felhasználói felület létrehozásához. A sablon egyesíti a meglévő Blazor Server és Blazor WebAssembly üzemeltetési modellek erősségeit a .NET 8-ban hozzáadott új Blazor képességekkel: statikus kiszolgálóoldali renderelés (statikus SSR), streamelési renderelés, továbbfejlesztett navigáció és űrlapkezelés, valamint az interaktivitás hozzáadása Blazor Server vagy Blazor WebAssembly összetevőnkénti alapon.

A különböző Blazor üzemeltetési modellek egyetlen modellbe való egyesítése részeként a .NET 8-ban összevonjuk a Blazor projektsablonok számát is. Eltávolítottuk a Blazor Server sablont, és a ASP.NET Core Hosted beállítás el lett távolítva a Blazor WebAssembly sablonból. Mindkét forgatókönyvet a Blazor Web App sablon használatakor megjelenő beállítások jelölik.

Jegyzet

A meglévő Blazor Server és Blazor WebAssembly alkalmazások továbbra is támogatottak a .NET 8-ban. Igény szerint ezek az alkalmazások frissíthetők az új full-stackos webes felhasználói felület Blazor funkcióinak használatára.

Az új Blazor Web App sablonról az alábbi cikkekben talál további információt:

Új JS inicializálók a Blazor Web App-ekhez

Blazor Server, Blazor WebAssemblyés Blazor Hybrid alkalmazások esetén:

  • beforeStart olyan feladatokhoz használható, mint a betöltési folyamat testreszabása, a naplózási szint és egyéb beállítások.
  • afterStarted olyan feladatokhoz használatos, mint például az Blazor eseményfigyelők és az egyéni eseménytípusok regisztrálása.

Az előző örökölt JS inicializálók alapértelmezés szerint nem hívódnak meg egy Blazor Web App-ben. Az Blazor Web App-ek esetében új JS inicializálókat használunk: beforeWebStart, afterWebStarted, beforeServerStart, afterServerStarted, beforeWebAssemblyStartés afterWebAssemblyStarted.

További információ: ASP.NET Core Blazor indítási.

Az előrenderelési és integrációs útmutató szétválasztása

A .NET korábbi kiadásaihoz egyetlen cikkben foglalkoztunk az előrendeléssel és az integrációval. A lefedettség egyszerűsítése és összpontosítása érdekében a témaköröket az alábbi új cikkekre osztottuk, amelyek frissültek a .NET 8-hoz:

Összetevő állapotának megőrzése egy Blazor Web App

A meglévő Blazor Web App szolgáltatással egy PersistentComponentState-ban megőrizheti és elolvashatja az összetevők állapotát. Ez hasznos a összetevő állapotának megőrzése során a prerenderelés közben.

Blazor Web Appautomatikusan megőrzi az előrenderelés során létrehozott regisztrált alkalmazásszintű állapotokat, így nincs szükség a komponens állapot megőrzése címke segéd használatára.

Űrlapkezelés és modellkötés

Blazor összetevők mostantól képesek kezelni az elküldött űrlapkérelmeket, beleértve a modellkötést és a kérelemadatok érvényesítését. Az összetevők a szabványos HTML-<form> címkével vagy a meglévő EditForm összetevővel külön űrlapkezelőkkel implementálhatják az űrlapokat.

Az űrlapmodell-kötés Blazor az adatszerződés attribútumait (például [DataMember] és [IgnoreDataMember]) tiszteletben tartja annak testreszabásához, hogy az űrlapadatok hogyan kötődnek a modellhez.

A .NET 8 új antiforgery-támogatást tartalmaz. Egy új AntiforgeryToken összetevő rejtett mezőként jeleníti meg az antiforgery tokent, az új [RequireAntiforgeryToken] attribútum pedig lehetővé teszi az antiforgery elleni védelmet. Ha az űrlaphamisítás elleni ellenőrzés sikertelen, a rendszer űrlapfeldolgozás nélkül visszaad egy 400-as (Hibás kérés) választ. Az új antiforgery funkciók alapértelmezés szerint engedélyezve vannak a Editform alapuló űrlapok esetében, és manuálisan alkalmazhatók a szabványos HTML-űrlapokra.

További információ, lásd: ASP.NET Core Blazor űrlapok áttekintése.

Továbbfejlesztett navigáció és űrlapkezelés

A statikus kiszolgálóoldali renderelés (statikus SSR) általában teljes oldalfrissítést hajt végre, amikor a felhasználó új oldalra lép vagy űrlapot küld el. A .NET 8-ban a Blazor javíthatja az oldalnavigációt és az űrlapkezelést úgy, hogy elfogja a kérést, és ehelyett lekéréses kérelmet hajt végre. Blazor ezután kezeli a renderelt választartalmat a böngésző DOM-jába való javításával. A továbbfejlesztett navigáció és űrlapkezelés nem igényel teljes oldalfrissítést, és több oldalállapotot őriz meg, így a lapok gyorsabban és zökkenőmentesebben töltődnek be. A továbbfejlesztett navigáció alapértelmezés szerint engedélyezve van a Blazor szkript (blazor.web.js) betöltésekor. A továbbfejlesztett űrlapkezelés opcionálisan engedélyezhető adott űrlapokhoz.

Az új továbbfejlesztett navigációs API lehetővé teszi az aktuális lap frissítését NavigationManager.Refresh(bool forceLoad = false)meghívásával.

További információt a BlazorÚtválasztási című cikk alábbi szakaszaiban talál:

Új cikk a statikus renderelésről továbbfejlesztett navigációval JS interophoz

Egyes alkalmazások JS interoptól függenek az egyes oldalakra jellemző inicializálási feladatok végrehajtásához. Ha Blazortovábbfejlesztett navigációs funkcióját olyan statikusan renderelt oldalakkal használja, amelyek JS interopicializálási feladatokat hajtanak végre, előfordulhat, hogy a lapspecifikus JS nem lesz újra végrehajtva a várt módon minden alkalommal, amikor továbbfejlesztett oldalnavigáció történik. Egy új cikk bemutatja, hogyan oldhatja meg ezt a forgatókönyvet Blazor Web Appesetében:

ASP.NET Core Blazor JavaScript statikus kiszolgálóoldali rendereléssel (statikus SSR)

Folyamatos megjelenítés

Mostantól a válaszfolyamon is streamelheti a tartalomfrissítéseket, ha statikus kiszolgálóoldali renderelést (statikus SSR- t) használ Blazor. A streamelési renderelés javíthatja a hosszan futó aszinkron feladatokat végző lapok felhasználói élményét annak érdekében, hogy a tartalom amint elérhető lesz, teljes mértékben renderelhető legyen.

Egy lap megjelenítéséhez például hosszú ideig futó adatbázis-lekérdezésre vagy API-hívásra lehet szükség. A lap renderelése során végrehajtott aszinkron feladatoknak általában a renderelt válasz elküldése előtt kell befejeződniük, ami késleltetheti a lap betöltését. A streamelési renderelés kezdetben helyőrző tartalommal jeleníti meg a teljes lapot az aszinkron műveletek végrehajtása közben. Az aszinkron műveletek befejezése után a rendszer elküldi a frissített tartalmat az ügyfélnek ugyanabban a válaszkapcsolatban, és a DOM-ba illeszti. Ennek a megközelítésnek az az előnye, hogy az alkalmazás fő elrendezése a lehető leggyorsabban jelenik meg, és a tartalom elkészülte után a lap azonnal frissül.

További információkért tekintse meg az ASP.NET Core Razor összetevő renderelését.

Kulcsos szolgáltatások injektálása összetevőkbe

Blazor mostantól támogatja a kulcsos szolgáltatások injektálását a [Inject] attribútum használatával. A kulcsok lehetővé teszik a regisztráció és a szolgáltatások használatának hatókörét függőséginjektálás használatakor. Az új InjectAttribute.Key tulajdonság használatával adja meg a szolgáltatás injektálandó kulcsát:

[Inject(Key = "my-service")]
public IMyService MyService { get; set; }

A @injectRazor irányelv nem támogatja a kulcsos szolgáltatásokat ehhez a kiadáshoz, de az Update @inject nyomon követi a kulcsos szolgáltatásokat (dotnet/razor #9286) egy jövőbeli .NET-kiadáshoz.

További információért lásd: ASP.NET Core Blazor függőség injektálása.

HttpContext elérése lépcsőzetes paraméterként

Az aktuális HttpContext most már lépcsőzetes paraméterként is elérheti egy statikus kiszolgáló összetevőből:

[CascadingParameter]
public HttpContext? HttpContext { get; set; }

A HttpContext statikus kiszolgálóösszetevőből való elérése hasznos lehet fejlécek vagy egyéb tulajdonságok vizsgálatához és módosításához.

Ha például HttpContext állapotot, hozzáférési és frissítési jogkivonatokat ad át az összetevőknek, tekintse meg ASP.NET Core kiszolgálóoldali és Blazor Web App további biztonsági forgatókönyveket.

Razor összetevők renderelése a ASP.NET Core-on kívül

Mostantól a HTTP-kérés környezetén kívül is megjelenítheti Razor összetevőket. Az Razor összetevőket HTML-ként közvetlenül egy sztringre vagy streamre jelenítheti meg, függetlenül a ASP.NET Core üzemeltetési környezetétől. Ez olyan helyzetekben hasznos, amikor HTML-töredékeket szeretne létrehozni, például e-maileket vagy statikus webhelytartalmakat szeretne létrehozni.

További információ: Render Razor összetevők az ASP.NET Core környezetén kívül.

Szakaszok támogatása

A SectionOutlet új SectionContent és Blazor összetevői támogatják a később kitölthető tartalmakhoz tartozó konnektorok megadását. A tartalmi szakaszokat gyakran használják helyőrzők meghatározására az elrendezésekben, amelyeket aztán konkrét oldalak töltenek ki. A szakaszokra egyedi név vagy egyedi objektumazonosító hivatkozik.

További információkért lásd: ASP.NET Core Blazor szakaszok.

Hibaoldal támogatása

Blazor Web Appaz ASP.NET Core kivételkezelési köztes szoftverhasználható egyéni hibalapot is definiálhatnak. A Blazor Web App projektsablon tartalmaz egy alapértelmezett hibalapot (Components/Pages/Error.razor) az MVC-ben és Razor Pages-alkalmazásokban használthoz hasonló tartalommal. Ha a hibalap a Exception Handling Middleware kérésére reagálva jelenik meg, a hibalap mindig statikus kiszolgáló-összetevőként jelenik meg, még akkor is, ha az interaktivitás egyébként engedélyezve van.

Error.razor az 8.0 referenciaforrásban

QuickGrid

A BlazorQuickGrid összetevő már nem kísérleti, és a .NET 8 Blazor keretrendszerének része.

QuickGrid egy nagy teljesítményű rácsösszetevő, amely táblázatos formában jeleníti meg az adatokat. QuickGrid az adatok megjelenítésének egyszerű és kényelmes módja, ugyanakkor hatékony funkciókat biztosít, például a rendezést, a szűrést, a lapozást és a virtualizálást.

További információ: ASP.NET Core Blazor `QuickGrid` összetevő.

Útvonal nevesített elemekhez

Blazor mostantól támogatja az ügyféloldali útválasztást a lap adott HTML-elemére való navigáláshoz szabványos URL-töredékekkel. Ha egy HTML-elem azonosítót ad meg a szabványos id attribútummal, akkor Blazor megfelelően görget az elemhez, ha az URL-töredék megegyezik az elemazonosítóval.

További információért lásd a(z) ASP.NET Core Blazor útválasztás és navigációcímű részt.

Alap szintű kaszkádolt értékek

A gyökérszintű kaszkádolt értékek regisztrálhatók a teljes összetevőhierarchiában. A névvel ellátott kaszkádolt értékek és a frissítési értesítésekhez tartozó előfizetések támogatottak.

További információ: ASP.NET Core Blazor kaszkádolt értékek és paraméterek.

Üres tartalom virtualizálása

Használja a EmptyContent összetevő új Virtualize paraméterét a tartalom szolgáltatására, amikor az összetevő betöltődött, és vagy Items üres, vagy ItemsProviderResult<T>.TotalItemCount nulla.

További információért lásd a ASP.NET Core Razor összetevő-virtualizáláscímű részt.

Zárja be az áramköröket, ha nem maradtak interaktív kiszolgálóösszetevők

Az interaktív kiszolgálóösszetevők egy áramkörnek nevezett, valós idejű kapcsolaton keresztül kezelik a webes felhasználói felület eseményeit a böngészővel. Egy áramkör és a hozzá tartozó állapot akkor van beállítva, amikor egy gyökér interaktív kiszolgálóösszetevő renderelésre kerül. A kapcsolatcsoport akkor lesz bezárva, ha a lapon nincsenek további interaktív kiszolgálóösszetevők, ami felszabadítja a kiszolgáló erőforrásait.

SignalR áramkör tevékenységének figyelése

Mostantól a kiszolgálóoldali alkalmazásokban figyelheti a bejövő kör aktivitásokat az új CreateInboundActivityHandler metódus használatával a CircuitHandler. A bejövő körforgalmi tevékenység minden olyan tevékenység, amelyet a böngésző küld a kiszolgálónak, például felhasználói felületi események vagy JavaScript és .NET közötti interoperábilis hívások.

További információ: ASP.NET Core BlazorSignalR útmutató.

Gyorsabb futásidejű teljesítmény a Jiterpreterrel

A Jiterpreter egy új futtatókörnyezeti funkció a .NET 8-ban, amely részleges just-in-time (JIT) fordítást tesz lehetővé a WebAssembly-en való futtatáskor a jobb futásidejű teljesítmény érdekében.

További információ: Gazdagép és üzembe helyezés ASP.NET Core Blazor WebAssembly.

Idő előtti (AOT) SIMD és kivételkezelés

Blazor WebAssembly előre összeállított (AOT) összeállítás mostantól WebAssembly Rögzített szélességű SIMD- és WebAssembly Exception kezelési alapértelmezés szerint a futtatókörnyezet teljesítményének javítása érdekében.

További információkért lásd a következő cikkeket:

Webbarát Webcil csomagolás

A Webcil a .NET-szerelvények webbarát csomagolása, amely eltávolítja a natív Windows-végrehajtásra jellemző tartalmat, hogy elkerülje a problémákat olyan környezetekben való üzembe helyezéskor, amelyek blokkolják .dll fájlok letöltését vagy használatát. A Webcil alapértelmezés szerint engedélyezve van az Blazor WebAssembly alkalmazások számára.

További információ: Gazdagép és üzembe helyezés ASP.NET Core Blazor WebAssembly.

Jegyzet

A .NET 8 kiadása előtt útmutatást talál ASP.NET Core által üzemeltetett Blazor WebAssembly-alkalmazások üzembe helyezési elrendezéséhez, olyan környezeteket kezel, amelyek megakadályozzák az ügyfelek számára a DLL-ek letöltését és végrehajtását többrészes kötegelési megközelítéssel. A .NET 8-ban vagy újabb verziókban Blazor a Webcil fájlformátumot használja a probléma megoldásához. A WebAssembly üzembe helyezési elrendezésről szóló cikkben leírt kísérleti NuGet-csomaggal végzett többrészes összekapcsolás nem támogatott a Blazor alkalmazásokhoz a .NET 8-ban vagy annál újabb verziókban. További információ: Microsoft.AspNetCore.Components.WebAssembly.MultipartBundle csomag továbbfejlesztése egyéni csomagformátum definiálásához (dotnet/aspnetcore #36978). Ha továbbra is használni szeretné a többrészes csomagcsomagot a .NET 8 vagy újabb alkalmazásokban, a cikkben található útmutató segítségével létrehozhatja saját többrészes csomagcsomagját, de a Microsoft nem támogatja.

Blazor WebAssembly hibakeresési fejlesztések

A WebAssembly .NET hibakeresésekor a hibakereső mostantól letölti a szimbólumadatokat a Visual Studio beállításaiban konfigurált szimbólumhelyekről. Ez javítja a NuGet-csomagokat használó alkalmazások hibakeresési élményét.

Mostantól hibakeresést végezhet Blazor WebAssembly alkalmazásokban a Firefox használatával. A Blazor WebAssembly alkalmazások hibakereséséhez konfigurálnia kell a böngészőt a távoli hibakereséshez, majd csatlakoznia kell a böngészőhöz a böngésző fejlesztői eszközeivel a .NET WebAssembly hibakeresési proxyn keresztül. A Firefox Visual Studióból való hibakeresése jelenleg nem támogatott.

További információért lásd: ASP.NET Core hibakeresési Blazor alkalmazások.

Tartalombiztonsági szabályzat (CSP) kompatibilitása

Blazor WebAssembly már nem szükséges engedélyezni a unsafe-eval szkriptforrást tartalombiztonsági szabályzat (CSP) megadásakor.

További információért lásd: Tartalombiztonsági szabályzat kényszerítése ASP.NET Core Blazor.

Az Razor-összetevők életciklusán kívül észlelt kivételek kezelése

Egy ComponentBase.DispatchExceptionAsync-összetevő Razor használva feldolgozhatja az összetevő életciklus-hívásveremén kívül eső kivételeket. Ez lehetővé teszi, hogy az összetevő kódja úgy kezelje a kivételeket, mintha életciklus-metódus kivételei lennének. Ezt követően Blazorhibakezelési mechanizmusai, például a hibahatárok feldolgozhatják a kivételeket.

További információ: ASP.NET Core Blazor-alkalmazások hibáinak kezelése.

A .NET WebAssembly futtatókörnyezet konfigurálása

A .NET WebAssembly futtatókörnyezet mostantól konfigurálható Blazor indításhoz.

További információ: ASP.NET Core Blazor indítási.

Kapcsolati időtúllépések konfigurálása a HubConnectionBuilder

A hubkapcsolat időtúllépések konfigurálására szolgáló korábbi ideiglenes megoldások helyettesíthetők a formális SignalR hubkapcsolat-építő időtúllépési konfigurációval.

További információ:

A projektsablonok elhagyják az Open Iconic-ot.

A Blazor projektsablonok már nem függnek az ikonok szempontjából az Open Iconic-tól.

Párbeszédablak megszakítási és bezárási események támogatása

Blazor mostantól támogatja a cancel HTML-elem close és dialog eseményeit.

Az alábbi példában:

  • OnClose akkor hívjuk meg, ha a my-dialog párbeszédpanel a Bezárás gombbal van bezárva.
  • OnCancel a párbeszédpanel Esc kulccsal történő megszakításakor hívjuk meg. Ha egy HTML-párbeszédpanelt az Esc billentyűvel bezárják, a cancel és a close események is aktiválódnak.
<div>
    <p>Output: @message</p>

    <button onclick="document.getElementById('my-dialog').showModal()">
        Show modal dialog
    </button>

    <dialog id="my-dialog" @onclose="OnClose" @oncancel="OnCancel">
        <p>Hi there!</p>

        <form method="dialog">
            <button>Close</button>
        </form>
    </dialog>
</div>

@code {
    private string? message;

    private void OnClose(EventArgs e) => message += "onclose, ";

    private void OnCancel(EventArgs e) => message += "oncancel, ";
}

Blazor Identity felhasználói felület

támogatja a teljes -alapú felhasználói felület létrehozásának lehetőségét, ha az egyéni fiókokhitelesítési lehetőséget választja. A Visual Studióból származó Blazor Web Appúj projekt párbeszédpanelén kiválaszthatja az egyéni fiókok beállítását, vagy átadhatja a -au|--auth beállítást úgy, hogy Individual legyen a parancssorból egy új projekt létrehozásakor.

További információ:

Védje Blazor WebAssembly-t az ASP.NET Core Identity segítségével

A Blazor dokumentáció egy új cikket és példaalkalmazást tartalmaz, amelyek lefedik, hogyan lehet egy különálló Blazor WebAssembly-alkalmazást biztonságossá tenni az ASP.NET Core Identityhasználatával.

További információ:

Blazor Server Yarp-útválasztással

A Yarp-Blazor Server útválasztása és mély összekapcsolása megfelelően működik a .NET 8-ban.

További információ: Migrálás ASP.NET Core 7.0-ról 8.0-ra.

Kiszolgálóprojektenként több Blazor Web Appelem

Több Blazor Web Apptámogatását is figyelembe veszik szerverprojektenként a .NET 10-hez (2025. november).

További információ: Kiszolgálóprojektenként több Blazor webalkalmazás támogatása (dotnet/aspnetcore #52216).

Blazor Hybrid

Az alábbi cikkek a .NET 8-ban Blazor Hybrid módosításait ismertetik:

[Parameter] attribútumra már nincs szükség, ha a lekérdezési sztringből van megadva

A [Parameter] attribútumra már nincs szükség, ha paramétert ad meg a lekérdezési sztringből:

- [Parameter]
  [SupplyParameterFromQuery]

SignalR

A kiszolgáló időtúllépésének és Keep-Alive időközének beállításának új megközelítése

ServerTimeout (alapértelmezett: 30 másodperc) és KeepAliveInterval (alapértelmezett: 15 másodperc) közvetlenül beállíthatók a HubConnectionBuilder-n.

Előzetes megközelítés JavaScript-ügyfelekhez

Az alábbi példa a Core 7.0-s vagy korábbi verziójá ASP.NET ban az alapértelmezett érték duplájára ható értékek hozzárendelését mutatja be:

var connection = new signalR.HubConnectionBuilder()
  .withUrl("/chatHub")
  .build();

connection.serverTimeoutInMilliseconds = 60000;
connection.keepAliveIntervalInMilliseconds = 30000;

Új megközelítés JavaScript-ügyfelek számára

Az alábbi példa az új megközelítést mutatja be, olyan értékek hozzárendeléséhez, amelyek a Core 8.0 vagy újabb ASP.NET alapértelmezett értékeinek duplái:

var connection = new signalR.HubConnectionBuilder()
  .withUrl("/chatHub")
  .withServerTimeout(60000)
  .withKeepAlive(30000)
  .build();

Egy Blazor Server-alkalmazás JavaScript-kliensének korábbi megközelítése

Az alábbi példa a Core 7.0-s vagy korábbi verziójá ASP.NET ban az alapértelmezett érték duplájára ható értékek hozzárendelését mutatja be:

Blazor.start({
  configureSignalR: function (builder) {
    let c = builder.build();
    c.serverTimeoutInMilliseconds = 60000;
    c.keepAliveIntervalInMilliseconds = 30000;
    builder.build = () => {
      return c;
    };
  }
});

A kiszolgálóoldali Blazor alkalmazás JavaScript-ügyfélének új megközelítése

Az alábbi példában az új megközelítési az ASP.NET Core 8.0-s vagy újabb verziójában az alapértelmezett érték duplájára s és .

Blazor Web App:

Blazor.start({
  circuit: {
    configureSignalR: function (builder) {
      builder.withServerTimeout(60000).withKeepAliveInterval(30000);
    }
  }
});

Blazor Server:

Blazor.start({
  configureSignalR: function (builder) {
    builder.withServerTimeout(60000).withKeepAliveInterval(30000);
  }
});

.NET-ügyfelek előzetes megközelítése

Az alábbi példa a Core 7.0-s vagy korábbi verziójá ASP.NET ban az alapértelmezett érték duplájára ható értékek hozzárendelését mutatja be:

var builder = new HubConnectionBuilder()
    .WithUrl(Navigation.ToAbsoluteUri("/chathub"))
    .Build();

builder.ServerTimeout = TimeSpan.FromSeconds(60);
builder.KeepAliveInterval = TimeSpan.FromSeconds(30);

builder.On<string, string>("ReceiveMessage", (user, message) => ...

await builder.StartAsync();

A .NET-ügyfelek új megközelítése

Az alábbi példa az új megközelítést mutatja be, olyan értékek hozzárendeléséhez, amelyek a Core 8.0 vagy újabb ASP.NET alapértelmezett értékeinek duplái:

var builder = new HubConnectionBuilder()
    .WithUrl(Navigation.ToAbsoluteUri("/chathub"))
    .WithServerTimeout(TimeSpan.FromSeconds(60))
    .WithKeepAliveInterval(TimeSpan.FromSeconds(30))
    .Build();

builder.On<string, string>("ReceiveMessage", (user, message) => ...

await builder.StartAsync();

SignalR állapotalapú újracsatlakozás

SignalR állapotot megőrző újracsatlakozás csökkenti azoknak az ügyfeleknek az érzékelt leállási idejét, akiknek a hálózati kapcsolata átmenetileg megszakad, például hálózati kapcsolatok váltása vagy a hozzáférés rövid ideig tartó elvesztése esetén.

Az állapotalapú újracsatlakozás a következőkkel érhető el:

  • Adatok ideiglenes pufferelése a kiszolgálón és az ügyfélen.
  • A kiszolgáló és az ügyfél által fogadott üzenetek (ACK-ing) elismerése.
  • Annak felismerése, amikor egy kapcsolat helyreáll, és az esetleg addig nem elküldött üzenetek újraküldése.

Az állapotalapú újracsatlakozás a ASP.NET Core 8.0-s és újabb verzióiban érhető el.

Az állapotalapú újracsatlakozás engedélyezése a kiszolgálóközpont végpontján és az ügyfélen egyaránt:

  • Frissítse a kiszolgálóközpont végpontkonfigurációját a AllowStatefulReconnects beállítás engedélyezéséhez:

    app.MapHub<MyHub>("/hubName", options =>
{
    options.AllowStatefulReconnects = true;
});

    Ha szükséges, a kiszolgáló által engedélyezett bájtokban megadott maximális pufferméret globálisan vagy egy adott központhoz is beállítható a StatefulReconnectBufferSize beállítással:

    A StatefulReconnectBufferSize beállítás globálisan be van állítva:

    builder.AddSignalR(o => o.StatefulReconnectBufferSize = 1000);

    Egy adott elosztóhoz beállított StatefulReconnectBufferSize opció:

    builder.AddSignalR().AddHubOptions<MyHub>(o => o.StatefulReconnectBufferSize = 1000);

    A StatefulReconnectBufferSize beállítás nem kötelező, alapértelmezés szerint 100 000 bájt.

  • Frissítse a JavaScript- vagy TypeScript-ügyfélkódot a withStatefulReconnect beállítás engedélyezéséhez:

    const builder = new signalR.HubConnectionBuilder()
  .withUrl("/hubname")
  .withStatefulReconnect({ bufferSize: 1000 });  // Optional, defaults to 100,000
const connection = builder.build();

    A bufferSize beállítás nem kötelező, alapértelmezés szerint 100 000 bájt.

  • Frissítse a .NET-ügyfélkódot a WithStatefulReconnect beállítás engedélyezéséhez:

      var builder = new HubConnectionBuilder()
      .WithUrl("<hub url>")
      .WithStatefulReconnect();
  builder.Services.Configure<HubConnectionOptions>(o => o.StatefulReconnectBufferSize = 1000);
  var hubConnection = builder.Build();

    A StatefulReconnectBufferSize beállítás nem kötelező, alapértelmezés szerint 100 000 bájt.

További információ: Állapotalapú újracsatlakozás konfigurálása.

Minimális API-k

Ez a szakasz a minimális API-k új funkcióit ismerteti. További információkért a minimális API-król tekintse meg a Natív AOT szakaszát .

Felhasználói döntésfelülírási kultúra

Az ASP.NET Core 8.0-tól kezdődően a RequestLocalizationOptions.CultureInfoUseUserOverride tulajdonság lehetővé teszi az alkalmazás számára, hogy eldöntse, használja-e a nem alapértelmezett Windows beállításokat a CultureInfoDateTimeFormat és NumberFormat tulajdonságokhoz. Ez nincs hatással a Linuxra. Ez közvetlenül a UseUserOverridefelel meg.

    app.UseRequestLocalization(options =>
    {
        options.CultureInfoUseUserOverride = false;
    });

Kötés űrlapokhoz

A [FromForm] attribútum használatával történő explicit kapcsolat az űrlap értékekhez mostantól támogatott. Az [FromForm] kéréshez kötött paraméterek között szerepel egy antiforgery token. A kérés feldolgozásakor a rendszer ellenőrzi az antiforgery tokent.

A IFormCollection, IFormFileés IFormFileCollection típusú űrlapokhoz való következtetéses kötés is támogatott. OpenAPI metadatai az űrlapparaméterekhez kapcsolódóan arra szolgálnak, hogy támogassák a Swagger UIintegrációját.

További információ:

Az űrlapok kötése mostantól támogatott a következő módokon:

  • Gyűjtemények, például Lista és Szótár
  • Összetett típusok, például Todo vagy Project

További információ: Gyűjtemények és összetett típusok kötése űrlapokról.

Hamisítás elleni védelem minimális API-kkal

Ez a kiadás hozzáad egy köztesréteget az antiforgery tokenek érvényesítéséhez, amelyek a webhelyek közti kéréshamisítási támadások megelőzésére szolgálnak. Hívja AddAntiforgery az antiforgery-szolgáltatások di-ben való regisztrálásához. WebApplicationBuilder automatikusan hozzáadja a köztes szoftvereket, amikor az antiforgery szolgáltatásokat regisztrálták a DI-tárolóban. Az antiforgery tokenek helyek közötti hamisítási támadásokmérséklésére szolgálnak.

var builder = WebApplication.CreateBuilder();

builder.Services.AddAntiforgery();

var app = builder.Build();

app.UseAntiforgery();

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

app.Run();

Az antiforgery köztes szoftver:

Az antiforgery token csak akkor érvényes, ha:

  • A végpont olyan metaadatokat tartalmaz, amelyek IAntiforgeryMetadata, ahol RequiresValidation=true.
  • A végponthoz társított HTTP-metódus egy releváns HTTP-metódus. A vonatkozó metódusok mind HTTP-metódusok, kivéve a TRACE, a OPTIONS, a HEAD és a GET metódusokat.
  • A kérés egy érvényes végponthoz van társítva.

További információ: Antiforgery minimális API-kkal.

Új IResettable felület ObjectPool-ban/ben

Microsoft.Extensions.ObjectPool támogatja az objektumpéldányok készletezését a memóriában. Az alkalmazások akkor használhatnak objektumkészletet, ha az értékek lefoglalása vagy inicializálása költséges.

Ebben a kiadásban egyszerűbbé tettük az objektumkészlet használatát a IResettable felület hozzáadásával. Az újrahasználható típusokat gyakran vissza kell állítani az alapértelmezett állapotba a felhasználások között. IResettable típusok automatikusan alaphelyzetbe állnak egy objektumkészletbe való visszatéréskor.

További információ: ObjectPool-minta.

Natív AOT

Az .NET natív előzetes (AOT) támogatása hozzáadva. Az AOT használatával közzétett alkalmazások teljesítménye lényegesen jobb lehet: kisebb alkalmazásméret, kevesebb memóriahasználat és gyorsabb indítási idő. A natív AOT-t jelenleg a gRPC, a minimális API és a feldolgozói szolgáltatásalkalmazások támogatják. További információért lásd: ASP.NET Core támogatás natív AOT-hoz és oktatóanyag: ASP.NET Core alkalmazás közzététele natív AOT használatával. A ASP.NET Core és a Natív AOT kompatibilitásával kapcsolatos ismert problémákról a GitHub dotnet/core #8288című témakörben talál további információt.

Kódtárak és natív AOT

Az ASP.NET Core-projektekben használt népszerű kódtárak közül számos jelenleg kompatibilitási problémákat tapasztal, ha natív AOT-t célzó projektben használják, például:

  • Tükröződés használata típusok vizsgálatára és felderítésére.
  • Kódtárak feltételes betöltése futásidőben.
  • Kód generálása menet közben a funkciók implementálásához.

A natív AOT használatához frissíteni kell az ezeket a dinamikus funkciókat használó kódtárakat. Ezek olyan eszközökkel frissíthetők, mint a Roslyn-forrásgenerátorok.

A Natív AOT támogatására törekvő könyvtárszerzőket arra biztatjuk, hogy:

Új projektsablon

Az új ASP.NET Core Web API (natív AOT) projektsablon (rövid neve webapiaot) egy projektet hoz létre az AOT-közzététel engedélyezésével. További információ: A webes API (natív AOT) sablon.

Új CreateSlimBuilder metódus

A Webes API (natív AOT) sablonban használt CreateSlimBuilder() metódus inicializálja a WebApplicationBuilder az alkalmazás futtatásához szükséges minimális ASP.NET Core-funkciókkal. A CreateSlimBuilder módszer a következő funkciókat tartalmazza, amelyek általában szükségesek a hatékony fejlesztési élményhez:

  • A appsettings.json és appsettings.{EnvironmentName}.jsonJSON-fájlok konfigurációja.
  • Felhasználói titkos kódok konfigurálása.
  • Konzolnaplózás.
  • Naplózási konfiguráció.

További információ: A CreateSlimBuilder metódus.

Új CreateEmptyBuilder metódus

Van egy másik új WebApplicationBuilder gyári módszer a csak a szükséges funkciókat tartalmazó kis alkalmazások létrehozásához: WebApplication.CreateEmptyBuilder(WebApplicationOptions options). Ez a WebApplicationBuilder beépített viselkedés nélkül jön létre. Az általa létrehozott alkalmazás csak a kifejezetten konfigurált szolgáltatásokat és köztes szoftvereket tartalmazza.

Íme egy példa arra, hogy az API-t használva hozzon létre egy kis webalkalmazást:

var builder = WebApplication.CreateEmptyBuilder(new WebApplicationOptions());
builder.WebHost.UseKestrelCore();

var app = builder.Build();

app.Use(async (context, next) =>
{
    await context.Response.WriteAsync("Hello, World!");
    await next(context);
});

Console.WriteLine("Running...");
app.Run();

Ha a kódot natív AOT-val teszi közzé a .NET 8 Preview 7 használatával linuxos x64-es gépen, az körülbelül 8,5 MB-os, önálló natív végrehajthatósághoz vezet.

Csökkentett alkalmazásméret konfigurálható HTTPS-támogatással

Tovább csökkentettük a Natív AOT bináris méretét olyan alkalmazások esetében, amelyekhez nincs szükség HTTPS- vagy HTTP/3-támogatásra. A HTTPS vagy a HTTP/3 használatának mellőzése gyakori a TLS-leállítási proxy mögött futó alkalmazások esetében (például az Azure-ban). Az új WebApplication.CreateSlimBuilder metódus alapértelmezés szerint kihagyja ezt a funkciót. A builder.WebHost.UseKestrelHttpsConfiguration() hívásával lehet hozzáadni HTTPS-hez, vagy a builder.WebHost.UseQuic() hívásával HTTP/3-hoz. További információ: A CreateSlimBuilder metódus.

A fordító által létrehozott IAsyncEnumerable<T> típusok JSON-szerializálása

Új funkciókat adtak hozzá a System.Text.Json-hoz a natív AOT jobb támogatásához. Ezek az új funkciók a System.Text.Jsonforrásgenerálási módjához nyújtanak képességeket, mivel az AOT nem támogatja a tükröződést.

Az egyik új funkció a C#-fordító által implementált IAsyncEnumerable<T> implementációk JSON-szerializálásának támogatása. Ez a támogatás megnyitja a natív AOT közzétételére konfigurált ASP.NET Core-projektek használatát.

Ez az API olyan esetekben hasznos, amikor egy útvonalkezelő yield return használ az enumerálás aszinkron visszaadásához. Például egy adatbázis-lekérdezés sorainak materializálása. További információért lásd a .NET 8 Preview 4 bejelentésében a kimondhatatlan típustámogatás részt.

A System.Text.Json forráslétrehozás egyéb fejlesztéseiről további információkért lásd a .NET 8szerializációs fejlesztéseket.

A vágási figyelmeztetésekhez jegyzetelt legfelső szintű API-k

A fő belépési pontjai mostantól fel vannak jegyezve az alrendszerekhez, amelyek nem működnek megbízhatóan a Native AOT-val. Ha a rendszer meghívja ezeket a metódusokat egy natív AOT-kompatibilis alkalmazásból, figyelmeztetés jelenik meg. A következő kód például figyelmeztetést ad AddControllers meghívására, mivel ez az API nem biztonságos, és a natív AOT nem támogatja.

Visual Studio ablakában il2026 figyelmeztető üzenet jelenik meg az AddControllers metóduson, amely szerint az MVC jelenleg nem támogatja a natív AOT-t.

Delegálási generátor kérése

Annak érdekében, hogy a minimális API-k kompatibilisek legyenek a natív AOT-jal, bevezetjük a Kérelemdelegált generátort (RDG). Az RDG egy forrásgenerátor, amely azt teszi, amit a RequestDelegateFactory (RDF) csinál. Azaz, a különböző MapGet(), MapPost()és a hozzájuk hasonló hívásokat a megadott útvonalakhoz társított RequestDelegate példányokká alakítja. Az RDG azonban ahelyett, hogy az alkalmazás indításakor végezné ezt a memóriában, fordítási időben végzi el, és közvetlenül a projektbe generálja a C#-kódot. Az RDG:

  • Eltávolítja a kód futtatókörnyezeti generációját.
  • Biztosítja, hogy az API-kban használt típusok statikusan elemezhetők legyenek a Natív AOT eszközlánc által.
  • Biztosítja, hogy a szükséges kód ne kerüljön eltávolításra.

Dolgozunk azon, hogy az RDG a lehető legtöbb minimális API-funkciót támogassa, és így kompatibilis legyen a natív AOT-jal.

Az RDG automatikusan engedélyeződik egy projektben, amikor a natív AOT-közzététel engedélyezve van. Az RDG manuálisan is engedélyezhető, még akkor is, ha nem használja a natív AOT-t a projektfájlban <EnableRequestDelegateGenerator>true</EnableRequestDelegateGenerator> beállításával. Ez akkor lehet hasznos, ha először kiértékeli a projekt natív AOT-ra való felkészültségét, vagy csökkenti egy alkalmazás indítási idejét.

Jobb teljesítmény a Interceptorok használatával

A Kérelemdelegálási generátor az új C# 12 interceptors fordítófunkcióval támogatja a minimális API-térképezési metódusok hívásainak elfogását a futási időben statikusan generált változatokkal. Az elfogók használata megnöveli a PublishAotáltal lefordított alkalmazások indítási sebességét.

Naplózás és kivételkezelés fordítási időben létrehozott minimális API-kban

A futtatáskor létrehozott minimális API-k támogatják az automatikus naplózást (vagy kivételeket dobnak ki a fejlesztői környezetekben), ha a paraméterkötés meghiúsul. A .NET 8 ugyanazt a támogatást nyújtja a fordításkor létrehozott API-khoz a Delegált generátor (RDG) segítségével. További információért lásd a Naplózás és kivételkezelés a fordítási időben létrehozott minimális API-kban.

AOT és System.Text.Json

A minimális API-k JSON-hasznos adatok fogadására és visszaadására vannak optimalizálva System.Text.Jsonhasználatával, így a JSON és a natív AOT kompatibilitási követelményei is érvényesek. A natív AOT-kompatibilitáshoz szükség van a System.Text.Json forrásgenerátor használatára. A minimális API-kban a kérelmek delegáltjaihoz paraméterként elfogadott vagy visszaadott összes típust olyan JsonSerializerContext kell konfigurálni, amely a ASP.NET Core függőséginjektálásán keresztül van regisztrálva, például:

// Register the JSON serializer context with DI
builder.Services.ConfigureHttpJsonOptions(options =>
{
    options.SerializerOptions.TypeInfoResolverChain.Insert(0, AppJsonSerializerContext.Default);
});

...

// Add types used in the minimal API app to source generated JSON serializer content
[JsonSerializable(typeof(Todo[]))]
internal partial class AppJsonSerializerContext : JsonSerializerContext
{

}

Az TypeInfoResolverChain API-val kapcsolatos további információkért tekintse meg a következő erőforrásokat:

Kódtárak és natív AOT

Az ASP.NET Core-projektekhez jelenleg elérhető gyakori kódtárak közül sok kompatibilitási problémát tapasztal, ha a natív AOT-t célzó projektben használják. A népszerű kódtárak gyakran támaszkodnak a .NET-tükröződés dinamikus képességeire a típusok vizsgálatára és felderítésére, a kódtárak futásidőben való feltételes betöltésére, valamint a funkciók implementálásához szükséges kód generálására. Ezeket a kódtárakat frissíteni kell a natív AOT használatához olyan eszközök használatával, mint a Roslyn-forrásgenerátorok.

A kódtárak natív AOT-ra való előkészítésével kapcsolatos további ismereteket kívánó könyvtárszerzőknek javasoljuk, hogy először készítsék elő a kódtárukat a vágására, és jobban megismerjék a natív AOT-kompatibilitási követelmények.

Kestrel és HTTP.sys kiszolgálók

A Kestrel és HTTP.sysszámos új funkcióval rendelkezik.

Támogatás elnevezett csövekhez a Kestrel-ban

A nevesített csövek népszerű technológia a Windows-alkalmazások közötti folyamatközi kommunikáció (IPC) kiépítéséhez. Most már létrehozhat egy IPC-kiszolgálót .NET, Kestrelés nevesített csövek használatával.

var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
    serverOptions.ListenNamedPipe("MyPipeName");
});

Erről a funkcióról, valamint az IPC-kiszolgáló és -ügyfél létrehozásához a .NET és a gRPC használatával kapcsolatos további információkért lásd gRPCfolyamatközi kommunikációját.

A nevesített csövek szállításának teljesítménybeli fejlesztései

Javítottuk a nevesített csőkapcsolat teljesítményét. Kestrelnevű csőátvitele mostantól párhuzamosan fogadja a kapcsolatokat, és újrafelhasználja a NamedPipeServerStream példányokat.

100 000 kapcsolat létrehozásának ideje:

  • Előtte: 5,916 másodperc
  • Utána: 2,374 másodperc

HTTP/2 tLS-en keresztüli (HTTPS) támogatás macOS rendszeren Kestrel

A .NET 8 támogatja a Application-Layer Protocol Negotiation (ALPN) használatát a macOS-hez. Az ALPN egy TLS-funkció, amellyel egyeztethető, hogy melyik HTTP-protokollt használja a kapcsolat. Az ALPN például lehetővé teszi, hogy a böngészők és más HTTP-ügyfelek HTTP/2 kapcsolatot kérjenek. Ez a funkció különösen hasznos a HTTP/2-t igénylő gRPC-alkalmazások esetében. További információ: HTTP/2 használata a ASP.NET Core Kestrel webkiszolgálóval.

Tanúsítványfájl figyelése a Kestrel helyen

A elérési útján konfigurált TLS-tanúsítványok mostantól figyelik a való átadásakor bekövetkező változásokat. A tanúsítványfájl módosítása ugyanúgy történik, mint a konfigurált elérési út módosítása (vagyis a végpontok újratöltődnek).

Vegye figyelembe, hogy a fájltörlések nincsenek nyomon követve, mivel átmenetiek, és ha nem átmenetiek, összeomlanak a kiszolgáló.

Figyelmeztetés, ha a megadott HTTP-protokollok nem lesznek használatban

Ha a TLS le van tiltva, és a HTTP/1.x elérhető, akkor a HTTP/2 és a HTTP/3 akkor is le lesz tiltva, ha már meg van adva. Ez csúnya meglepetéseket okozhat, ezért figyelmeztető kimenetet adtunk hozzá, hogy tudassa, mikor történik.

HTTP_PORTS és HTTPS_PORTS konfigurációs kulcsok

Az alkalmazások és tárolók gyakran csak egy, például a 80-as, figyelő portot kapnak, további korlátozások, mint a hoszt vagy az elérési út nélkül. HTTP_PORTS és HTTPS_PORTS új konfigurációs kulcsok, amelyek lehetővé teszik a figyelési portok megadását a Kestrel és HTTP.sys kiszolgálókhoz. Ezek definiálhatók a DOTNET_ vagy ASPNETCORE_ környezeti változó előtagokkal, vagy közvetlenül bármely más konfigurációs bemeneten, például appsettings.json. Mindegyik a portértékek pontosvesszővel tagolt listája. Például:

ASPNETCORE_HTTP_PORTS=80;8080
ASPNETCORE_HTTPS_PORTS=443;8081

Ez a következő rövidítés, amely meghatározza a sémát (HTTP vagy HTTPS), valamint bármely gazdagépet vagy IP-címet:

ASPNETCORE_URLS=http://*:80/;http://*:8080/;https://*:443/;https://*:8081/

További információ: Végpontok konfigurálása a ASP.NET Core Kestrel-webkiszolgáló és HTTP.sys webkiszolgáló-implementációhoz ASP.NET Core.

SNI házigazda neve az ITlsHandshakeFeature-ben

Mostantól a Szervernév jelzés (SNI) hosztneve megjelenik a felület ITlsHandshakeFeature tulajdonságában.

Az SNI a TLS kézfogási folyamat része. Lehetővé teszi az ügyfelek számára, hogy megadják azt a gazdagépnevet, amelyhez csatlakozni próbálnak, ha a kiszolgáló több virtuális gazdagépet vagy tartományt üzemeltet. A kézfogási folyamat során a megfelelő biztonsági tanúsítvány bemutatásához a kiszolgálónak tudnia kell az egyes kérésekhez kiválasztott gazdagépnevet.

A hosztnév általában csak a TLS-verem környezetében van kezelve, és a megfelelő tanúsítvány kiválasztására szolgál. Az alkalmazás más összetevői azonban felhasználhatják ezeket az információkat olyan célokra, mint a diagnosztika, a sebességkorlátozás, az útválasztás és a számlázás.

Nagy léptékű szolgáltatások esetében, amelyek több ezer SNI-kötést kezelnek, hasznos lehet a gazdagép nevének megmutatása. Ez a funkció jelentősen javíthatja a hibakeresés hatékonyságát az ügyfelek eszkalációi során. A nagyobb átláthatóság gyorsabb problémamegoldást és fokozott szolgáltatás-megbízhatóságot tesz lehetővé.

További információ: ITlsHandshakeFeature.HostName.

IHttpSysRequestTimingFeature

[IHttpSysRequestTimingFeature](https://source.dot.net/#Microsoft.AspNetCore.Server.HttpSys/IHttpSysRequestTimingFeature.cs,3c5dc86dc837b1f4) részletes időzítési információkat nyújt a [HTTP.sys kiszolgáló](xref:fundamentals/servers/httpsys) és [Folyamaton belüli üzemeltetés az IIS-sel](xref:host-and-deploy/iis/in-process-hosting?view=aspnetcore-8.0&preserve-view=true#ihsrtf8): [IHttpSysRequestTimingFeature.TryGetTimestamp](https://source.dot.net/#Microsoft.AspNetCore.Server.HttpSys/IHttpSysRequestTimingFeature.cs,3c5dc86dc837b1f4) lekéri a megadott időzítéstípus időbélyegét: 
using Microsoft.AspNetCore.Http.Features;
using Microsoft.AspNetCore.Server.HttpSys;
var builder = WebApplication.CreateBuilder(args);

builder.WebHost.UseHttpSys();

var app = builder.Build();

app.Use((context, next) =>
{
    var feature = context.Features.GetRequiredFeature<IHttpSysRequestTimingFeature>();

    var loggerFactory = context.RequestServices.GetRequiredService<ILoggerFactory>();
    var logger = loggerFactory.CreateLogger("Sample");

    var timingType = HttpSysRequestTimingType.RequestRoutingEnd;

    if (feature.TryGetTimestamp(timingType, out var timestamp))
    {
        logger.LogInformation("Timestamp {timingType}: {timestamp}",
                                          timingType, timestamp);
    }
    else
    {
        logger.LogInformation("Timestamp {timingType}: not available for the "
                                           + "current request",    timingType);
    }

    return next(context);
});

app.MapGet("/", () => Results.Ok());

app.Run();

További információ: Részletes időzítési információk lekérése az IHttpSysRequestTimingFeature segítségével és idõzítési információk, valamint a folyamaton belüli üzemeltetés az IIS-sel együtt.

HTTP.sys: a kernel módú válaszpufferezés választható támogatása

Bizonyos esetekben a kis méretű írások nagy mennyisége és magas késése jelentős hatást gyakorolhat a teljesítményre HTTP.sys-n. Ennek a hatásnak az az oka, hogy a Pipe implementációban nincs HTTP.sys puffer. Az ilyen forgatókönyvek teljesítményének javítása érdekében a válaszpufferezés támogatásának hozzáadása történt a HTTP.sys-ban. A pufferelés engedélyezéséhez állítsa be a HttpSysOptions.EnableKernelResponseBuffering opciót trueértékre.

A válaszpufferezést olyan alkalmazásnak kell engedélyeznie, amely szinkron I/O-t vagy aszinkron I/O-t végez, és egyszerre legfeljebb egy folyamatban lévő írási művelettel rendelkezik. Ezekben a forgatókönyvekben a válaszpufferelés jelentősen javíthatja a nagy késésű kapcsolatok átviteli sebességét.

Az aszinkron I/O-t használó és egyszerre több írási függőben lévő alkalmazásnak nem használni ezt a jelzőt. A jelző engedélyezése magasabb processzor- és memóriahasználatot eredményezhet a HTTP.Sys számára.

Hitelesítés és engedélyezés

ASP.NET Core 8 új funkciókat ad hozzá a hitelesítéshez és az engedélyezéshez.

Identity API-végpontok

MapIdentityApi<TUser> egy új bővítménymetódus, amely két API-végpontot (/register és /login) ad hozzá. A MapIdentityApi fő célja, hogy megkönnyítse a fejlesztők számára az ASP.NET Core Identity használatát a JavaScript-alapú egyoldalas alkalmazásokban (SPA) vagy Blazor alkalmazásokban való hitelesítéshez. A ASP.NET Core Identityáltal biztosított alapértelmezett felhasználói felület használata helyett, amely Razor Oldalakra épül, a MapIdentityApi olyan JSON API-végpontokat ad hozzá, amelyek jobban megfelelnek az SPA-alkalmazásoknak és a nem-rowser-alkalmazásoknak. További információ: Identity API-végpontok.

IAuthorizationRequirementData

ASP.NET Core 8 előtt, egy paraméterezett engedélyezési szabályzat hozzáadása egy végponthoz megkövetelte az implementálást.

  • AuthorizeAttribute minden irányelvhez.
  • AuthorizationPolicyProvider egyéni szabályzat feldolgozása egy szöveg alapú szerződésből.
  • AuthorizationRequirement a szabályzat számára.
  • AuthorizationHandler minden egyes követelményhez.

Vegyük például a ASP.NET Core 7.0-hoz írt alábbi mintát:

using AuthRequirementsData.Authorization;
using Microsoft.AspNetCore.Authorization;

var builder = WebApplication.CreateBuilder();

builder.Services.AddAuthentication().AddJwtBearer();
builder.Services.AddAuthorization();
builder.Services.AddControllers();
builder.Services.AddSingleton<IAuthorizationPolicyProvider, MinimumAgePolicyProvider>();
builder.Services.AddSingleton<IAuthorizationHandler, MinimumAgeAuthorizationHandler>();

var app = builder.Build();

app.MapControllers();

app.Run();

using Microsoft.AspNetCore.Mvc;

namespace AuthRequirementsData.Controllers;

[ApiController]
[Route("api/[controller]")]
public class GreetingsController : Controller
{
    [MinimumAgeAuthorize(16)]
    [HttpGet("hello")]
    public string Hello() => $"Hello {(HttpContext.User.Identity?.Name ?? "world")}!";
}

using Microsoft.AspNetCore.Authorization;
using System.Globalization;
using System.Security.Claims;

namespace AuthRequirementsData.Authorization;

class MinimumAgeAuthorizationHandler : AuthorizationHandler<MinimumAgeRequirement>
{
    private readonly ILogger<MinimumAgeAuthorizationHandler> _logger;

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

    // Check whether a given MinimumAgeRequirement is satisfied or not for a particular
    // context.
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,
                                               MinimumAgeRequirement requirement)
    {
        // Log as a warning so that it's very clear in sample output which authorization
        // policies(and requirements/handlers) are in use.
        _logger.LogWarning("Evaluating authorization requirement for age >= {age}",
                                                                    requirement.Age);

        // Check the user's age
        var dateOfBirthClaim = context.User.FindFirst(c => c.Type ==
                                                                 ClaimTypes.DateOfBirth);
        if (dateOfBirthClaim != null)
        {
            // If the user has a date of birth claim, check their age
            var dateOfBirth = Convert.ToDateTime(dateOfBirthClaim.Value, CultureInfo.InvariantCulture);
            var age = DateTime.Now.Year - dateOfBirth.Year;
            if (dateOfBirth > DateTime.Now.AddYears(-age))
            {
                // Adjust age if the user hasn't had a birthday yet this year.
                age--;
            }

            // If the user meets the age criterion, mark the authorization requirement
            // succeeded.
            if (age >= requirement.Age)
            {
                _logger.LogInformation("Minimum age authorization requirement {age} satisfied",
                                         requirement.Age);
                context.Succeed(requirement);
            }
            else
            {
                _logger.LogInformation("Current user's DateOfBirth claim ({dateOfBirth})" +
                    " does not satisfy the minimum age authorization requirement {age}",
                    dateOfBirthClaim.Value,
                    requirement.Age);
            }
        }
        else
        {
            _logger.LogInformation("No DateOfBirth claim present");
        }

        return Task.CompletedTask;
    }
}

A teljes minta itt az AspNetCore.Docs.Samples adattárban.

ASP.NET Core 8 bevezeti a IAuthorizationRequirementData felületet. A IAuthorizationRequirementData felület lehetővé teszi az attribútumdefiníció számára az engedélyezési szabályzathoz társított követelmények megadását. A IAuthorizationRequirementDatahasználatával az előző egyéni engedélyezési szabályzatkód kevesebb sornyi kóddal írható. A frissített Program.cs fájl:

  using AuthRequirementsData.Authorization;
  using Microsoft.AspNetCore.Authorization;
  
  var builder = WebApplication.CreateBuilder();
  
  builder.Services.AddAuthentication().AddJwtBearer();
  builder.Services.AddAuthorization();
  builder.Services.AddControllers();
- builder.Services.AddSingleton<IAuthorizationPolicyProvider, MinimumAgePolicyProvider>();
  builder.Services.AddSingleton<IAuthorizationHandler, MinimumAgeAuthorizationHandler>();
  
  var app = builder.Build();
  
  app.MapControllers();
  
  app.Run();

A frissített MinimumAgeAuthorizationHandler:

using Microsoft.AspNetCore.Authorization;
using System.Globalization;
using System.Security.Claims;

namespace AuthRequirementsData.Authorization;

- class MinimumAgeAuthorizationHandler : AuthorizationHandler<MinimumAgeRequirement>
+ class MinimumAgeAuthorizationHandler : AuthorizationHandler<MinimumAgeAuthorizeAttribute>
{
    private readonly ILogger<MinimumAgeAuthorizationHandler> _logger;

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

    // Check whether a given MinimumAgeRequirement is satisfied or not for a particular
    // context
    protected override Task HandleRequirementAsync(AuthorizationHandlerContext context,
-                                              MinimumAgeRequirement requirement)
+                                              MinimumAgeAuthorizeAttribute requirement)
    {
        // Remaining code omitted for brevity.

A teljes frissített minta itt található.

Az új minta részletes vizsgálatához tekintse meg egyéni engedélyezési szabályzatokat az IAuthorizationRequirementData használatával.

Swagger felhasználói felületi végpontok védelme

A Swagger felhasználói felületi végpontjai mostantól éles környezetben is védhetők MapSwagger().RequireAuthorizationmeghívásával. További információ: Swagger felhasználói felületi végpontok biztonságossá tétele

Vegyes

Az alábbi szakaszok a ASP.NET Core 8 különböző új funkcióit ismertetik.

Kulcsalapú szolgáltatások támogatása a Dependency Injection-ben

kulcsos szolgáltatások a függőséginjektálási (DI-) szolgáltatások kulcsokkal történő regisztrálására és lekérésére szolgáló mechanizmusra utal. A szolgáltatás egy kulccsal van társítva a AddKeyedSingleton (vagy AddKeyedScoped vagy AddKeyedTransient) hívásával a regisztrációhoz. Egy regisztrált szolgáltatás eléréséhez adja meg a kulcsot a [FromKeyedServices] attribútummal. A következő kód a kulcsos szolgáltatások használatát mutatja be:

using Microsoft.AspNetCore.Mvc;
using Microsoft.AspNetCore.SignalR;

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddKeyedSingleton<ICache, BigCache>("big");
builder.Services.AddKeyedSingleton<ICache, SmallCache>("small");
builder.Services.AddControllers();

var app = builder.Build();

app.MapGet("/big", ([FromKeyedServices("big")] ICache bigCache) => bigCache.Get("date"));
app.MapGet("/small", ([FromKeyedServices("small")] ICache smallCache) =>
                                                               smallCache.Get("date"));

app.MapControllers();

app.Run();

public interface ICache
{
    object Get(string key);
}
public class BigCache : ICache
{
    public object Get(string key) => $"Resolving {key} from big cache.";
}

public class SmallCache : ICache
{
    public object Get(string key) => $"Resolving {key} from small cache.";
}

[ApiController]
[Route("/cache")]
public class CustomServicesApiController : Controller
{
    [HttpGet("big-cache")]
    public ActionResult<object> GetOk([FromKeyedServices("big")] ICache cache)
    {
        return cache.Get("data-mvc");
    }
}

public class MyHub : Hub
{
    public void Method([FromKeyedServices("small")] ICache cache)
    {
        Console.WriteLine(cache.Get("signalr"));
    }
}

Visual Studio-projektsablonok SPA-alkalmazásokhoz ASP.NET Core háttérrendszerrel

A Visual Studio projektsablonjai mostantól ajánlottak egyoldalas alkalmazások (SLA-k) létrehozására, amelyek ASP.NET Core-háttérrendszert használnak. Olyan sablonokat biztosítunk, amelyek a JavaScript-keretrendszerek Angular, Reactés Vuealapján hoznak létre alkalmazásokat. Ezek a sablonok:

  • Hozzon létre egy Visual Studio-megoldást egy előtérbeli projekttel és egy háttérprojekttel.
  • Használja a Visual Studio projekttípust JavaScripthez és TypeScripthez (.esproj) az előtérben.
  • Használjon egy ASP.NET Core-projektet a háttérrendszerhez.

A Visual Studio-sablonokról és az örökölt sablonok eléréséről további információért lásd: Az egyoldalas alkalmazások (SPA-k) áttekintése az ASP.NET Core-ban

Általános attribútumok támogatása

A korábban Type paramétert igénylő attribútumok mostantól tisztább általános változatokban érhetők el. Ezt a C# 11-ben általános attribútumok támogatása teszi lehetővé. Egy művelet választípusának megjegyzéseinek szintaxisa például az alábbiak szerint módosítható:

[ApiController]
[Route("api/[controller]")]
public class TodosController : Controller
{
  [HttpGet("/")]
- [ProducesResponseType(typeof(Todo), StatusCodes.Status200OK)]
+ [ProducesResponseType<Todo>(StatusCodes.Status200OK)]
  public Todo Get() => new Todo(1, "Write a sample", DateTime.Now, false);
}

Az általános változatok a következő attribútumokhoz támogatottak:

  • [ProducesResponseType<T>]
  • [Produces<T>]
  • [MiddlewareFilter<T>]
  • [ModelBinder<T>]
  • [ModelMetadataType<T>]
  • [ServiceFilter<T>]
  • [TypeFilter<T>]

Kódelemzés ASP.NET Core-alkalmazásokban

Az alábbi táblázatban látható új elemzők a ASP.NET Core 8.0-ban érhetők el.

Diagnosztikai azonosító Törés vagy nem törés Leírás
ASP0016 Nem törhető Ne adjon vissza értéket a RequestDelegate-ből
ASP0019 Nem törhető Javaslat az IHeaderDictionary.Append vagy az indexelő használatára
ASP0020 Nem törhető Az útvonalparaméterek által hivatkozott összetett típusoknak elemezhetőnek kell lenniük
ASP0021 Nem törhető A BindAsync metódus visszatérési típusának ValueTask<T> kell lennie.
ASP0022 Nem törhető Útvonalütközés észlelhető az útvonalkezelők között
ASP0023 Nem törhető MVC: Útvonalütközés észlelhető az útvonalkezelők között
ASP0024 Nem törhető Az útvonalkezelő több paraméterrel rendelkezik a [FromBody] attribútummal
ASP0025 Nem törhető Az AddAuthorizationBuilder használata

Útvonalkezelő eszköz

ASP.NET Core az útválasztásra épül. Minimális API-k, webes API-k, Razor lapok és Blazor mind útvonalakat használnak, hogy testre szabják, hogyan képezik le a HTTP-kéréseket kódra.

A .NET 8-ban új funkciókkal ruháztuk fel az útválasztást a tanulás és a használat megkönnyítése érdekében. Ezek az új funkciók a következők:

További információ: Útválasztás eszközkészlet a .NET 8-ban.

alapvető metrikák ASP.NET

A metrikák az idő függvényében jelentett mérések, és leggyakrabban egy alkalmazás állapotának figyelésére és riasztások létrehozására szolgálnak. Például egy számláló, amely a sikertelen HTTP-kéréseket jelenti, megjeleníthető az irányítópultokon, vagy riasztásokat hozhat létre, ha a hibák átlépnek egy küszöbértéket.

Ez az előzetes verzió új metrikákat ad hozzá ASP.NET Core-ban System.Diagnostics.Metricshasználatával. A Metrics egy modern API az alkalmazásokról való jelentéskészítéshez és információk gyűjtéséhez.

A metrikák számos fejlesztést kínálnak a meglévő eseményszámlálókhoz képest:

  • Új típusú mérések számlálókkal, mérőműszerekkel és hisztogramokkal.
  • Hatékony jelentéskészítés többdimenziós értékekkel.
  • Integráció a tágabb felhőbeli natív ökoszisztémába az OpenTelemetry szabványokkal összhangban.

Metrikák lettek hozzáadva ASP.NET Core-üzemeltetéshez, Kestrelés SignalR. További információért lásd: System.Diagnostics.Metrics.

IExceptionHandler

IExceptionHandler egy új felület, amely visszahívást biztosít a fejlesztőnek az ismert kivételek központi helyen való kezelésére.

IExceptionHandler implementációkat a IServiceCollection.AddExceptionHandler<T>meghívásával regisztrálják. Több implementáció is hozzáadható, és a rendszer a regisztrált sorrendben hívja meg őket. Ha egy kivételkezelő kezeli a kéréseket, true adhat vissza a feldolgozás leállításához. Ha egy kivételt egyetlen kivételkezelő sem kezel, akkor a vezérlés visszaesik a köztes szoftver alapértelmezett viselkedésére és beállításaira.

További információ: IExceptionHandler.

Továbbfejlesztett hibakeresési élmény

Hibakeresési testreszabási attribútumok lettek hozzáadva olyan típusokhoz, mint a HttpContext, HttpRequest, HttpResponse, ClaimsPrincipalés WebApplication. Az ilyen típusú továbbfejlesztett hibakeresők megkönnyítik a fontos információk keresését az IDE-hibakeresőben. Az alábbi képernyőképek azt a különbséget jelenítik meg, amelyet ezek az attribútumok a HttpContexthibakeresőbeli megjelenítésében okoznak.

.NET 7:

HttpContext típusú nem hasznos hibakereső megjelenítése a .NET 7-ben.

.NET 8:

HttpContext típusú hibakereső hasznos megjelenítése a .NET 8-ban.

Az WebApplication hibakeresője fontos információkat emel ki, például konfigurált végpontokat, köztes szoftvereket és IConfiguration értékeket.

.NET 7:

A WebApplication típus haszontalan hibakereső megjelenítése a .NET 7-ben.

.NET 8:

A WebApplication típusának hasznos hibakeresői megjelenítése a .NET 8-ban.

A .NET 8 hibakeresési fejlesztéseiről a következő témakörben talál további információt:

IPNetwork.Parse és TryParse

A Parse új TryParse és IPNetwork metódusai támogatják a IPNetwork létrehozását egy bemeneti sztring használatával CIDR-jelölési vagy "perjeljelezés" használatával.

IPv4-példák:

// Using Parse
var network = IPNetwork.Parse("192.168.0.1/32");

// Using TryParse
bool success = IPNetwork.TryParse("192.168.0.1/32", out var network);

// Constructor equivalent
var network = new IPNetwork(IPAddress.Parse("192.168.0.1"), 32);

Példák az IPv6-ra:

// Using Parse
var network = IPNetwork.Parse("2001:db8:3c4d::1/128");

// Using TryParse
bool success = IPNetwork.TryParse("2001:db8:3c4d::1/128", out var network);

// Constructor equivalent
var network = new IPNetwork(IPAddress.Parse("2001:db8:3c4d::1"), 128);

Redis-alapú output cache-elés

ASP.NET Core 8 támogatja a Redis elosztott gyorsítótárként való használatát a kimeneti gyorsítótárazáshoz. A kimeneti gyorsítótárazás olyan funkció, amely lehetővé teszi, hogy az alkalmazás gyorsítótárazza egy minimális API-végpont, vezérlőművelet vagy Razor oldal kimenetét. További információkért lásd: kimeneti gyorsítótárazás.

Rövidzárlatú köztes szoftver útválasztás után

Amikor az útválasztás megfelel egy végpontnak, általában lehetővé teszi a köztes szoftver folyamatának futtatását a végpontlogika meghívása előtt. A szolgáltatások csökkenthetik az erőforrás-használatot, ha kiszűrik az ismert kéréseket a folyamat korai szakaszában. A ShortCircuit bővítménymetódus használatával az útválasztás azonnal meghívja a végpontlogikát, majd befejezi a kérést. Előfordulhat például, hogy egy adott útvonalnak nem kell hitelesítésen vagy CORS köztes szoftveren keresztül haladnia. Az alábbi rövidzárlat-kérések az /short-circuit útvonalnak megfelelőek:

app.MapGet("/short-circuit", () => "Short circuiting!").ShortCircuit();

A MapShortCircuit metódussal egyszerre több útvonalhoz is beállíthat rövidzárlatot úgy, hogy egy URL-előtagokat tartalmazó params tömböt ad át neki. A böngészők és a robotok például gyakran mintavételezik a kiszolgálókat olyan jól ismert útvonalakon, mint a robots.txt és a favicon.ico. Ha az alkalmazás nem rendelkezik ezekkel a fájlokkal, egy kódsor mindkét útvonalat konfigurálhatja:

app.MapShortCircuit(404, "robots.txt", "favicon.ico");

További információért lásd: Útválasztás utáni rövidzárlatos köztes szoftver.

HTTP-naplózás közbenső szoftver bővíthetősége

A HTTP-naplózási köztes szoftver számos új funkcióval rendelkezik:

  • HttpLoggingFields.Duration: Ha engedélyezve van, a köztes szoftver egy új naplót bocsát ki a kérelem és a válasz végén, amely a feldolgozáshoz szükséges teljes időt méri. Ez az új mező hozzá lett adva a HttpLoggingFields.All készlethez.
  • HttpLoggingOptions.CombineLogs: Ha engedélyezve van, a köztes szoftver összesíti az összes engedélyezett naplóját egy kéréshez és válaszhoz egy naplóba a végén. Egyetlen naplóüzenet tartalmazza a kérést, a kérelem törzsét, a választ, a válasz törzsét és az időtartamot.
  • IHttpLoggingInterceptor: Egy olyan szolgáltatás új felülete, amely implementálható és regisztrálható (a AddHttpLoggingInterceptorhasználatával) kérésenként és válaszonkénti visszahívások fogadásához, hogy testre szabhassa a naplózott adatokat. A végpontspecifikus naplóbeállításokat először alkalmazzuk, és ezeket a visszahívások során felül lehet bírálni. A megvalósítás a következő lehet:
    • Vizsgálja meg a kérést és a választ.
    • Az HttpLoggingFieldsengedélyezése vagy letiltása.
    • A kérelem vagy válasz törzsének naplózási módjának módosítása.
    • Egyéni mezők hozzáadása a naplókhoz.

További információért lásd a HTTP-naplózást a .NET Core és az ASP.NET Core rendszerben.

Új API-k a ProblemDetailsben a rugalmasabb integráció támogatása érdekében

A .NET 7-ben a ProblemDetails szolgáltatás a ProblemDetails specifikációjánakmegfelelő hibaválaszok létrehozásának élményének javítása érdekében került bevezetésre. A .NET 8-ban új API-t adtak hozzá, amely megkönnyíti a tartalék viselkedés implementálását, ha IProblemDetailsService nem tud ProblemDetailslétrehozni. Az alábbi példa az új TryWriteAsync API használatát szemlélteti:

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddProblemDetails();

var app = builder.Build();

app.UseExceptionHandler(exceptionHandlerApp =>
{
    exceptionHandlerApp.Run(async httpContext =>
    {
        var pds = httpContext.RequestServices.GetService<IProblemDetailsService>();
        if (pds == null
            || !await pds.TryWriteAsync(new() { HttpContext = httpContext }))
        {
            // Fallback behavior
            await httpContext.Response.WriteAsync("Fallback: An error occurred.");
        }
    });
});

app.MapGet("/exception", () =>
{
    throw new InvalidOperationException("Sample Exception");
});

app.MapGet("/", () => "Test by calling /exception");

app.Run();

További információ: IProblemDetailsService tartalék

További erőforrások