Apa yang baru dalam ASP.NET Core 6.0
Artikel ini menyoroti perubahan paling signifikan dalam ASP.NET Core 6.0 dengan tautan ke dokumentasi yang relevan.
ASP.NET Core MVC dan Razor peningkatan
Minimal API
API minimal dirancang untuk membuat API HTTP dengan dependensi minimal. Mereka sangat ideal untuk layanan mikro dan aplikasi yang hanya ingin menyertakan file, fitur, dan dependensi minimum di ASP.NET Core. Untuk informasi selengkapnya, lihat:
- Tutorial: Membuat API minimal dengan ASP.NET Core
- Perbedaan antara API dan API minimal dengan pengontrol
- Referensi cepat API minimal
- Sampel kode dimigrasikan ke model hosting minimal baru di 6.0
SignalR
Tag aktivitas yang berjalan lama untuk SignalR koneksi
SignalR menggunakan yang baru Microsoft.AspNetCore.Http.Features.IHttpActivityFeature.Activity untuk menambahkan http.long_running
tag ke aktivitas permintaan.
IHttpActivityFeature.Activity
digunakan oleh layanan APM seperti Azure Monitor Application Insights untuk memfilter SignalR permintaan agar tidak membuat pemberitahuan permintaan yang berjalan lama.
Peningkatan performa SignalR
- Alokasikan HubCallerClients sekali per koneksi alih-alih setiap panggilan metode hub.
- Hindari penutupan alokasi di SignalR
DefaultHubDispatcher.Invoke
. Status diteruskan ke fungsi statis lokal melalui parameter untuk menghindari alokasi penutupan. Untuk informasi selengkapnya, lihat permintaan pull GitHub ini. - Alokasikan satu StreamItemMessage per streaming alih-alih per item streaming dalam streaming server-ke-klien. Untuk informasi selengkapnya, lihat permintaan pull GitHub ini.
Razor kompilator
Razor compiler diperbarui untuk menggunakan generator sumber
Pengkompilasi Razor sekarang didasarkan pada generator sumber C#. Generator sumber berjalan selama kompilasi dan periksa apa yang sedang dikompilasi untuk menghasilkan file tambahan yang dikompilasi bersama dengan sisa proyek. Menggunakan generator sumber menyederhanakan Razor pengkompilasi dan secara signifikan mempercepat waktu build.
Razor compiler tidak lagi menghasilkan rakitan Tampilan terpisah
Kompilator Razor sebelumnya menggunakan proses kompilasi dua langkah yang menghasilkan rakitan Tampilan terpisah yang berisi tampilan dan halaman (.cshtml
file) yang dihasilkan yang ditentukan dalam aplikasi. Jenis yang dihasilkan adalah publik dan di AspNetCore
bawah namespace layanan.
Pengkompilasi yang diperbarui Razor membangun tampilan dan jenis halaman ke dalam perakitan proyek utama. Jenis ini sekarang dihasilkan secara default sebagai internal yang AspNetCoreGeneratedDocument
disegel di namespace layanan. Perubahan ini meningkatkan performa build, memungkinkan penyebaran file tunggal, dan memungkinkan jenis ini untuk berpartisipasi dalam Hot Reload.
Untuk informasi selengkapnya tentang perubahan ini, lihat masalah pengumuman terkait di GitHub.
performa ASP.NET Core dan peningkatan API
Banyak perubahan dilakukan untuk mengurangi alokasi dan meningkatkan performa di seluruh tumpukan:
- Aplikasi non-alokasi . Gunakan metode ekstensi. Kelebihan beban
app.Use
baru mengharuskan melewati konteksnext
yang menyimpan dua alokasi internal per permintaan yang diperlukan saat menggunakan kelebihan beban lainnya. - Mengurangi alokasi memori saat mengakses HttpRequest.Cookies. Untuk informasi lebih lanjut, lihat masalah GitHub ini.
- Gunakan LoggerMessage.Define untuk windows hanya HTTP.sys server web. Panggilan ILogger metode ekstensi telah diganti dengan panggilan ke
LoggerMessage.Define
. - Kurangi overhead per koneksi di SocketConnection sebesar ~30%. Untuk informasi selengkapnya, lihat permintaan pull GitHub ini.
- Kurangi alokasi dengan menghapus delegasi pengelogan dalam jenis generik. Untuk informasi selengkapnya, lihat permintaan pull GitHub ini.
- Akses GET yang lebih cepat (sekitar 50%) ke fitur yang umum digunakan seperti IHttpRequestFeature, , IHttpResponseFeatureIHttpResponseBodyFeature, IRouteValuesFeature, dan IEndpointFeature. Untuk informasi selengkapnya, lihat permintaan pull GitHub ini.
- Gunakan string instans tunggal untuk nama header yang diketahui, meskipun tidak berada di blok header yang dipertahankan. Menggunakan string instans tunggal membantu mencegah beberapa duplikat string yang sama dalam koneksi berumur panjang, misalnya, di Microsoft.AspNetCore.WebSockets. Untuk informasi lebih lanjut, lihat masalah GitHub ini.
- Gunakan kembali HttpProtocol CancellationTokenSource di Kestrel. Gunakan metode CancellationTokenSource.TryReset
CancellationTokenSource
untuk menggunakan kembali token jika belum dibatalkan. Untuk informasi selengkapnya, lihat masalah GitHub ini dan video ini. - Terapkan dan gunakan AdaptiveCapacityDictionary di Microsoft.AspNetCore.HttpRequestCookieCollection untuk akses yang lebih efisien ke kamus. Untuk informasi selengkapnya, lihat permintaan pull GitHub ini.
Mengurangi jejak memori untuk koneksi TLS diam
Untuk koneksi TLS yang berjalan lama di mana data hanya sesekali dikirim bolak-balik, kami telah secara signifikan mengurangi jejak memori aplikasi ASP.NET Core di .NET 6. Ini akan membantu meningkatkan skalabilitas skenario seperti server WebSocket. Hal ini dimungkinkan karena banyak peningkatan dalam System.IO.Pipelines, , SslStreamdan Kestrel. Bagian berikut merinci beberapa peningkatan yang telah berkontribusi pada pengurangan jejak memori:
Kurangi ukuran System.IO.Pipelines.Pipe
Untuk setiap koneksi yang dibuat, dua pipa dialokasikan dalam Kestrel:
- Lapisan transportasi ke aplikasi untuk permintaan tersebut.
- Lapisan aplikasi ke transportasi untuk respons.
Dengan menyusutkan ukuran dari 368 byte menjadi 264 byte (sekitar pengurangan System.IO.Pipelines.Pipe 28,2%), 208 byte per koneksi disimpan (104 byte per Pipa).
Pool SocketSender
SocketSender
objek (subkelas SocketAsyncEventArgsitu) sekitar 350 byte saat runtime. Alih-alih mengalokasikan objek baru SocketSender
per koneksi, objek dapat dikumpulkan.
SocketSender
objek dapat dikumpulkan karena pengiriman biasanya sangat cepat. Pengumpulan mengurangi overhead per koneksi. Alih-alih mengalokasikan 350 byte per koneksi, hanya bayar 350 byte per IOQueue
yang dialokasikan. Alokasi dilakukan per antrean untuk menghindari pertikaian. Server WebSocket kami dengan 5000 koneksi diam dari mengalokasikan ~ 1,75 MB (350 byte * 5000) untuk mengalokasikan ~ 2,8 kb (350 byte * 8) untuk SocketSender
objek.
Pembacaan byte nol dengan SslStream
Bacaan tanpa buffer adalah teknik yang digunakan di ASP.NET Core untuk menghindari penyewaan memori dari kumpulan memori jika tidak ada data yang tersedia di soket. Sebelum perubahan ini, server WebSocket kami dengan 5000 koneksi menganggur diperlukan ~ 200 MB tanpa TLS dibandingkan dengan ~ 800 MB dengan TLS. Beberapa alokasi ini (4k per koneksi) adalah dari Kestrel harus berpegang pada ArrayPool<T> buffer sambil menunggu pembacaan SslStream selesai. Mengingat bahwa koneksi ini menganggur, tidak ada bacaan yang selesai dan mengembalikan buffer mereka ke ArrayPool
, memaksa ArrayPool
untuk mengalokasikan lebih banyak memori. Alokasi yang tersisa itu SslStream
sendiri: buffer 4k untuk jabat tangan TLS dan buffer 32k untuk bacaan normal. Di .NET 6, ketika pengguna melakukan pembacaan SslStream
byte nol dan tidak memiliki data yang tersedia, SslStream
secara internal melakukan pembacaan byte nol pada aliran yang dibungkus yang mendasar. Dalam kasus terbaik (koneksi diam), perubahan ini menghasilkan penghematan 40 Kb per koneksi sambil tetap mengizinkan konsumen (Kestrel) untuk diberi tahu ketika data tersedia tanpa menahan buffer yang tidak digunakan.
Pembacaan byte nol dengan PipeReader
Dengan bacaan tanpa buffer yang didukung pada SslStream
, opsi ditambahkan untuk melakukan pembacaan byte nol ke StreamPipeReader
, jenis internal yang mengadaptasi Stream
menjadi PipeReader
. Dalam Kestrel, digunakanStreamPipeReader
untuk mengadaptasi yang mendasar SslStream
menjadi PipeReader
. Oleh karena itu perlu untuk mengekspos semantik baca byte nol ini pada PipeReader
.
Sekarang PipeReader
dapat dibuat yang mendukung pembacaan nol byte atas dasar apa pun Stream
yang mendukung semantik baca byte nol (misalnya, SslStream
, NetworkStream, dll) menggunakan API berikut:
var reader = PipeReader.Create(stream, new StreamPipeReaderOptions(useZeroByteReads: true));
Menghapus slabs dari SlabMemoryPool
Untuk mengurangi fragmentasi tumpukan, Kestrel menggunakan teknik di mana ia mengalokasikan lempung memori 128 KB sebagai bagian dari kumpulan memorinya. Slabs kemudian dibagi lebih lanjut menjadi 4 KB blok yang digunakan oleh Kestrel internal. Lempengan harus lebih besar dari 85 KB untuk memaksa alokasi pada tumpukan objek besar untuk mencoba dan mencegah GC merelokasi array ini. Namun, dengan diperkenalkannya generasi GC baru, Pinned Object Heap (POH), tidak masuk akal lagi untuk mengalokasikan blok pada lempengan. Kestrel sekarang langsung mengalokasikan blok pada POH, mengurangi kompleksitas yang terlibat dalam mengelola kumpulan memori. Perubahan ini harus mempermudah untuk melakukan peningkatan di masa mendatang seperti mempermudah penyusutan kumpulan memori yang digunakan oleh Kestrel.
IAsyncDisposable didukung
IAsyncDisposable sekarang tersedia untuk pengontrol, Razor Halaman, dan Komponen Tampilan. Versi asinkron telah ditambahkan ke antarmuka yang relevan di pabrik dan aktivator:
- Metode baru menawarkan implementasi antarmuka default yang mendelegasikan ke versi sinkron dan panggilan Dispose.
- Implementasi mengambil alih implementasi default dan menangani implementasi pembuangan
IAsyncDisposable
. - Implementasi mendukung
IAsyncDisposable
IDisposable
ketika kedua antarmuka diimplementasikan. - Extender harus mengambil alih metode baru yang disertakan untuk mendukung
IAsyncDisposable
instans.
IAsyncDisposable
bermanfaat ketika bekerja dengan:
- Enumerator asinkron, misalnya, dalam aliran asinkron.
- Sumber daya tidak terkelola yang memiliki operasi I/O intensif sumber daya untuk dirilis.
Saat menerapkan antarmuka ini, gunakan DisposeAsync
metode untuk merilis sumber daya.
Pertimbangkan pengontrol yang membuat dan menggunakan Utf8JsonWriter.
Utf8JsonWriter
IAsyncDisposable
adalah sumber daya:
public class HomeController : Controller, IAsyncDisposable
{
private Utf8JsonWriter? _jsonWriter;
private readonly ILogger<HomeController> _logger;
public HomeController(ILogger<HomeController> logger)
{
_logger = logger;
_jsonWriter = new Utf8JsonWriter(new MemoryStream());
}
IAsyncDisposable
harus mengimplementasikan DisposeAsync
:
public async ValueTask DisposeAsync()
{
if (_jsonWriter is not null)
{
await _jsonWriter.DisposeAsync();
}
_jsonWriter = null;
}
Port Vcpkg untuk SignalR klien C++
Vcpkg adalah manajer paket baris perintah lintas platform untuk pustaka C dan C++. Kami baru-baru ini menambahkan port untuk vcpkg
menambahkan CMake
dukungan asli untuk SignalR klien C++.
vcpkg
juga berfungsi dengan MSBuild.
Klien SignalR dapat ditambahkan ke proyek CMake dengan cuplikan berikut ketika vcpkg disertakan dalam file toolchain:
find_package(microsoft-signalr CONFIG REQUIRED)
link_libraries(microsoft-signalr::microsoft-signalr)
Dengan cuplikan sebelumnya, SignalR klien C++ siap digunakan #include
dan digunakan dalam proyek tanpa konfigurasi tambahan. Untuk contoh lengkap aplikasi C++ yang menggunakan SignalR klien C++, lihat repositori halter73/SignalR-Client-Cpp-Sample .
Blazor
Perubahan templat proyek
Beberapa perubahan templat proyek dilakukan untuk Blazor aplikasi, termasuk penggunaan Pages/_Layout.cshtml
file untuk konten tata letak yang muncul dalam _Host.cshtml
file untuk aplikasi sebelumnya Blazor Server . Pelajari perubahan dengan membuat aplikasi dari templat proyek 6.0 atau mengakses sumber referensi ASP.NET Core untuk templat proyek:
Blazor WebAssembly dukungan dependensi asli
Blazor WebAssembly aplikasi dapat menggunakan dependensi asli yang dibuat untuk berjalan di WebAssembly. Untuk informasi selengkapnya, lihat Blazor WebAssembly asli ASP.NET Core.
Kompilasi WebAssembly Ahead-of-time (AOT) dan runtime relinking
Blazor WebAssembly mendukung kompilasi ahead-of-time (AOT), di mana Anda dapat mengkompilasi kode .NET langsung ke WebAssembly. Kompilasi AOT menghasilkan peningkatan performa runtime dengan mengorbankan ukuran aplikasi yang lebih besar. Menautkan ulang runtime .NET WebAssembly memangkas kode runtime yang tidak digunakan dan dengan demikian meningkatkan kecepatan unduhan. Untuk informasi selengkapnya, lihat Kompilasi ahead-of-time (AOT) dan Runtime relinking.
Mempertahankan status yang telah dirender sebelumnya
Blazor mendukung status bertahan di halaman yang telah dirender sebelumnya sehingga status tidak perlu dibuat ulang saat aplikasi dimuat sepenuhnya. Untuk informasi selengkapnya, lihat Mengintegrasikan komponen ASP.NET Core Razor dengan MVC atau Razor Pages.
Batas kesalahan
Batas kesalahan memberikan pendekatan yang mudah untuk menangani pengecualian pada tingkat UI. Untuk informasi selengkapnya, lihat Blazor ASP.NET Core.
Dukungan SVG
Elemen <foreignObject>
elemen didukung untuk menampilkan HTML arbitrer dalam SVG. Untuk informasi selengkapnya, lihat Razor ASP.NET Core.
Blazor Server dukungan untuk transfer array byte di JS Interop
Blazor mendukung interop array JS byte yang dioptimalkan yang menghindari pengodean dan pendekodean array byte ke base64. Untuk informasi selengkapnya, lihat sumber daya berikut:
- Memanggil fungsi JavaScript dari metode .NET di Blazor ASP.NET Core
- Memanggil metode .NET dari fungsi JavaScript di Blazor ASP.NET Core
Penyempurnaan string kueri
Dukungan untuk bekerja dengan string kueri ditingkatkan. Untuk informasi selengkapnya, lihat Blazor ASP.NET Core.
Pengikatan untuk memilih beberapa
Pengikatan mendukung beberapa pilihan opsi dengan <input>
elemen. Untuk informasi selengkapnya, lihat sumber daya berikut:
Kontrol konten head (<head>
)
Razor komponen dapat mengubah konten elemen HTML <head>
halaman, termasuk mengatur judul (<title>
elemen) halaman dan memodifikasi metadata (<meta>
elemen). Untuk informasi selengkapnya, lihat Blazor ASP.NET Core.
Membuat komponen Angular dan React
Hasilkan komponen JavaScript khusus kerangka kerja dari Razor komponen untuk kerangka kerja web, seperti Angular atau React. Untuk informasi selengkapnya, lihat Razor ASP.NET Core.
Merender komponen dari JavaScript
Render Razor komponen secara dinamis dari JavaScript untuk aplikasi JavaScript yang ada. Untuk informasi selengkapnya, lihat Razor ASP.NET Core.
Elemen kustom
Dukungan eksperimental tersedia untuk membangun elemen kustom, yang menggunakan antarmuka HTML standar. Untuk informasi selengkapnya, lihat Razor ASP.NET Core.
Menyimpulkan jenis generik komponen dari komponen leluhur
Komponen leluhur dapat mengaitkan parameter jenis berdasarkan nama ke turunan menggunakan atribut baru [CascadingTypeParameter]
. Untuk informasi selengkapnya, lihat Razor ASP.NET Core.
Komponen yang dirender secara dinamis
Gunakan komponen bawaan DynamicComponent
baru untuk merender komponen berdasarkan jenis. Untuk informasi selengkapnya, lihat Razor ASP.NET Core yang dirender secara dinamis.
Aksesibilitas yang ditingkatkan Blazor
Gunakan komponen baru FocusOnNavigate
untuk mengatur fokus UI ke elemen berdasarkan pemilih CSS setelah menavigasi dari satu halaman ke halaman lainnya. Untuk informasi selengkapnya, lihat Blazor ASP.NET Core.
Dukungan argumen peristiwa kustom
Blazor mendukung argumen peristiwa kustom, yang memungkinkan Anda meneruskan data arbitrer ke penanganan aktivitas .NET dengan peristiwa kustom. Untuk informasi selengkapnya, lihat Blazor peristiwa ASP.NET Core.
Parameter yang diperlukan
Terapkan atribut baru [EditorRequired]
untuk menentukan parameter komponen yang diperlukan. Untuk informasi selengkapnya, lihat Razor ASP.NET Core.
Kolokasi file JavaScript dengan halaman, tampilan, dan komponen
Kolokasikan file JavaScript untuk halaman, tampilan, dan Razor komponen sebagai cara mudah untuk mengatur skrip di aplikasi. Untuk informasi selengkapnya, lihat ASP.NET Blazor interoperabilitas Core JavaScript (JS interop).
Penginisialisasi JavaScript
Penginisialisasi JavaScript menjalankan logika sebelum dan sesudah Blazor aplikasi dimuat. Untuk informasi selengkapnya, lihat ASP.NET Blazor interoperabilitas Core JavaScript (JS interop).
Interop Streaming JavaScript
Blazor sekarang mendukung data streaming langsung antara .NET dan JavaScript. Untuk informasi selengkapnya, lihat sumber daya berikut:
Batasan jenis generik
Parameter jenis generik sekarang didukung. Untuk informasi selengkapnya, lihat Razor ASP.NET Core.
Tata letak penyebaran WebAssembly
Gunakan tata letak penyebaran untuk mengaktifkan Blazor WebAssembly unduhan aplikasi di lingkungan keamanan terbatas. Untuk informasi selengkapnya, lihat Blazor WebAssembly yang dihosting ASP.NET Core.
Artikel baru Blazor
Selain fitur yang Blazor dijelaskan di bagian sebelumnya, artikel baru Blazor tersedia pada subjek berikut:
-
Blazor file Core: Pelajari cara mengunduh file menggunakan interop streaming asli
byte[]
untuk memastikan transfer yang efisien ke klien. - Menampilkan gambar dan dokumen di ASP.NET Core Blazor: Temukan cara bekerja dengan gambar dan dokumen di Blazor aplikasi, termasuk cara mengalirkan data gambar dan dokumen.
Membangun Blazor Hybrid aplikasi dengan .NET MAUI, WPF, dan Formulir Windows
Gunakan Blazor Hybrid untuk memadukan kerangka kerja klien asli desktop dan seluler dengan .NET dan Blazor:
- .NET Multi-platform App UI (.NET MAUI) adalah kerangka kerja lintas platform untuk membuat aplikasi seluler dan desktop asli dengan C# dan XAML.
- Blazor Hybridaplikasi dapat dibangun dengan Windows Presentation Foundation (WPF) dan kerangka kerja Formulir Windows.
Penting
Blazor Hybrid dalam pratinjau dan tidak boleh digunakan dalam aplikasi produksi hingga rilis akhir.
Untuk informasi selengkapnya, lihat sumber daya berikut:
- Pratinjau dokumentasi ASP.NET Core Blazor Hybrid
- Apa itu .NET MAUI?
- Microsoft .NET Blog (kategori: ".NET MAUI")
Kestrel
HTTP/3 saat ini dalam draf dan karenanya dapat berubah. Dukungan HTTP/3 di ASP.NET Core tidak dirilis, ini adalah fitur pratinjau yang disertakan dalam .NET 6.
Kestrel sekarang mendukung HTTP/3. Untuk informasi selengkapnya, lihat Kestrel web ASP.NET Core dan entri blog dukungan HTTP/3 di .NET 6.
Kategori pengelogan baru Kestrel untuk pengelogan yang dipilih
Sebelum perubahan ini, mengaktifkan pengelogan verbose sangat Kestrel mahal karena semua berbagi Kestrel nama kategori pengeloganMicrosoft.AspNetCore.Server.Kestrel
.
Microsoft.AspNetCore.Server.Kestrel
masih tersedia, tetapi subkataan baru berikut ini memungkinkan kontrol pengelogan yang lebih banyak:
-
Microsoft.AspNetCore.Server.Kestrel
(kategori saat ini):ApplicationError
, ,ConnectionHeadResponseBodyWrite
,ApplicationNeverCompleted
RequestBodyStart
,RequestBodyDone
, ,RequestBodyNotEntirelyRead
RequestBodyDrainTimedOut
,ResponseMinimumDataRateNotSatisfied
, ,InvalidResponseHeaderRemoved
.HeartbeatSlow
-
Microsoft.AspNetCore.Server.Kestrel.BadRequests
:ConnectionBadRequest
,RequestProcessingError
, .RequestBodyMinimumDataRateNotSatisfied
-
Microsoft.AspNetCore.Server.Kestrel.Connections
:ConnectionAccepted
, ,ConnectionStart
,ConnectionStop
ConnectionPause
,ConnectionResume
,ConnectionKeepAlive
,ConnectionRejected
,ConnectionDisconnect
,NotAllConnectionsClosedGracefully
,NotAllConnectionsAborted
, .ApplicationAbortedConnection
-
Microsoft.AspNetCore.Server.Kestrel.Http2
:Http2ConnectionError
, ,Http2ConnectionClosing
,Http2ConnectionClosed
Http2StreamError
,Http2StreamResetAbort
,HPackDecodingError
,HPackEncodingError
,Http2FrameReceived
, ,Http2FrameSending
.Http2MaxConcurrentStreamsReached
-
Microsoft.AspNetCore.Server.Kestrel.Http3
:Http3ConnectionError
, ,Http3ConnectionClosing
Http3ConnectionClosed
,Http3StreamAbort
, ,Http3FrameReceived
.Http3FrameSending
Aturan yang ada terus berfungsi, tetapi Anda sekarang bisa lebih selektif tentang aturan mana yang Anda aktifkan. Misalnya, overhead pengamatan mengaktifkan pengelogan Debug
hanya untuk permintaan buruk sangat berkurang dan dapat diaktifkan dengan konfigurasi berikut:
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft.AspNetCore": "Warning",
"Microsoft.AspNetCore.Kestrel.BadRequests": "Debug"
}
}
Pemfilteran log menerapkan aturan dengan awalan kategori pencocokan terpanjang. Untuk informasi selengkapnya, lihat Bagaimana aturan pemfilteran diterapkan
Memancarkan KestrelServerOptions melalui peristiwa EventSource
KestrelEventSourceEventLevel.LogAlways
Kejadian ini mempermudah alasan tentang perilaku server saat menganalisis jejak yang dikumpulkan. JSON berikut adalah contoh payload peristiwa:
{
"AllowSynchronousIO": false,
"AddServerHeader": true,
"AllowAlternateSchemes": false,
"AllowResponseHeaderCompression": true,
"EnableAltSvc": false,
"IsDevCertLoaded": true,
"RequestHeaderEncodingSelector": "default",
"ResponseHeaderEncodingSelector": "default",
"Limits": {
"KeepAliveTimeout": "00:02:10",
"MaxConcurrentConnections": null,
"MaxConcurrentUpgradedConnections": null,
"MaxRequestBodySize": 30000000,
"MaxRequestBufferSize": 1048576,
"MaxRequestHeaderCount": 100,
"MaxRequestHeadersTotalSize": 32768,
"MaxRequestLineSize": 8192,
"MaxResponseBufferSize": 65536,
"MinRequestBodyDataRate": "Bytes per second: 240, Grace Period: 00:00:05",
"MinResponseDataRate": "Bytes per second: 240, Grace Period: 00:00:05",
"RequestHeadersTimeout": "00:00:30",
"Http2": {
"MaxStreamsPerConnection": 100,
"HeaderTableSize": 4096,
"MaxFrameSize": 16384,
"MaxRequestHeaderFieldSize": 16384,
"InitialConnectionWindowSize": 131072,
"InitialStreamWindowSize": 98304,
"KeepAlivePingDelay": "10675199.02:48:05.4775807",
"KeepAlivePingTimeout": "00:00:20"
},
"Http3": {
"HeaderTableSize": 0,
"MaxRequestHeaderFieldSize": 16384
}
},
"ListenOptions": [
{
"Address": "https://127.0.0.1:7030",
"IsTls": true,
"Protocols": "Http1AndHttp2"
},
{
"Address": "https://[::1]:7030",
"IsTls": true,
"Protocols": "Http1AndHttp2"
},
{
"Address": "http://127.0.0.1:5030",
"IsTls": false,
"Protocols": "Http1AndHttp2"
},
{
"Address": "http://[::1]:5030",
"IsTls": false,
"Protocols": "Http1AndHttp2"
}
]
}
Kejadian DiagnosticSource baru untuk permintaan HTTP yang ditolak
Kestrel sekarang memancarkan peristiwa baru DiagnosticSource
untuk permintaan HTTP yang ditolak di lapisan server. Sebelum perubahan ini, tidak ada cara untuk mengamati permintaan yang ditolak ini. Peristiwa DiagnosticSource
baru Microsoft.AspNetCore.Server.Kestrel.BadRequest
berisi IBadRequestExceptionFeature yang dapat digunakan untuk mengintrospiksi alasan penolakan permintaan.
using Microsoft.AspNetCore.Http.Features;
using System.Diagnostics;
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
var diagnosticSource = app.Services.GetRequiredService<DiagnosticListener>();
using var badRequestListener = new BadRequestEventListener(diagnosticSource,
(badRequestExceptionFeature) =>
{
app.Logger.LogError(badRequestExceptionFeature.Error, "Bad request received");
});
app.MapGet("/", () => "Hello world");
app.Run();
class BadRequestEventListener : IObserver<KeyValuePair<string, object>>, IDisposable
{
private readonly IDisposable _subscription;
private readonly Action<IBadRequestExceptionFeature> _callback;
public BadRequestEventListener(DiagnosticListener diagnosticListener,
Action<IBadRequestExceptionFeature> callback)
{
_subscription = diagnosticListener.Subscribe(this!, IsEnabled);
_callback = callback;
}
private static readonly Predicate<string> IsEnabled = (provider) => provider switch
{
"Microsoft.AspNetCore.Server.Kestrel.BadRequest" => true,
_ => false
};
public void OnNext(KeyValuePair<string, object> pair)
{
if (pair.Value is IFeatureCollection featureCollection)
{
var badRequestFeature = featureCollection.Get<IBadRequestExceptionFeature>();
if (badRequestFeature is not null)
{
_callback(badRequestFeature);
}
}
}
public void OnError(Exception error) { }
public void OnCompleted() { }
public virtual void Dispose() => _subscription.Dispose();
}
Untuk informasi selengkapnya, lihat Pengelogan dan diagnostik di Kestrel.
Membuat ConnectionContext dari Accept Socket
Yang baru SocketConnectionContextFactory memungkinkan untuk membuat ConnectionContext dari soket yang diterima. Ini memungkinkan untuk membangun berbasis IConnectionListenerFactory soket kustom tanpa kehilangan semua pekerjaan performa dan pengumpulan yang terjadi di SocketConnection.
Lihat contoh IConnectionListenerFactory kustom ini yang menunjukkan cara menggunakan ini SocketConnectionContextFactory
.
Kestrel adalah profil peluncuran default untuk Visual Studio
Profil peluncuran default untuk semua proyek web dotnet baru adalah Kestrel. Memulai Kestrel secara signifikan lebih cepat dan menghasilkan pengalaman yang lebih responsif saat mengembangkan aplikasi.
IIS Express masih tersedia sebagai profil peluncuran untuk skenario seperti Autentikasi Windows atau berbagi port.
Port localhost untuk Kestrel acak
Lihat Port yang dihasilkan templat untuk Kestrel dalam dokumen ini untuk informasi selengkapnya.
Autentikasi dan otorisasi
Server autentikasi
.NET 3 hingga .NET 5 menggunakan IdentityServer4 sebagai bagian dari templat kami untuk mendukung penerbitan token JWT untuk SPA dan Blazor aplikasi. Templat sekarang menggunakan Duende Identity Server.
Jika Anda memperluas model identitas dan memperbarui proyek yang ada, perbarui namespace dalam kode Anda dari IdentityServer4.IdentityServer
ke Duende.IdentityServer
dan ikuti instruksi migrasinya.
Model lisensi untuk Duende Identity Server telah berubah menjadi lisensi timbal balik, yang mungkin memerlukan biaya lisensi ketika digunakan secara komersial dalam produksi. Lihat halaman Lisensi Duende untuk detail selengkapnya.
Negosiasi sertifikat klien tertunda
Pengembang sekarang dapat ikut serta menggunakan negosiasi sertifikat klien yang tertunda dengan menentukan ClientCertificateMode.DelayCertificate pada HttpsConnectionAdapterOptions. Ini hanya berfungsi dengan koneksi HTTP/1.1 karena HTTP/2 melarang negosiasi ulang sertifikat tertunda. Pemanggil API ini harus menyangga isi permintaan sebelum meminta sertifikat klien:
using Microsoft.AspNetCore.Server.Kestrel.Https;
using Microsoft.AspNetCore.WebUtilities;
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.UseKestrel(options =>
{
options.ConfigureHttpsDefaults(adapterOptions =>
{
adapterOptions.ClientCertificateMode = ClientCertificateMode.DelayCertificate;
});
});
var app = builder.Build();
app.Use(async (context, next) =>
{
bool desiredState = GetDesiredState();
// Check if your desired criteria is met
if (desiredState)
{
// Buffer the request body
context.Request.EnableBuffering();
var body = context.Request.Body;
await body.DrainAsync(context.RequestAborted);
body.Position = 0;
// Request client certificate
var cert = await context.Connection.GetClientCertificateAsync();
// Disable buffering on future requests if the client doesn't provide a cert
}
await next(context);
});
app.MapGet("/", () => "Hello World!");
app.Run();
OnCheckSlidingExpiration
peristiwa untuk mengontrol perpanjangan cookie
Cookie kedaluwarsa geser autentikasi sekarang dapat disesuaikan atau ditekan menggunakan yang baru OnCheckSlidingExpiration. Misalnya, peristiwa ini dapat digunakan oleh aplikasi satu halaman yang perlu melakukan ping server secara berkala tanpa memengaruhi sesi autentikasi.
Lain-lain
Hot Reload
Buat UI dan pembaruan kode dengan cepat untuk menjalankan aplikasi tanpa kehilangan status aplikasi untuk pengalaman pengembang yang lebih cepat dan lebih produktif menggunakan Hot Reload. Untuk informasi selengkapnya, lihat dukungan .NET Hot Reload untuk ASP.NET Core dan Perbarui kemajuan .NET Hot Reload dan Sorotan Visual Studio 2022.
Templat aplikasi halaman tunggal (SPA) yang disempurnakan
Templat proyek ASP.NET Core telah diperbarui untuk Angular dan React untuk menggunakan pola yang ditingkatkan untuk aplikasi satu halaman yang lebih fleksibel dan lebih selaras dengan pola umum untuk pengembangan web front-end modern.
Sebelumnya, templat ASP.NET Core untuk Angular dan React menggunakan middleware khusus selama pengembangan untuk meluncurkan server pengembangan untuk kerangka kerja front-end dan kemudian permintaan proksi dari ASP.NET Core ke server pengembangan. Logika untuk meluncurkan server pengembangan front-end khusus untuk antarmuka baris perintah untuk kerangka kerja front-end yang sesuai. Mendukung kerangka kerja front-end tambahan menggunakan pola ini berarti menambahkan logika tambahan ke ASP.NET Core.
Templat ASP.NET Core yang diperbarui untuk Angular dan React di .NET 6 membalikkan pengaturan ini dan memanfaatkan dukungan proksi bawaan di server pengembangan dari sebagian besar kerangka kerja front-end modern. Ketika aplikasi ASP.NET Core diluncurkan, server pengembangan front-end diluncurkan seperti sebelumnya, tetapi server pengembangan dikonfigurasi untuk memproksi permintaan ke proses backend ASP.NET Core. Semua konfigurasi khusus front-end untuk menyiapkan proksi adalah bagian dari aplikasi, bukan ASP.NET Core. Menyiapkan proyek ASP.NET Core untuk bekerja dengan kerangka kerja front-end lainnya sekarang lurus ke depan: menyiapkan server pengembangan front-end untuk kerangka kerja yang dipilih untuk diproksi ke backend ASP.NET Core menggunakan pola yang ditetapkan dalam templat Angular dan React.
Kode startup untuk aplikasi ASP.NET Core tidak lagi memerlukan logika khusus aplikasi satu halaman. Logika untuk memulai server pengembangan front-end selama pengembangan disuntikkan ke aplikasi saat runtime oleh paket Microsoft.AspNetCore.SpaProxy baru. Perutean fallback ditangani menggunakan perutean titik akhir alih-alih middleware khusus SPA.
Templat yang mengikuti pola ini masih dapat dijalankan sebagai proyek tunggal di Visual Studio atau menggunakan dotnet run
dari baris perintah. Saat aplikasi diterbitkan, kode front-end di folder ClientApp dibangun dan dikumpulkan seperti sebelumnya ke akar web aplikasi host ASP.NET Core dan dilayani sebagai file statis. Skrip yang disertakan dalam templat mengonfigurasi server pengembangan front-end untuk menggunakan HTTPS menggunakan sertifikat pengembangan ASP.NET Core.
Draf dukungan HTTP/3 di .NET 6
HTTP/3 saat ini dalam draf dan karenanya dapat berubah. Dukungan HTTP/3 di ASP.NET Core tidak dirilis, ini adalah fitur pratinjau yang disertakan dalam .NET 6.
Lihat entri blog dukungan HTTP/3 di .NET 6.
Anotasi Tipe Referensi Nullable
Bagian dari kode sumber ASP.NET Core 6.0 telah menerapkan anotasi nullability.
Dengan menggunakan fitur Nullable baru di C# 8, ASP.NET Core dapat memberikan keamanan waktu kompilasi tambahan dalam penanganan jenis referensi. Misalnya, melindungi dari null
pengecualian referensi. Proyek yang telah memilih untuk menggunakan anotasi nullable mungkin melihat peringatan build-time baru dari API ASP.NET Core.
Untuk mengaktifkan jenis referensi nullable, tambahkan properti berikut ke file proyek:
<PropertyGroup>
<Nullable>enable</Nullable>
</PropertyGroup>
Untuk informasi selengkapnya, lihat Jenis nilai yang dapat diubah ke null.
Analisis Kode Sumber
Beberapa penganalisis platform kompilator .NET ditambahkan yang memeriksa kode aplikasi untuk masalah seperti konfigurasi atau urutan middleware yang salah, konflik perutean, dll. Untuk informasi selengkapnya, lihat Analisis kode di aplikasi ASP.NET Core.
Penyempurnaan templat aplikasi web
Templat aplikasi web:
- Gunakan model hosting minimal baru.
- Secara signifikan mengurangi jumlah file dan baris kode yang diperlukan untuk membuat aplikasi. Misalnya, aplikasi web kosong ASP.NET Core membuat satu file C# dengan empat baris kode dan merupakan aplikasi lengkap.
- Menyaingkan
Startup.cs
danProgram.cs
ke dalam satuProgram.cs
file. - Menggunakan pernyataan tingkat atas untuk meminimalkan kode yang diperlukan untuk aplikasi.
- Menggunakan arahan
using
global untuk menghilangkan atau meminimalkan jumlahusing
baris pernyataan yang diperlukan.
Port yang dihasilkan templat untuk Kestrel
Port acak ditetapkan selama pembuatan proyek untuk digunakan oleh Kestrel server web. Port acak membantu meminimalkan konflik port ketika beberapa proyek dijalankan pada komputer yang sama.
Ketika proyek dibuat, port HTTP acak antara 5000-5300 dan port HTTPS acak antara 7000-7300 ditentukan dalam file yang dihasilkan Properties/launchSettings.json
. Port dapat diubah dalam Properties/launchSettings.json
file. Jika tidak ada port yang ditentukan, Kestrel default ke port HTTP 5000 dan HTTPS 5001. Untuk informasi selengkapnya, lihat Kestrel web ASP.NET Core.
Default pengelogan baru
Perubahan berikut dilakukan pada dan appsettings.json
appsettings.Development.json
:
- "Microsoft": "Warning",
- "Microsoft.Hosting.Lifetime": "Information"
+ "Microsoft.AspNetCore": "Warning"
Perubahan dari "Microsoft": "Warning"
ke menghasilkan pengelogan semua pesan informasi dari "Microsoft.AspNetCore": "Warning"
namespaceMicrosoft
.Microsoft.AspNetCore
Misalnya, Microsoft.EntityFrameworkCore
sekarang dicatat di tingkat informasi.
Halaman pengecualian pengembang Middleware ditambahkan secara otomatis
Di lingkungan pengembangan, DeveloperExceptionPageMiddleware ditambahkan secara default. Tidak perlu lagi menambahkan kode berikut ke aplikasi UI web:
if (app.Environment.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
Dukungan untuk header permintaan yang dikodekan Latin1 di HttpSysServer
HttpSysServer
sekarang mendukung header permintaan decoding yang dikodekan Latin1
dengan mengatur UseLatin1RequestHeaders properti ke HttpSysOptionstrue
:
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.UseHttpSys(o => o.UseLatin1RequestHeaders = true);
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();
Log Modul ASP.NET Core mencakup tanda waktu dan PID
Log diagnostik yang ditingkatkan ASP.NET Core Module (ANCM) for IIS (ANCM) mencakup tanda waktu dan PID dari proses yang memancarkan log. Tanda waktu pengelogan dan PID memudahkan untuk mendiagnosis masalah dengan proses yang tumpang tindih dimulai ulang di IIS ketika beberapa proses pekerja IIS berjalan.
Log yang dihasilkan sekarang menyerupai contoh output yang ditunjukkan di bawah ini:
[2021-07-28T19:23:44.076Z, PID: 11020] [aspnetcorev2.dll] Initializing logs for 'C:\<path>\aspnetcorev2.dll'. Process Id: 11020. File Version: 16.0.21209.0. Description: IIS ASP.NET Core Module V2. Commit: 96475a2acdf50d7599ba8e96583fa73efbe27912.
[2021-07-28T19:23:44.079Z, PID: 11020] [aspnetcorev2.dll] Resolving hostfxr parameters for application: '.\InProcessWebSite.exe' arguments: '' path: 'C:\Temp\e86ac4e9ced24bb6bacf1a9415e70753\'
[2021-07-28T19:23:44.080Z, PID: 11020] [aspnetcorev2.dll] Known dotnet.exe location: ''
Ukuran buffer masuk yang tidak dapat dikonfigurasi untuk IIS
Server IIS sebelumnya hanya menyangga 64 KiB badan permintaan yang tidak dikonsumsi. Buffering 64 KiB mengakibatkan pembacaan dibatasi hingga ukuran maksimum tersebut, yang berdampak pada performa dengan bodi masuk besar seperti unggahan. Di .NET 6 , ukuran buffer default berubah dari 64 KiB menjadi 1 MiB yang harus meningkatkan throughput untuk unggahan besar. Dalam pengujian kami, unggahan 700 MiB yang digunakan untuk mengambil waktu 9 detik sekarang hanya membutuhkan waktu 2,5 detik.
Kelemahan dari ukuran buffer yang lebih besar adalah peningkatan konsumsi memori per permintaan ketika aplikasi tidak dengan cepat membaca dari isi permintaan. Jadi, selain mengubah ukuran buffer default, ukuran buffer yang dapat dikonfigurasi, memungkinkan aplikasi untuk mengonfigurasi ukuran buffer berdasarkan beban kerja.
Lihat Bantuan Tag Komponen
Pertimbangkan komponen tampilan dengan parameter opsional, seperti yang ditunjukkan dalam kode berikut:
class MyViewComponent
{
IViewComponentResult Invoke(bool showSomething = false) { ... }
}
Dengan ASP.NET Core 6, pembantu tag dapat dipanggil tanpa harus menentukan nilai untuk showSomething
parameter:
<vc:my />
Templat Angular diperbarui ke Angular 12
Templat ASP.NET Core 6.0 untuk Angular sekarang menggunakan Angular 12.
Templat React telah diperbarui ke React 17.
Ambang buffer yang dapat dikonfigurasi sebelum menulis ke disk dalam formatter output Json.NET
Catatan: Sebaiknya gunakan System.Text.Json pemformat output kecuali saat Newtonsoft.Json
serializer diperlukan karena alasan kompatibilitas. Serializer System.Text.Json
sepenuhnya async
dan berfungsi secara efisien untuk payload yang lebih besar.
Formatter Newtonsoft.Json
output secara default buffer merespons hingga 32 KiB dalam memori sebelum buffering ke disk. Ini untuk menghindari melakukan IO sinkron, yang dapat mengakibatkan efek samping lainnya seperti kelaparan utas dan kebuntuan aplikasi. Namun, jika respons lebih besar dari 32 KiB, I/O disk yang cukup besar terjadi. Ambang memori sekarang dapat dikonfigurasi melalui properti MvcNewtonsoftJsonOptions.OutputFormatterMemoryBufferThreshold sebelum buffering ke disk:
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages()
.AddNewtonsoftJson(options =>
{
options.OutputFormatterMemoryBufferThreshold = 48 * 1024;
});
var app = builder.Build();
Untuk informasi selengkapnya, lihat permintaan pull GitHub ini dan file NewtonsoftJsonOutputFormatterTest.cs .
Dapatkan dan atur lebih cepat untuk header HTTP
API baru ditambahkan untuk mengekspos semua header umum yang tersedia sebagai Microsoft.Net.Http.Headers.HeaderNames properti yang IHeaderDictionary menghasilkan API yang lebih mudah digunakan. Misalnya, middleware sebaris dalam kode berikut mendapatkan dan mengatur header permintaan dan respons menggunakan API baru:
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Use(async (context, next) =>
{
var hostHeader = context.Request.Headers.Host;
app.Logger.LogInformation("Host header: {host}", hostHeader);
context.Response.Headers.XPoweredBy = "ASP.NET Core 6.0";
await next.Invoke(context);
var dateHeader = context.Response.Headers.Date;
app.Logger.LogInformation("Response date: {date}", dateHeader);
});
app.Run();
Untuk header yang diimplementasikan, aksesor dapatkan dan atur diimplementasikan dengan langsung ke bidang dan melewati pencarian. Untuk header yang tidak diimplementasikan, pengakses dapat melewati pencarian awal terhadap header yang diimplementasikan dan langsung melakukan Dictionary<string, StringValues>
pencarian. Menghindari pencarian menghasilkan akses yang lebih cepat untuk kedua skenario.
Streaming asinkron
ASP.NET Core sekarang mendukung streaming asinkron dari tindakan pengontrol dan respons dari formatter JSON. Mengembalikan IAsyncEnumerable
dari tindakan tidak lagi menyangga konten respons dalam memori sebelum dikirim. Tidak buffering membantu mengurangi penggunaan memori saat mengembalikan himpunan data besar yang dapat dijumlahkan secara asinkron.
Perhatikan bahwa Entity Framework Core menyediakan implementasi untuk mengkueri IAsyncEnumerable
database. Dukungan yang ditingkatkan untuk IAsyncEnumerable
di ASP.NET Core di .NET 6 dapat membuat penggunaan EF Core dengan ASP.NET Core lebih efisien. Misalnya, kode berikut tidak lagi menyangga data produk ke dalam memori sebelum mengirim respons:
public IActionResult GetMovies()
{
return Ok(_context.Movie);
}
Namun, saat menggunakan pemuatan malas di EF Core, perilaku baru ini dapat mengakibatkan kesalahan karena eksekusi kueri bersamaan saat data sedang dijumlahkan. Aplikasi dapat kembali ke perilaku sebelumnya dengan menyangga data:
public async Task<IActionResult> GetMovies2()
{
return Ok(await _context.Movie.ToListAsync());
}
Lihat pengumuman terkait untuk detail tambahan tentang perubahan perilaku ini.
Middleware pengelogan HTTP
Pengelogan HTTP adalah middleware bawaan baru yang mencatat informasi tentang permintaan HTTP dan respons HTTP termasuk header dan seluruh isi:
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.UseHttpLogging();
app.MapGet("/", () => "Hello World!");
app.Run();
Menavigasi ke /
dengan informasi log kode sebelumnya yang mirip dengan output berikut:
info: Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware[1]
Request:
Protocol: HTTP/2
Method: GET
Scheme: https
PathBase:
Path: /
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Cache-Control: max-age=0
Connection: close
Cookie: [Redacted]
Host: localhost:44372
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36 Edg/95.0.1020.30
sec-ch-ua: [Redacted]
sec-ch-ua-mobile: [Redacted]
sec-ch-ua-platform: [Redacted]
upgrade-insecure-requests: [Redacted]
sec-fetch-site: [Redacted]
sec-fetch-mode: [Redacted]
sec-fetch-user: [Redacted]
sec-fetch-dest: [Redacted]
info: Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware[2]
Response:
StatusCode: 200
Content-Type: text/plain; charset=utf-8
Output sebelumnya diaktifkan dengan file berikut appsettings.Development.json
:
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft.AspNetCore": "Warning",
"Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware": "Information"
}
}
}
Pengelogan HTTP menyediakan log dari:
- Informasi Permintaan HTTP
- Properti umum
- Header
- Isi
- Informasi Respons HTTP
Untuk mengonfigurasi middleware pengelogan HTTP, tentukan HttpLoggingOptions:
using Microsoft.AspNetCore.HttpLogging;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddHttpLogging(logging =>
{
// Customize HTTP logging.
logging.LoggingFields = HttpLoggingFields.All;
logging.RequestHeaders.Add("My-Request-Header");
logging.ResponseHeaders.Add("My-Response-Header");
logging.MediaTypeOptions.AddText("application/javascript");
logging.RequestBodyLogLimit = 4096;
logging.ResponseBodyLogLimit = 4096;
});
var app = builder.Build();
app.UseHttpLogging();
app.MapGet("/", () => "Hello World!");
app.Run();
IConnectionSocketFeature
IConnectionSocketFeature Fitur permintaan menyediakan akses ke soket terima yang mendasar yang terkait dengan permintaan saat ini. Ini dapat diakses melalui on FeatureCollectionHttpContext
.
Misalnya, aplikasi berikut mengatur LingerState properti pada soket yang diterima:
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.ConfigureKestrel(serverOptions =>
{
serverOptions.ConfigureEndpointDefaults(listenOptions => listenOptions.Use((connection, next) =>
{
var socketFeature = connection.Features.Get<IConnectionSocketFeature>();
socketFeature.Socket.LingerState = new LingerOption(true, seconds: 10);
return next();
}));
});
var app = builder.Build();
app.MapGet("/", (Func<string>)(() => "Hello world"));
await app.RunAsync();
Batasan jenis generik dalam Razor
Saat menentukan parameter jenis generik dalam Razor menggunakan @typeparam
direktif, batasan jenis generik sekarang dapat ditentukan menggunakan sintaks C# standar:
Skrip MessagePack yang lebih SignalRkecil , Blazor Server, dan
SignalRSkrip , MessagePack, dan Blazor Server sekarang secara signifikan lebih kecil, memungkinkan unduhan yang lebih kecil, penguraian dan kompilasi JavaScript yang lebih sedikit oleh browser, dan start-up yang lebih cepat. Pengurangan ukuran:
-
signalr.js
: 70% -
blazor.server.js
: 45%
Skrip yang lebih kecil adalah hasil dari kontribusi komunitas dari Ben Adams. Untuk informasi selengkapnya tentang detail pengurangan ukuran, lihat Permintaan penarikan GitHub Ben.
Mengaktifkan sesi pembuatan profil Redis
Kontribusi komunitas dari Gabriel Lucaci memungkinkan sesi pembuatan profil Redis dengan Microsoft.Extensions.Caching.StackExchangeRedis:
using StackExchange.Redis.Profiling;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddStackExchangeRedisCache(options =>
{
options.ProfilingSession = () => new ProfilingSession();
});
Untuk informasi selengkapnya, lihat Pembuatan Profil StackExchange.Redis.
Penyalinan bayangan di IIS
Fitur eksperimental telah ditambahkan ke ASP.NET Core Module (ANCM) untuk IIS guna menambahkan dukungan untuk rakitan aplikasi penyalinan bayangan. Saat ini .NET mengunci biner aplikasi saat berjalan di Windows sehingga tidak mungkin mengganti biner saat aplikasi berjalan. Meskipun rekomendasi kami tetap menggunakan file offline aplikasi, kami menyadari ada skenario tertentu (misalnya penyebaran FTP) di mana tidak dimungkinkan untuk melakukannya.
Dalam skenario seperti itu, aktifkan penyalinan bayangan dengan menyesuaikan pengaturan handler modul ASP.NET Core. Dalam kebanyakan kasus, aplikasi ASP.NET Core tidak memiliki web.config
kontrol sumber yang dapat Anda ubah. Dalam ASP.NET Core, web.config
biasanya dihasilkan oleh SDK. Sampel web.config
berikut dapat digunakan untuk memulai:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<!-- To customize the asp.net core module uncomment and edit the following section.
For more info see https://go.microsoft.com/fwlink/?linkid=838655 -->
<system.webServer>
<handlers>
<remove name="aspNetCore"/>
<add name="aspNetCore" path="*" verb="*" modules="AspNetCoreModuleV2" resourceType="Unspecified"/>
</handlers>
<aspNetCore processPath="%LAUNCHER_PATH%" arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false" stdoutLogFile=".\logs\stdout">
<handlerSettings>
<handlerSetting name="experimentalEnableShadowCopy" value="true" />
<handlerSetting name="shadowCopyDirectory" value="../ShadowCopyDirectory/" />
<!-- Only enable handler logging if you encounter issues-->
<!--<handlerSetting name="debugFile" value=".\logs\aspnetcore-debug.log" />-->
<!--<handlerSetting name="debugLevel" value="FILE,TRACE" />-->
</handlerSettings>
</aspNetCore>
</system.webServer>
</configuration>
Penyalinan bayangan di IIS adalah fitur eksperimental yang tidak dijamin menjadi bagian dari ASP.NET Core. Silakan tinggalkan umpan balik tentang penyalinan Bayangan IIS dalam masalah GitHub ini.
Sumber Daya Tambahan:
ASP.NET Core