Not
Bu sayfaya erişim yetkilendirme gerektiriyor. Oturum açmayı veya dizinleri değiştirmeyi deneyebilirsiniz.
Bu sayfaya erişim yetkilendirme gerektiriyor. Dizinleri değiştirmeyi deneyebilirsiniz.
Bu makalede, ilgili belgelerin bağlantıları ile .NET 6'da ASP.NET Core'daki en önemli değişiklikler vurgulanır.
ASP.NET Core MVC ve Razor iyileştirmeler
Minimal API'ler
Minimum API'ler, en az bağımlılıkla HTTP API'leri oluşturmak için tasarlanır. Bunlar, ASP.NET Core'da yalnızca en düşük dosyaları, özellikleri ve bağımlılıkları dahil etmek isteyen mikro hizmetler ve uygulamalar için idealdir. Daha fazla bilgi için bakınız:
- Öğretici: ASP.NET Core ile Minimal API oluşturma
- Minimal API'ler ile denetleyicili API'ler arasındaki farklar
- Minimal API'ler hızlı başvuru
- 6.0 sürümünde yeni minimal barındırma modeline geçirilen kod örnekleri
SignalR
Uzun süre çalışan SignalR bağlantılar için etkinlik etiketi
SignalR, istek etkinliğine bir Microsoft.AspNetCore.Http.Features.IHttpActivityFeature.Activity etiketi eklemek için yeni http.long_running kullanır.
IHttpActivityFeature.Activity, Azure İzleyici Application Insights gibi APM hizmetleri tarafından uzun süre çalışan isteklerden kaynaklanan uyarıların oluşmasını engellemek için SignalR isteklerini filtrelemek amacıyla kullanılır.
SignalR performans geliştirmeleri
- HubCallerClients'ı her hub yöntemi çağrısı yerine bağlantı başına bir kez ayırın.
-
SignalR
DefaultHubDispatcher.Invokeiçinde closure tahsisinden kaçının. Durum, kapanım ayırmasını önlemek için parametreler aracılığıyla statik yerel fonksiyona aktarılır. Daha fazla bilgi için bu GitHub çekme isteğine bakın. - Sunucudan istemciye akışta, akış öğesi yerine akış başına tek bir StreamItemMessage ayırın. Daha fazla bilgi için bu GitHub çekme isteğine bakın.
Razor derleyici
Razor derleyicisi kaynak oluşturucuları kullanacak şekilde güncelleştirildi
Derleyici Razor artık C# kaynak oluşturucularını temel alır. Kaynak oluşturucular derleme sırasında çalışır ve projenin geri kalanıyla birlikte derlenen ek dosyalar üretmek için nelerin derlendiğini inceler. Kaynak oluşturucuların kullanılması derleyiciyi Razor basitleştirir ve derleme sürelerini önemli ölçüde hızlandırır.
Razor derleyici artık ayrı bir Görünümler derlemesi üretmez
Derleyici Razor daha önce uygulamada tanımlanan oluşturulan görünümleri ve sayfaları (.cshtml dosyaları) içeren ayrı bir Görünümler derlemesi oluşturan iki adımlı bir derleme işlemi kullanmıştı. Oluşturulan türler geneldi ve ad alanı AspNetCore altındaydı.
Güncelleştirilmiş Razor derleyici, görünümleri ve sayfa türlerini ana proje derlemesinde oluşturur. Bu türler artık ad alanı AspNetCoreGeneratedDocument içinde dahili mühürlü olarak varsayılan şekilde oluşturulur. Bu değişiklik derleme performansını artırır, tek dosya dağıtımına olanak tanır ve bu türlerin Sık Erişimli Yeniden Yükleme'ye katılmasını sağlar.
Bu değişiklik hakkında daha fazla bilgi için GitHub'da ilgili duyuru sorununa bakın.
ASP.NET Çekirdek performansı ve API geliştirmeleri
Ayırmaları azaltmak ve yığın genelinde performansı geliştirmek için birçok değişiklik yapıldı:
- Ayırma yapmayan app.Use uzantı yöntemi. Yeni
app.Useaşırı yüklemesi, bağlamınnext'e geçirilmesini gerektirir, bu da diğerapp.Useaşırı yüklemesi kullanıldığında gerekli olan iki iç istek başına ayrımı tasarruf eder. - Bellek ayırmaları, HttpRequest.Cookies erişimi sırasında azaltıldı. Daha fazla bilgi için bu GitHub konusuna bakın.
- Yalnızca windowsHTTP.sys web sunucusu için LoggerMessage.Define kullanın.
ILogger uzantı yöntemleri çağrıları,
LoggerMessage.Defineçağrılarıyla değiştirilmiştir. - SocketConnection'da bağlantı başına ek yükü yaklaşık 30%azaltın. Daha fazla bilgi için bu GitHub çekme isteğine bakın.
- Genel türlerdeki günlük temsilcilerini kaldırarak kaynak ayırmalarını azaltın. Daha fazla bilgi için bu GitHub çekme isteğine bakın.
- Sıklıkla kullanılan özelliklere, IHttpRequestFeature, IHttpResponseFeature, IHttpResponseBodyFeature, IRouteValuesFeature ve IEndpointFeature gibi, daha hızlı GET erişimi (yaklaşık 50%). Daha fazla bilgi için bu GitHub çekme isteğine bakın.
- Korunan üst bilgi bloğunda olmasalar bile bilinen üst bilgi adları için tek örnek dizeleri kullanın. Örneğin Microsoft.AspNetCore.WebSockets içinde tek örnek dizesinin kullanılması, aynı dizenin uzun ömürlü bağlantılarda birden çok kez yinelenmesini önlemeye yardımcı olur. Daha fazla bilgi için bu GitHub konusuna bakın.
-
HttpProtocol CancellationTokenSource'u Kestrel içinde yeniden kullanın. Yeni CancellationTokenSource.TryReset yöntemini
CancellationTokenSourceüzerindeki belirteçleri iptal edilmedikleri takdirde yeniden kullanmak için kullanın. Daha fazla bilgi için bu GitHub sorununa ve bu videoya bakın. - Sözlüklere daha verimli erişim için RequestCookieCollection'daMicrosoft.AspNetCore.HttpAdaptiveCapacityDictionary uygulayın ve kullanın. Daha fazla bilgi için bu GitHub çekme isteğine bakın.
Boşta TLS bağlantıları için bellek ayak izi azaltıldı
Verilerin yalnızca ara sıra geri gönderildiği uzun süre çalışan TLS bağlantıları için .NET 6'daki ASP.NET Core uygulamalarının bellek ayak izini önemli ölçüde azalttık. Bu, WebSocket sunucuları gibi senaryoların ölçeklenebilirliğini geliştirmeye yardımcı olmalıdır. Bu, System.IO.Pipelines, SslStream ve Kestrel'de birçok iyileştirme sayesinde mümkün oldu. Aşağıdaki bölümlerde azaltılmış bellek ayak izine katkıda bulunan bazı geliştirmeler ayrıntılı olarak anlatılır:
Boyutunu küçült System.IO.Pipelines.Pipe
Kurulan her bağlantı için Kestrel içinde iki boru tahsis edilir.
- İstek için uygulamaya aktarım katmanı.
- Yanıt için aktarıma yönelik uygulama katmanı.
Boyutu System.IO.Pipelines.Pipe 368 bayttan 264 bayta (yaklaşık 28,2% azaltma) daraltılarak, bağlantı başına 208 bayt kaydedilir (Kanal başına 104 bayt).
Havuz SocketSender
SocketSender nesneleri (bu alt sınıf SocketAsyncEventArgs) çalışma zamanında yaklaşık 350 bayttır. Bağlantı başına yeni SocketSender bir nesne ayırma yerine havuza eklenebilir.
SocketSender gönderme işlemleri genellikle çok hızlı olduğundan nesneler havuzlanabilir. Kaynak birleştirme, bağlantı başına düşen ek yükü azaltır. Bağlantı başına 350 bayt ayırmak yerine, sadece IOQueue başına 350 bayt ayrılır. Çakışmayı önlemek için kuyruk başına ayırma gerçekleştirilir. 5000 atıl bağlantıya sahip WebSocket sunucumuz, SocketSender nesneleri için ayırdığı ~1,75 MB (350 bayt * 5000) bellekten, ~2,8 kB (350 bayt * 8) ayırmaya geçti.
SslStream ile sıfır bayt okuma
Tamponsuz okuma, sokette kullanılabilir veri yoksa bellek havuzundan bellek kiralamaktan kaçınmak için ASP.NET Core framework'ünde kullanılan bir tekniktir. Bu değişiklik öncesinde, 5000 boşta bağlantısı olan WebSocket sunucumuz TLS olmadan yaklaşık 200 MB gerektirirken TLS ile yaklaşık 800 MB gerekiyordu. Bu ayırmalardan bazıları (bağlantı başına 4k), okumaların Kestrel tamamlanmasını beklerken ArrayPool<T> tarafından bir SslStream arabelleğin tutulması gerekliliğinden kaynaklanıyordu. Bu bağlantıların boşta olduğu göz önüne alındığında, okuma işlemlerinin hiçbiri tamamlanmadı ve arabelleklerini ArrayPool öğesine geri vermedi, bu da ArrayPool'in daha fazla bellek ayırmak zorunda kalmasına neden oldu. Kalan ayırmalar doğrudan SslStream içindeydi: TLS el sıkışmaları için 4k arabellek ve normal okumalar için 32k arabellek. .NET 6'da, kullanıcı SslStream üzerinde sıfır bayt okuma işlemi gerçekleştirdiğinde ve kullanılabilir veri olmadığında, SslStream temel alınan sarmalanmış akış üzerinde dahili olarak sıfır bayt okuma gerçekleştirir. En iyi durumda (boşta bağlantı), bu değişiklikler bir bağlantı başına 40 Kb tasarruf sağlarken, kullanılmayan arabellekleri tutmaya gerek kalmadan veriler kullanılabilir olduğunda tüketiciye (Kestrel) bildirim gönderilmesini sağlar.
PipeReader ile sıfır bayt okuma
SslStream üzerinde arabellek kullanılmadan okuma desteklendiğinde, StreamPipeReader öğesi için sıfır bayt okuma işlemi yapma seçeneği eklendi. Bu iç tür, Stream öğesini PipeReader içine dönüştürür.
Kestrel'de, StreamPipeReader temel alınan SslStream öğesini bir PipeReader içine uyarlamak için kullanılır. Bu nedenle bu sıfır bayt okuma semantiğini PipeReader üzerinde kullanıma sunmak gerekiyordu.
Aşağıdaki API kullanılarak, sıfır bayt okuma semantiğini (örn. PipeReader, Stream, vb) destekleyen herhangi bir temel SslStream üzerinde sıfır bayt okumayı destekleyen bir NetworkStream artık oluşturulabilir.
var reader = PipeReader.Create(stream, new StreamPipeReaderOptions(useZeroByteReads: true));
Levhaları kaldır SlabMemoryPool
Yığındaki parçalanmayı azaltmak için, Kestrel, bellek havuzunun bir parçası olarak 128 KB bellek blokları ayırdığı bir teknik kullandı. Döşemeler daha sonra Kestrel tarafından dahili olarak kullanılan 4 KB bloklara bölündü. Gc'nin bu diziyi yeniden konumlandırmasını önlemek için büyük nesne yığınında ayırmayı zorlamak için levhaların 85 KB'tan büyük olması gerekiyordu. Ancak, yeni GC nesli olan Sabitlenmiş Nesne Yığını'nın (POH) kullanıma sunulmasıyla birlikte artık blokları levhaya ayırmak mantıklı değildir. Kestrel artık POH üzerinde blokları doğrudan ayırarak bellek havuzunun yönetilmesindeki karmaşıklığı azaltıyor. Bu değişiklik, tarafından Kestrelkullanılan bellek havuzunu küçültmek gibi gelecekteki iyileştirmeleri gerçekleştirmeyi kolaylaştırmalıdır.
IAsyncDisposable desteklenir
IAsyncDisposable artık denetleyiciler, Razor Sayfalar ve Görünüm Bileşenleri için kullanılabilir. Fabrikalarda ve etkinleştiricilerde ilgili arabirimlere zaman uyumsuz sürümler eklendi:
- Yeni yöntemler, zaman uyumlu sürüme devreden ve Dispose'yi çağıran varsayılan bir arabirim uygulaması sağlar.
- Uygulamalar, varsayılan uygulamayı geçersiz kılar ve
IAsyncDisposableuygulamalarının bertaraf edilmesini yönetir. - Her iki arabirim de uygulandığında, uygulamalar
IAsyncDisposable'uIDisposable'e tercih eder. - Genişleticiler, destek
IAsyncDisposableörneklerine dahil edilen yeni yöntemleri geçersiz kılmalıdır.
IAsyncDisposable şu kişilerle çalışırken faydalıdır:
- Eş zamansız numaralandırıcılar, örneğin eş zamansız akışlarda.
- Yayınlanması gereken yoğun kaynak kullanan G/Ç işlemlerine sahip yönetilmeyen kaynaklar.
Bu arabirimi uygularken, DisposeAsync yöntemini kaynakları serbest bırakmak için kullanın.
Bir Utf8JsonWriter oluşturan ve kullanan bir denetleyici düşünün.
Utf8JsonWriter bir IAsyncDisposable kaynaktır:
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 mutlaka DisposeAsync uygulamalı:
public async ValueTask DisposeAsync()
{
if (_jsonWriter is not null)
{
await _jsonWriter.DisposeAsync();
}
_jsonWriter = null;
}
C++ istemcisi için SignalR Vcpkg bağlantı noktası
Vcpkg , C ve C++ kitaplıkları için platformlar arası bir komut satırı paket yöneticisidir. Yeni bir vcpkg yerel destek eklemek amacıyla C++ istemcisi için CMake'a bir bağlantı noktası SignalR ekledik.
vcpkg ayrıca MSBuild ile de çalışır.
vcpkg SignalR araç zinciri dosyasına eklendiğinde istemci aşağıdaki kod parçacığıyla bir CMake projesine eklenebilir:
find_package(microsoft-signalr CONFIG REQUIRED)
link_libraries(microsoft-signalr::microsoft-signalr)
Önceki kod parçacığıyla SignalR C++ istemcisi, ek yapılandırmaya gerek kalmadan bir projede kullanıma hazır hale gelir ve kullanılır. C++ istemcisini kullanan bir C++ uygulamasının SignalR tam örneği için bkz. halter73/SignalR-Client-Cpp-Sample deposu.
Blazor
Proje şablonu değişiklikleri
Önceki Blazor uygulamalarında Pages/_Layout.cshtml dosyasında görünen düzen içerikleri için _Host.cshtml dosyasının kullanımı da dahil olmak üzere Blazor Server uygulamalar için çeşitli proje şablonu değişiklikleri yapıldı. 6.0 proje şablonundan uygulama oluşturarak veya proje şablonları için ASP.NET Core başvuru kaynağına erişerek değişiklikleri inceleyin:
Blazor WebAssembly yerel bağımlılıklar desteği
Blazor WebAssembly uygulamalar, WebAssembly üzerinde çalışacak şekilde oluşturulmuş yerel bağımlılıkları kullanabilir. Daha fazla bilgi için bkz. ASP.NET Core Blazor WebAssembly yerel bağımlılıkları.
WebAssembly Önceden Derleme (AOT) derlemesi ve çalışma zamanı yeniden bağlama
Blazor WebAssembly , .NET kodunuzu doğrudan WebAssembly'ye derleyebileceğiniz önceden derleme (AOT) desteğine sahiptir. AOT derlemesi, daha büyük bir uygulama boyutu pahasına çalışma zamanı performansında iyileştirmeler sağlar. .NET WebAssembly çalışma zamanının yeniden bağlanması kullanılmayan çalışma zamanı kodunu kırparak indirme hızını artırır. Daha fazla bilgi için bkz. Önceden (AOT) derleme ve Çalışma zamanı yeniden bağlama.
** Önceden oluşturulmuş durumu kalıcı hale getirmek
Blazor , uygulama tam olarak yüklendiğinde durumun yeniden oluşturulması gerekmeyecek şekilde önceden oluşturulmuş bir sayfada kalıcı durumu destekler. Daha fazla bilgi için bkz . ASP.NET Core Razor bileşenlerini MVC veya Razor Pages ile tümleştirme.
Hata sınırları
Hata sınırları, kullanıcı arabirimi düzeyinde özel durumları işlemek için kullanışlı bir yaklaşım sağlar. Daha fazla bilgi için bkz . ASP.NET Core Blazor uygulamalarında hataları işleme.
SVG desteği
<foreignObject> öğesi, SVG içinde rastgele HTML görüntülemek için desteklenir. Daha fazla bilgi için ASP.NET Core Razor bileşenleri bölümüne bakın.
Blazor Server Birlikte Çalışma'da JS bayt dizisi aktarımı desteği
Blazor , bayt dizilerinin Base64'e kodlanması ve kodunun çözülmesinden kaçınan geliştirilmiş bayt dizisi birlikte çalışabilirliğini destekler. Daha fazla bilgi için aşağıdaki kaynaklara bakın:
- ASP.NET Core Blazor'da .NET yöntemlerinden JavaScript işlevlerini çağırma
- ASP.NET Core Blazor'da JavaScript işlevlerinden .NET yöntemlerini çağırma
Sorgu dizesi iyileştirmeleri
Sorgu dizeleriyle çalışma desteği geliştirildi. Daha fazla bilgi için bkz. ASP.NET Çekirdek Blazor gezintisi.
Birden çok seçmek için bağlama
Birden çok seçenek seçimi, <input> öğeleri ile bağlama tarafından desteklenir. Daha fazla bilgi için aşağıdaki kaynaklara bakın:
Baş (<head>) içerik denetimi
Razorbileşenleri, sayfanın başlığını (öğesi) ayarlama ve meta verileri (<head><title>öğeler) değiştirme dahil olmak üzere sayfanın HTML <meta> öğesi içeriğini değiştirebilir. Daha fazla bilgi için bkz. ASP.NET Core <head> uygulamalarında içeriği denetlemeBlazor.
Angular ve React bileşenleri oluşturma
Razor bileşenlerinden, Angular veya React gibi web çerçeveleri için çerçeveye özgü JavaScript bileşenleri oluşturun. Daha fazla bilgi için ASP.NET Core Razor bileşenleri bölümüne bakın.
JavaScript ile bileşenleri render etme
Mevcut JavaScript uygulamaları için Razor bileşenlerini JavaScript'ten dinamik olarak oluşturun. Daha fazla bilgi için ASP.NET Core Razor bileşenleri bölümüne bakın.
Özel öğeler
Standart HTML arabirimlerini kullanan özel öğeler oluşturmak için deneysel destek sağlanır. Daha fazla bilgi için ASP.NET Core Razor bileşenleri bölümüne bakın.
Bileşen genel türlerini ata bileşenlerinden çıkar
Bir ata bileşeni, yeni [CascadingTypeParameter] özniteliğini kullanarak bir tür parametresini ada göre alt bileşenlere iletebilir. Daha fazla bilgi için ASP.NET Core Razor bileşenleri bölümüne bakın.
Dinamik olarak işlenen bileşenler
Bileşenleri türe göre işlemek için yeni yerleşik DynamicComponent bileşeni kullanın. Daha fazla bilgi için bkz. Dinamik olarak işlenmiş ASP.NET Çekirdek Razor bileşenleri.
Geliştirilmiş Blazor erişilebilirlik
Kullanıcı arabirimi odağını bir sayfadan diğerine geçtikten sonra CSS seçicisini temel alan bir öğeye ayarlamak için yeni FocusOnNavigate bileşeni kullanın. Daha fazla bilgi için bkz . ASP.NET Çekirdek Blazor yönlendirme.
Özel etkinlik argümanı desteği
Blazor özel olay bağımsız değişkenlerini destekler. Bu, özel olaylarla .NET olay işleyicilerine rastgele veriler geçirmenizi sağlar. Daha fazla bilgi için bkz . ASP.NET Core Blazor olay işleme.
Gerekli parametreler
Gerekli bir bileşen parametresini belirtmek için yeni [EditorRequired] özniteliği uygulayın. Daha fazla bilgi için ASP.NET Core Razor bileşenleri bölümüne bakın.
Sayfalar, görünümler ve bileşenlerle JavaScript dosyalarının birlikte yerleştirilmesi
Uygulamadaki betikleri düzenlemenin kullanışlı bir yolu olarak, JavaScript dosyalarını sayfalar, görünümler ve Razor bileşenler için bir araya getirin. Daha fazla bilgi için bkz. ASP.NET Core Blazor JavaScript interoperabilite (JSinterop).
JavaScript başlatıcıları
JavaScript başlatıcıları bir Blazor uygulama yüklenmeden önce ve yükledikten sonra mantık yürütür. Daha fazla bilgi için bkz. ASP.NET Core Blazor JavaScript interoperabilite (JSinterop).
JavaScript canlı birlikte çalışma uyumluluğu
Blazor artık .NET ve JavaScript arasında doğrudan akış verilerini destekliyor. Daha fazla bilgi için aşağıdaki kaynaklara bakın:
Genel tür kısıtlamaları
Genel tür parametreleri artık desteklenmektedir. Daha fazla bilgi için ASP.NET Core Razor bileşenleri bölümüne bakın.
WebAssembly dağıtım düzeni
Kısıtlı güvenlik ortamlarında uygulama indirmelerini etkinleştirmek Blazor WebAssembly için bir dağıtım düzeni kullanın. Daha fazla bilgi için bkz . ASP.NET Core barındırılan Blazor WebAssembly uygulamalar için dağıtım düzeni.
Yeni Blazor makaleler
Önceki bölümlerde açıklanan özelliklere Blazor ek olarak, aşağıdaki konularda yeni Blazor makaleler mevcuttur:
-
ASP.NET Core Blazor dosya indirmeleri: İstemciye verimli aktarım sağlamak için yerel
byte[]akış birlikte çalışma kullanarak bir dosyayı indirmeyi öğrenin. - görüntüleri ve belgeleri ASP.NET Core'da Blazorgörüntüleme: Görüntü ve belge verilerinin akışının nasıl yapılacağını da içeren uygulamalardaki Blazor görüntüler ve belgelerle nasıl çalışılabileceği hakkında bilgi edinin.
Blazor Hybrid uygulamaları .NET MAUI, WPF ve Windows Forms ile oluşturun.
.NET ve Blazor Hybrid ile masaüstü ve mobil yerel istemci çerçevelerini birleştirmek için Blazor kullanın.
- .NET Multi-platform App UI (.NET MAUI), C# ve XAML ile yerel mobil ve masaüstü uygulamaları oluşturmaya yönelik platformlar arası bir çerçevedir.
- Blazor Hybrid uygulamalar Windows Presentation Foundation (WPF) ve Windows Forms çerçeveleriyle oluşturulabilir.
Önemli
Blazor Hybrid önizleme aşamasındadır ve son sürüme kadar üretim uygulamalarında kullanılmamalıdır.
Daha fazla bilgi için aşağıdaki kaynaklara bakın:
- ASP.NET Core belgelerini önizleyin Blazor Hybrid
- .NET MAUINedir?
- Microsoft .NET Blogu (kategori: ".NET MAUI")
Kestrel
HTTP/3 şu anda taslaktadır ve bu nedenle değiştirilebilir. ASP.NET Core'da HTTP/3 desteği yayımlanmaz, .NET 6'da bulunan bir önizleme özelliğidir.
Kestrel artık HTTP/3'i destekliyor. Daha fazla bilgi için bkz. ASP.NET Core Kestrel web sunucusuyla HTTP/3 kullanma ve .NET 6'da HTTP/3 desteği blog girdisi.
Seçili kayıt işlemi için yeni Kestrel kayıt kategorileri
Bu değişiklikten önce, Kestrel günlüğü kategori adı olarak kullanıldığı için Kestrel için ayrıntılı günlük kaydını etkinleştirmek, Microsoft.AspNetCore.Server.Kestrel açısından çok pahalıydı.
Microsoft.AspNetCore.Server.Kestrel hala kullanılabilir durumdadır, ancak aşağıdaki yeni alt kategoriler loglamayı daha iyi kontrol etmeye olanak tanır.
-
Microsoft.AspNetCore.Server.Kestrel(geçerli kategori):ApplicationError,ConnectionHeadResponseBodyWrite,ApplicationNeverCompleted,RequestBodyStart, ,RequestBodyDone,RequestBodyNotEntirelyRead,RequestBodyDrainTimedOut,ResponseMinimumDataRateNotSatisfiedInvalidResponseHeaderRemoved,HeartbeatSlow. -
Microsoft.AspNetCore.Server.Kestrel.BadRequests:ConnectionBadRequest,RequestProcessingError,RequestBodyMinimumDataRateNotSatisfied. -
Microsoft.AspNetCore.Server.Kestrel.Connections:ConnectionAccepted,ConnectionStart,ConnectionStop, ,ConnectionPause,ConnectionResume,ConnectionKeepAlive,ConnectionRejected,ConnectionDisconnect,NotAllConnectionsClosedGracefully,NotAllConnectionsAbortedApplicationAbortedConnection. -
Microsoft.AspNetCore.Server.Kestrel.Http2:Http2ConnectionError,Http2ConnectionClosing,Http2ConnectionClosed, ,Http2StreamError,Http2StreamResetAbort,HPackDecodingError,HPackEncodingError,Http2FrameReceived,Http2FrameSendingHttp2MaxConcurrentStreamsReached. -
Microsoft.AspNetCore.Server.Kestrel.Http3:Http3ConnectionError,Http3ConnectionClosing,Http3ConnectionClosed,Http3StreamAbort,Http3FrameReceived,Http3FrameSending.
Mevcut kurallar çalışmaya devam ediyor, ancak artık hangi kuralları etkinleştirdiğiniz konusunda daha seçici olabilirsiniz. Örneğin, yalnızca hatalı istekler için günlüğe kaydetmeyi etkinleştirmenin Debug gözlemlenebilirlik yükü büyük ölçüde azalır ve aşağıdaki yapılandırmayla etkinleştirilebilir:
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft.AspNetCore": "Warning",
"Microsoft.AspNetCore.Kestrel.BadRequests": "Debug"
}
}
Kayıt filtreleme, en uzun eşleşen kategori ön ekiyle kuralları uygular. Daha fazla bilgi için bkz. Filtreleme kuralları nasıl uygulanır?
EventSource olayı aracılığıyla KestrelServerOptions yayma
KestrelEventSource, belirli bir ayrıntı düzeyiyle etkinleştirildiğinde JSON ile serileştirilmiş KestrelServerOptions öğesini içeren yeni bir olay yayarEventLevel.LogAlways. Bu olay, toplanan izlemeleri analiz ederken sunucu davranışı hakkında mantık yürütmeyi kolaylaştırır. Aşağıdaki JSON, olay yükünün bir örneğidir:
{
"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"
}
]
}
Reddedilen HTTP istekleri için yeni DiagnosticSource olayı
Kestrel şimdi sunucu katmanında reddedilen HTTP istekleri için yeni DiagnosticSource bir olay yayar. Bu değişiklik öncesinde bu reddedilen istekleri gözlemlemenin hiçbir yolu yoktu. Yeni DiagnosticSource olay Microsoft.AspNetCore.Server.Kestrel.BadRequest, isteği reddetme nedenini incelemek için kullanılabilecek bir IBadRequestExceptionFeature içerir.
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();
}
Daha fazla bilgi için Kestrel içinde günlüğe kaydetme ve tanılama bkz.
Kabul Etme Soketinden ConnectionContext Oluşturma
Yeni SocketConnectionContextFactory, kabul edilen bir yuvadan ConnectionContext oluşturmayı mümkün kılar. Bu, IConnectionListenerFactory gerçekleşen tüm performans çalışmalarını ve havuz oluşturmayı kaybetmeden özel bir yuva tabanlı derlemeyi mümkün kılar.
Bunun nasıl kullanılacağını gösteren SocketConnectionContextFactory bakın.
Kestrel Visual Studio için varsayılan başlatma profilidir
Tüm yeni dotnet web projeleri için varsayılan başlatma profili şeklindedir Kestrel. Başlangıç Kestrel önemli ölçüde daha hızlıdır ve uygulama geliştirirken daha hızlı yanıt veren bir deneyime neden olur.
IIS Express, Windows Kimlik Doğrulaması veya bağlantı noktası paylaşımı gibi senaryolar için başlatma profili olarak kullanılabilir.
için Kestrel Localhost bağlantı noktaları rastgeledir
Daha fazla bilgi için bu belgede Kestrel için şablon tarafından oluşturulan bağlantı noktalarına bakın.
Kimlik doğrulaması ve yetkilendirme
Kimlik doğrulama sunucuları
.NET 3 ile .NET 5 arasında, SPA ve uygulamalar için JWT belirteçlerinin verilmesini desteklemek üzere şablonumuzun bir parçası olarak Blazor kullanıldı. Şablonlar artık Duende Identity Sunucusu'nu kullanır.
Kimlik modellerini genişletiyorsanız ve var olan projeleri güncelleştiriyorsanız, kodunuzdaki ad alanlarını IdentityServer4.IdentityServerDuende.IdentityServer güncelleştirin ve geçiş yönergelerini izleyin.
Duende Identity Server'ın lisans modeli, ticari olarak üretimde kullanıldığında lisans ücretleri gerektirebilecek karşılıklı lisans olarak değiştirildi. Daha fazla ayrıntı için Duende lisans sayfasına bakın.
Gecikmeli istemci sertifikası anlaşması
Geliştiriciler artık üzerinde ClientCertificateMode.DelayCertificateHttpsConnectionAdapterOptionsbelirterek gecikmeli istemci sertifikası anlaşması kullanmayı kabul edebilir. Bu yalnızca HTTP/1.1 bağlantılarında çalışır çünkü HTTP/2, sertifika yeniden anlaşmasını geciktirmesini yasaklar. Bu API'yi çağıran, istemci sertifikasını istemeden önce istek gövdesini tampon bellekte saklamalıdır.
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 yenilemeyi denetleme cookie olayı
Cookie kimlik doğrulaması oturum süresinin bitişi artık yeni OnCheckSlidingExpiration kullanılarak özelleştirilebilir veya kaldırılabilir. Örneğin, bu olay, kimlik doğrulama oturumunu etkilemeden sunucuda düzenli aralıklarla ping işlemi yapması gereken tek sayfalı bir uygulama tarafından kullanılabilir.
Çeşitli
Anında Yeniden Yükleme
Sık Erişimli Yeniden Yükleme'yi kullanarak daha hızlı ve daha üretken bir geliştirici deneyimi için uygulama durumunu kaybetmeden çalışan uygulamalarda kullanıcı arabirimi ve kod güncelleştirmeleri yapın. Daha fazla bilgi için ASP.NET Core için .NET Sık Erişimli Yeniden Yükleme desteği ve .NET Sık Erişimli Yeniden Yükleme gelişimi ve Visual Studio 2022 Öne Çıkanlarındaki güncellemeler bölümüne bakın.
Geliştirilmiş tek sayfalı uygulama (SPA) şablonları
ASP.NET Core proje şablonları, Angular ve React için güncelleştirilerek, modern ön uç web geliştirme için ortak desenlerle daha esnek ve daha yakından uyumlu tek sayfalı uygulamalar için geliştirilmiş bir desen kullanacak şekilde güncelleştirildi.
Daha önce Angular ve React için ASP.NET Core şablonu, geliştirme sırasında özel ara yazılımı kullanarak ön uç çerçevesi için geliştirme sunucusunu ve ardından ASP.NET Core'dan geliştirme sunucusuna ara sunucu isteklerini başlatmıştı. Ön uç geliştirme sunucusunu başlatma mantığı, ilgili ön uç çerçevesi için komut satırı arabirimine özeldi. Bu deseni kullanarak ek ön uç çerçevelerinin desteklenmesi, ASP.NET Core'a ek mantık eklemek anlamına geliyordu.
.NET 6'da Angular ve React için güncellenmiş ASP.NET Core şablonları, bu düzeni tersine çevirir ve çoğu modern ön uç çerçevesinin geliştirme sunucularındaki yerleşik ara sunucu desteğinden faydalanır. ASP.NET Core uygulaması başlatıldığında, ön uç geliştirme sunucusu daha önce olduğu gibi başlatılır, ancak geliştirme sunucusu arka uç ASP.NET Core işlemine ara sunucu istekleri için yapılandırılır. Ara sunucu kurulumuna yönelik ön uca özgü yapılandırmaların tümü, ASP.NET Core'un değil uygulamanın bir parçasıdır. ASP.NET Core projelerini diğer ön uç çerçeveleriyle çalışacak şekilde ayarlama işlemi artık doğrudan yapılır: Angular ve React şablonlarında oluşturulan deseni kullanarak seçilen çerçeve için ön uç geliştirme sunucusunu ASP.NET Core arka ucuna proxy olarak ayarlayın.
ASP.NET Core uygulamasının başlangıç koduna artık tek sayfalı uygulamaya özgü mantık gerekmez. Geliştirme sırasında ön uç geliştirme sunucusunu başlatma mantığı, yeni Microsoft.AspNetCore.SpaProxy paketi tarafından çalışma zamanında uygulamaya ekleniyor. Geri dönüş yönlendirme, SPA'ya özgü ara yazılım yerine uç nokta yönlendirmesi kullanılarak işlenir.
Bu deseni izleyen şablonlar Visual Studio'da tek bir proje olarak veya komut satırından kullanılarak dotnet run çalıştırılabilir. Uygulama yayımlandığında ClientApp klasöründeki ön uç kodu, ana bilgisayar ASP.NET Core uygulamasının web kökünde daha önce olduğu gibi derlenir ve toplanır ve statik dosyalar olarak hizmet verir. Şablonda yer alan betikler, ön uç geliştirme sunucusunu ASP.NET Core geliştirme sertifikasını kullanarak HTTPS kullanacak şekilde yapılandırılır.
.NET 6'da taslak HTTP/3 desteği
HTTP/3 şu anda taslaktadır ve bu nedenle değiştirilebilir. ASP.NET Core'da HTTP/3 desteği yayımlanmaz, .NET 6'da bulunan bir önizleme özelliğidir.
.NET 6'da HTTP/3 desteği blog girdisine bakın.
Boş Atanabilir Referans Türü Açıklamaları
.NET 6 kaynak kodundaki ASP.NET Core'un bazı bölümleri için null atanabilirlik açıklamaları uygulandı.
ASP.NET Core, C# 8'deki yeni Null atanabilir özelliğinden yararlanarak başvuru türlerinin işlenmesinde ek derleme zamanı güvenliği sağlayabilir. Örneğin, null referans istisnalarına karşı korunma. Null atanabilir ek açıklamaları kullanmayı kabul eden projeler, ASP.NET Çekirdek API'lerinden gelen yeni derleme zamanı uyarıları görebilir.
Null atanabilir başvuru türlerini etkinleştirmek için proje dosyalarına aşağıdaki özelliği ekleyin:
<PropertyGroup>
<Nullable>enable</Nullable>
</PropertyGroup>
Daha fazla bilgi için bkz. Null atanabilir başvuru türleri.
Kaynak Kodu Analizi
Yanlış ara yazılım yapılandırması veya sırası, yönlendirme çakışmaları gibi sorunlar için uygulama kodunu inceleyen çeşitli .NET derleyici platformu çözümleyicileri eklendi. Daha fazla bilgi için bkz. ASP.NET Core uygulamalarında kod analizi.
Web uygulaması şablonu geliştirmeleri
Web uygulaması şablonları:
- Yeni minimal barındırma modelini kullanın.
- Uygulama oluşturmak için gereken dosya ve kod satırlarının sayısını önemli ölçüde azaltır. Örneğin, ASP.NET Core boş web uygulaması dört kod satırı içeren bir C# dosyası oluşturur ve tam kapsamlı bir uygulamadır.
-
Startup.csveProgram.csöğesini tekProgram.csbir dosyada birleştirir. - Bir uygulama için gereken kodu en aza indirmek için üst düzey deyimleri kullanır.
- Gerekli
usingdeyim satırı sayısını ortadan kaldırmak veya en aza indirmek için genelusingyönergeleri kullanır.
Şablon tarafından oluşturulan Kestrel için bağlantı noktaları
Proje oluşturma sırasında web sunucusu tarafından kullanılmak üzere rastgele portlar atanır. Rastgele bağlantı noktaları, aynı makinede birden çok proje çalıştırıldığında bağlantı noktası çakışmasını en aza indirmeye yardımcı olur.
Proje oluşturulduğunda, oluşturulan Properties/launchSettings.json dosyada 5000-5300 arasında rastgele bir HTTP bağlantı noktası ve 7000-7300 arasında rastgele bir HTTPS bağlantı noktası belirtilir. Bağlantı noktaları Properties/launchSettings.json dosyasında değiştirilebilir. Bağlantı noktası belirtilmezse, Kestrel varsayılan olarak HTTP 5000 ve HTTPS 5001 bağlantı noktaları kullanılır. Daha fazla bilgi için bkz . ASP.NET Core Kestrel web sunucusu için uç noktaları yapılandırma.
Yeni günlük varsayılanları
Hem appsettings.json hem de appsettings.Development.json için aşağıdaki değişiklikler yapıldı:
- "Microsoft": "Warning",
- "Microsoft.Hosting.Lifetime": "Information"
+ "Microsoft.AspNetCore": "Warning"
"Microsoft": "Warning"'dan "Microsoft.AspNetCore": "Warning"'e olan değişiklik, Microsoft, Microsoft.AspNetCore ad alanından gelen tüm bilgilendirme iletilerini günlüğe kaydetmeye neden olur. Örneğin, Microsoft.EntityFrameworkCore artık bilgi düzeyinde günlüğe kaydediliyor.
Geliştirici özel durum sayfası Orta Katman Yazılımı otomatik olarak eklendi
Geliştirme ortamında, DeveloperExceptionPageMiddleware varsayılan olarak eklenir. Artık web kullanıcı arabirimi uygulamalarına aşağıdaki kodu eklemek gerekli değildir:
if (app.Environment.IsDevelopment())
{
app.UseDeveloperExceptionPage();
}
HttpSysServer'da Latin1 kodlanmış istek üst bilgileri desteği
HttpSysServer artık Latin1 kodlamasıyla kodlanmış istek üst bilgilerini UseLatin1RequestHeaders üzerinde HttpSysOptions özelliğini true olarak ayarlayarak çözmeyi destekliyor:
var builder = WebApplication.CreateBuilder(args);
builder.WebHost.UseHttpSys(o => o.UseLatin1RequestHeaders = true);
var app = builder.Build();
app.MapGet("/", () => "Hello World!");
app.Run();
ASP.NET Çekirdek Modülü günlükleri zaman damgalarını ve PID'yi içerir
IIS (ANCM) için ASP.NET Çekirdek Modülü (ANCM) gelişmiş tanılama günlükleri, günlükleri yayan işlemin zaman damgalarını ve PID'lerini içerir. IIS'de birden çok çalışan işlem çalışırken zaman damgalarının ve PID'nin kaydedilmesi, çakışan işlem yeniden başlatmalarıyla ilgili sorunları tanılamayı kolaylaştırır.
Sonuçta elde edilen günlükler artık aşağıdaki örnek çıkış gösterisine benzer:
[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: ''
IIS için özelleştirilebilir, kullanılmamış arabellek boyutu
IIS sunucusu daha önce yalnızca 64 KiB'lık, tüketilmeyen istek gövdelerini arabelleğe alıyordu. 64 KiB'lik arabelleğe alma, okumaların bu maksimum boyutla sınırlanmasına neden olur ve bu da yüklemeler gibi büyük gelen verilerin performansını etkiler. .NET 6'da varsayılan arabellek boyutu 64 KiB'den 1 MiB'a değişir ve bu da büyük yüklemeler için aktarım hızını geliştirmelidir. Testlerimizde, 9 saniye süren 700 MiB'lık karşıya yükleme işlemi artık yalnızca 2,5 saniye sürüyor.
Daha büyük bir arabellek boyutunun dezavantajı, uygulama istek gövdesinden hızlı bir şekilde okumadığında istek başına bellek tüketiminin artmasıdır. Bu nedenle, varsayılan arabellek boyutunu değiştirmenin yanı sıra, arabellek boyutu yapılandırılabilir ve uygulamaların arabellek boyutunu iş yüküne göre yapılandırmasına olanak sağlar.
Bileşenler Etiketi Yardımcılarını Görüntüle
Aşağıdaki kodda gösterildiği gibi isteğe bağlı parametreye sahip bir görünüm bileşeni düşünün:
class MyViewComponent
{
IViewComponentResult Invoke(bool showSomething = false) { ... }
}
.NET 6'da ASP.NET Core ile etiket yardımcısı parametresi için showSomething bir değer belirtmek zorunda kalmadan çağrılabilir:
<vc:my />
Angular şablonu Angular 12'ye güncelleştirildi
Angular için .NET 6'da ASP.NET Core şablonu artık Angular 12 kullanıyor.
React şablonu React 17 olarak güncelleştirildi.
Json.NET çıktı biçimlendiricisinde diske yazmadan önce yapılandırılabilir arabellek eşiği belirleme
Not: Uyumluluk nedeniyle seri hale getiricinin System.Text.Json gerekli olduğu durumlar dışında çıkış biçimlendiricisini Newtonsoft.Json kullanmanızı öneririz. Serileştirici System.Text.Json tamamen async ve daha büyük yükler için etkili bir şekilde çalışır.
Çıkış Newtonsoft.Json biçimlendiricisi varsayılan olarak diske arabelleğe almadan önce bellekte 32 KiB'a kadar olan yanıtları arabelleğe alır. Bu, iş parçacığı açlığı ve uygulama kilitlenmeleri gibi yan etkiler oluşturabilecek senkron GÇ işlemlerinden kaçınmak içindir. Ancak, yanıt 32 KiB'tan büyükse, önemli miktarda disk giriş/çıkış gerçekleşir. Bellek eşiği, artık diske arabelleğe alınmadan önce MvcNewtonsoftJsonOptions.OutputFormatterMemoryBufferThreshold özelliği üzerinden yapılandırılabilir.
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddRazorPages()
.AddNewtonsoftJson(options =>
{
options.OutputFormatterMemoryBufferThreshold = 48 * 1024;
});
var app = builder.Build();
Daha fazla bilgi için bu GitHub çekme isteğine ve NewtonsoftJsonOutputFormatterTest.cs dosyasına bakın.
HTTP üst bilgileri için daha hızlı okuma ve ayarlama
Microsoft.Net.Http.Headers.HeaderNames üzerindeki tüm ortak üst bilgileri özellikler olarak IHeaderDictionary'de kullanılabilecek şekilde sunan yeni API'ler eklendi, böylece daha kullanışlı bir API ortaya çıktı. Örneğin, aşağıdaki koddaki satır içi ara yazılım, yeni API'leri kullanarak hem istek hem de yanıt üst bilgilerini alır ve ayarlar:
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();
Uygulanan üst bilgiler için get ve set erişimcileri doğrudan alana gidip aramayı atlayarak uygulanır. Uygulanmamış üst bilgiler için, erişim yöntemleri uygulanmış üst bilgilere karşı yapılan ilk aramayı atlayabilir ve Dictionary<string, StringValues> aramayı doğrudan gerçekleştirebilir. Aramanın engellenmesi her iki senaryo için de daha hızlı erişim sağlar.
Asenkron akış
ASP.NET Core artık denetleyici eylemlerinden zaman uyumsuz akışı ve JSON biçimlendiricisinden gelen yanıtları destekliyor. Bir eylemden IAsyncEnumerable döndürülmesi, yanıt içeriği gönderilmeden önce artık bellekte arabelleğe alınmaz. Belleğe alınmaması, eşzamansız olarak işlenebilen büyük veri kümeleri döndürürken bellek kullanımını azaltmaya yardımcı olur.
Entity Framework Core'un, IAsyncEnumerable uygulamalarını veritabanını sorgulamak için sağladığını unutmayın. .NET 6'da ASP.NET Core'de IAsyncEnumerable için geliştirilmiş destek, EF Core'in ASP.NET Core ile kullanımını daha verimli hale getirebilir. Örneğin, aşağıdaki kod artık yanıtı göndermeden önce ürün verilerini belleğe yüklemez.
public IActionResult GetMovies()
{
return Ok(_context.Movie);
}
Ancak içinde gecikmeli yükleme EF Corekullanılırken bu yeni davranış, veriler numaralandırılırken eşzamanlı sorgu yürütme nedeniyle hatalara neden olabilir. Uygulamalar verileri arabelleğe alarak önceki davranışa geri dönebilir:
public async Task<IActionResult> GetMovies2()
{
return Ok(await _context.Movie.ToListAsync());
}
Davranıştaki bu değişiklik hakkında ek ayrıntılar için ilgili duyuruya bakın.
HTTP günlüğü ara yazılımı
HTTP günlüğü, başlıklar ve tüm gövde dahil HTTP istekleri ve HTTP yanıtları hakkındaki bilgileri günlüğe kaydeden yeni bir yerleşik ara yazılımdır.
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.UseHttpLogging();
app.MapGet("/", () => "Hello World!");
app.Run();
"/ adresine önceki kodla gitmek, aşağıdaki çıktıya benzer bilgileri günlüğe kaydeder:"
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
Yukarıdaki çıkış aşağıdaki appsettings.Development.json dosyayla etkinleştirildi:
{
"Logging": {
"LogLevel": {
"Default": "Information",
"Microsoft.AspNetCore": "Warning",
"Microsoft.AspNetCore.HttpLogging.HttpLoggingMiddleware": "Information"
}
}
}
HTTP günlüğü şu günlükleri sağlar:
- HTTP İstek bilgileri
- Ortak özellikler
- Başlıklar
- Vücut
- HTTP Yanıt bilgileri
HTTP günlüğü ara yazılımını yapılandırmak için HttpLoggingOptions belirtmeniz gerekir.
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();
Bağlantı Soket Özelliği (IConnectionSocketFeature)
Talep işlevi, IConnectionSocketFeature geçerli istekle ilişkili altta yatan kabul soketine erişim sağlar.
FeatureCollection
HttpContext üzerinden erişilebilir.
Örneğin, aşağıdaki uygulama, kabul edilen sokette LingerState özelliğini ayarlar:
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();
"Genel tür kısıtlamaları Razor içinde"
yönergesini Razor kullanarak içindeki @typeparam genel tür parametrelerini tanımlarken, genel tür kısıtlamaları artık standart C# söz dizimi kullanılarak belirtilebilir:
Daha küçük SignalR, Blazor Server, ve daha küçük MessagePack betikleri
SignalR, MessagePack ve Blazor Server betikler artık önemli ölçüde daha küçüktür ve daha küçük indirmelere, tarayıcı tarafından daha az JavaScript ayrıştırma ve derlemeye ve daha hızlı başlatmaya olanak tanır. Boyut azaltmaları:
-
signalr.js: 70% -
blazor.server.js: 45%
Daha küçük betikler, Ben Adams tarafından topluluğa yapılan katkının bir sonucudur. Boyut küçültme ayrıntıları hakkında daha fazla bilgi için Ben'in GitHub çekme isteğine bakın.
Redis profil oluşturma oturumlarını etkinleştirme
Gabriel Lucaci'nin topluluk katkılarından biri, Microsoft.Extensions.Caching.StackExchangeRedis ile Redis profil oluşturma oturumuna olanak tanır:
using StackExchange.Redis.Profiling;
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddStackExchangeRedisCache(options =>
{
options.ProfilingSession = () => new ProfilingSession();
});
Daha fazla bilgi için bkz. StackExchange.Redis Profiling.
IIS'de gölge kopyalama
Iis için ASP.NET Çekirdek Modülü'ne (ANCM)gölge kopyalama uygulama derlemeleri için destek eklemek üzere deneysel bir özellik eklendi. Şu anda .NET, Windows üzerinde çalışırken uygulama ikili dosyalarını kilitler ve bu da uygulama çalışırken ikili dosyaların değiştirilmesini imkansız hale getirir. Önerimiz bir uygulama çevrimdışı dosyasını kullanmaya devam ederken, bunun mümkün olmadığı bazı senaryolar (örneğin FTP dağıtımları) olduğunu biliyoruz.
Bu tür senaryolarda, ASP.NET Core modül işleyici ayarlarını özelleştirerek gölge kopyalamayı etkinleştirin. Çoğu durumda, ASP.NET Core uygulamalarında değiştirebileceğiniz bir web.config kaynak denetimi yoktur. ASP.NET Core'da normalde web.config SDK tarafından oluşturulur. Başlamak için aşağıdaki örnek web.config kullanılabilir:
<?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>
IIS'de gölge kopyalama, ASP.NET Core'un parçası olacağı garanti edilmeyen deneysel bir özelliktir. Lütfen bu GitHub sorununda IIS Gölge kopyalama hakkında geri bildirimde bulunabilirsiniz.
Kritik değişiklikler
Bir uygulamayı daha yeni bir .NET sürümüne yükseltirken uygulanabilecek hataya neden olabilecek değişiklikleri bulmak için .NET'te hataya neden olan değişiklikler makalelerini kullanın.
Ek kaynaklar
ASP.NET Core