Aracılığıyla paylaş

ASP.NET Core 6.0'daki yenilikler

  • Makale

Bu makalede, ilgili belgelerin bağlantıları ile ASP.NET Core 6.0'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 bkz.

SignalR

Bağlantılar için SignalR uzun süre çalışan etkinlik etiketi

SignalR, istek etkinliğine etiket http.long_running eklemek için yeniyi Microsoft.AspNetCore.Http.Features.IHttpActivityFeature.Activity kullanır. IHttpActivityFeature.Activity, Azure İzleyici Application Insights gibi APM hizmetleri tarafından uzun süre çalışan istek uyarıları oluşturma isteklerini filtrelemek SignalR için kullanılır.

SignalR performans geliştirmeleri

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 yanı sıra rest 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ında AspNetCoreGeneratedDocument iç korumalı olarak varsayılan olarak 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 Çalışırken Yeniden Yükleme katılmasına olanak tanır.

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ı:

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. Bunun nedeni, , SslStreamve Kestreliçindeki System.IO.Pipelinesçok sayıda geliştirmedir. 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üçültme System.IO.Pipelines.Pipe

Kurulan her bağlantı için içinde iki boru ayrılır Kestrel:

  • İstek için uygulamaya aktarım katmanı.
  • Yanıt için aktarıma yönelik uygulama katmanı.

Boyutu 368 bayttan 264 bayta (yaklaşık %28,2 azalma) küçülterek System.IO.Pipelines.Pipe , bağlantı başına 208 bayt (Kanal başına 104 bayt) kaydedilir.

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 nesneleri havuza alabilirsiniz. Havuza alma, bağlantı başına ek yükü azaltır. Bağlantı başına 350 bayt ayırmak yerine, yalnızca 350 bayt başına IOQueue ödeme ayrılır. Çakışmayı önlemek için kuyruk başına ayırma gerçekleştirilir. 5000 boşta bağlantısı olan WebSocket sunucumuz , ~1,75 MB (350 bayt * 5000) ayırmadan nesneler için SocketSender ~2,8 kb (350 bayt * 8) ayırmaya geçti.

SslStream ile sıfır bayt okuma

Arabelleksiz okumalar, yuvada kullanılabilir veri yoksa bellek havuzundan bellek kiralamayı önlemek için ASP.NET Core'da 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), Kestrel okumaların SslStream tamamlanmasını beklerken bir ArrayPool<T> arabelleğe tutunmak zorunda kaldı. 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 döndürdü ve daha fazla bellek ayırmaya ArrayPool zorlandı. Kalan ayırmalar kendi içindeydi SslStream : TLS el sıkışmaları için 4k arabellek ve normal okumalar için 32k arabellek. .NET 6'da, kullanıcı sıfır bayt okuma SslStream işlemi gerçekleştirdiğinde ve kullanılabilir veri olmadığında, SslStream temel alınan sarmalanmış akışta dahili olarak sıfır bayt okuma gerçekleştirir. En iyi durumda (boşta bağlantı), bu değişiklikler bağlantı başına 40 Kb tasarruf sağlarken, kullanılmayan arabellekleri tutmadan veriler kullanılabilir olduğunda tüketiciye (Kestrel) bildirim göndermeye devam eder.

PipeReader ile sıfır bayt okuma

üzerinde desteklenen arabelleğez okumalar ile SslStreamöğesine sıfır bayt okuma StreamPipeReaderişlemi gerçekleştirme seçeneği eklendi ve bunu içine Stream PipeReaderuyarlayan iç tür. içinde Kestrel,StreamPipeReader temel alınan SslStream öğesini bir PipeReaderiçine uyarlamak için kullanılır. Bu nedenle bu sıfır bayt okuma semantiğini üzerinde PipeReaderkullanıma sunmam gerekiyordu.

PipeReader Artık aşağıdaki API kullanılarak sıfır bayt okuma semantiğini (örn. , vbNetworkStream.SslStream) destekleyen herhangi bir temel Stream alınan üzerinde sıfır bayt okumasını destekleyen bir oluşturulabilir:

var reader = PipeReader.Create(stream, new StreamPipeReaderOptions(useZeroByteReads: true));

Levhaları SlabMemoryPool

Yığının parçalanma oranını azaltmak için, Kestrel bellek havuzunun bir parçası olarak 128 KB bellek levhaları ayırdığı bir teknik kullandı. Daha sonra döşemeler, dahili olarak kullanılan Kestrel 4 KB bloğuna 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ır. 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 temsilci olarak atanan ve çağıran Disposevarsayılan bir arabirim uygulaması sunar.
  • Uygulamalar varsayılan uygulamayı geçersiz kılar ve kullanımdan kaldırma IAsyncDisposable uygulamalarını işler.
  • Her iki arabirim de uygulandığında uygulamalar IAsyncDisposable IDisposable tercih edilir.
  • 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:

  • Zaman uyumsuz numaralandırıcılar, örneğin zaman uyumsuz akışlarda.
  • Yayınlanması gereken yoğun kaynak kullanan G/Ç işlemlerine sahip yönetilmeyen kaynaklar.

Bu arabirimi uygularken, kaynakları serbest bırakmak için yöntemini kullanın DisposeAsync .

oluşturan ve kullanan bir Utf8JsonWriterdenetleyici 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 uygulaması DisposeAsyncgerekir:

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. C++ istemcisi için yerel destek eklemek için SignalR yakın zamanda 'a vcpkg bir bağlantı noktası ekledikCMake. 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)

Yukarıdaki kod parçacığıyla SignalR , C++ istemcisi ek yapılandırma olmadan bir projede kullanılmaya #include hazır 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 uygulamalar için Blazor dosyada _Host.cshtml görünen düzen içeriği için dosyanın kullanımı Pages/_Layout.cshtml dahil olmak üzere uygulamalar için Blazor Server ç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'de derleyebileceğiniz önceden (AOT) derlemeyi destekler. AOT derlemesi, daha büyük bir uygulama boyutuna zarar verebilirsiniz. .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 girilmiş durumu kalıcı hale

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 . Prerender ve ASP.NET Core Razor bileşenlerini 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 bkz . ASP.NET Çekirdek Razor bileşenleri.

Blazor Server Birlikte Çalışma'da JS bayt dizisi aktarımı desteği

Blazor , bayt dizilerinin JS Base64'e kodlanması ve kodunun çözülmesini önleyen iyileştirilmiş bayt dizisi birlikte çalışmasını destekler. Daha fazla bilgi edinmek için aşağıdaki kaynaklara bakın:

Sorgu dizesi geliştirmeleri

Sorgu dizeleriyle çalışma desteği geliştirildi. Daha fazla bilgi için bkz . ASP.NET Temel Blazor yönlendirme ve gezinti.

Birden çok seçmek için bağlama

Bağlama, öğelerle <input> birden çok seçenek seçimini destekler. Daha fazla bilgi edinmek 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 (<title><meta>öğeler) değiştirme dahil olmak üzere sayfanın HTML <head> öğesi içeriğini değiştirebilir. Daha fazla bilgi için bkz. ASP.NET Core Blazor uygulamalarında içeriği denetleme<head>.

Angular ve React bileşenleri oluşturma

Angular veya React gibi web çerçeveleri için bileşenlerden Razor çerçeveye özgü JavaScript bileşenleri oluşturun. Daha fazla bilgi için bkz . ASP.NET Çekirdek Razor bileşenleri.

JavaScript'ten bileşenlerini işleme

Mevcut JavaScript uygulamaları için bileşenleri JavaScript'ten dinamik olarak işleyin Razor . Daha fazla bilgi için bkz . ASP.NET Çekirdek Razor bileşenleri.

Özel öğeler

Standart HTML arabirimlerini kullanan özel öğeler oluşturmak için deneysel destek sağlanır. Daha fazla bilgi için bkz . ASP.NET Çekirdek Razor bileşenleri.

Bileşen genel türlerini ata bileşenlerinden çıkar

Bir ata bileşeni, yeni [CascadingTypeParameter] özniteliği kullanarak bir tür parametresini ada göre alt öğelere basamaklayabilir. Daha fazla bilgi için bkz . ASP.NET Çekirdek Razor bileşenleri.

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 Temel Blazor yönlendirme ve gezinti.

Özel olay bağımsız değişkeni 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 bkz . ASP.NET Çekirdek Razor bileşenleri.

Sayfalar, görünümler ve bileşenlerle JavaScript dosyalarının birlikte yerleştirilmesi

Uygulamadaki betikleri düzenlemenin kullanışlı bir yolu olarak sayfalar, görünümler ve Razor bileşenler için JavaScript dosyalarını birlikte kullanın. Daha fazla bilgi için bkz. ASP.NET Core Blazor JavaScript birlikte çalışabilirliği (JSbirlikte çalışma).

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 birlikte çalışabilirliği (JSbirlikte çalışma).

JavaScript birlikte çalışma akışı

Blazor artık .NET ve JavaScript arasında doğrudan akış verilerini destekliyor. Daha fazla bilgi edinmek 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 bkz . ASP.NET Çekirdek Razor bileşenleri.

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.
  • ASP.NET Core'da Blazorgörüntü ve belge görüntüleme: Görüntü akışı ve belge verileri de dahil olmak üzere uygulamalarda resimler ve belgelerle Blazor çalışmayı keşfedin.

, WPF ve Windows Forms ile .NET MAUIuygulama oluşturma Blazor Hybrid

Masaüstü ve mobil yerel istemci çerçevelerini .NET ve Blazorile karıştırmak için kullanınBlazor Hybrid:

  • .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 edinmek için aşağıdaki kaynaklara bakın:

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 günlük için yeni Kestrel günlük kategorileri

Bu değişiklik öncesinde, tüm günlük kategorisi adı paylaşıldığından Microsoft.AspNetCore.Server.Kestrel için Kestrel ayrıntılı günlük kaydının etkinleştirilmesi Kestrel çok pahalıydı. Microsoft.AspNetCore.Server.Kestrel hala kullanılabilir durumdadır, ancak aşağıdaki yeni alt kategoriler günlüğün daha fazla denetlenebilmesini sağlar:

  • Microsoft.AspNetCore.Server.Kestrel(geçerli kategori): ApplicationError, ConnectionHeadResponseBodyWrite, ApplicationNeverCompleted, RequestBodyStart, , RequestBodyDone, RequestBodyNotEntirelyRead, RequestBodyDrainTimedOut, InvalidResponseHeaderRemovedResponseMinimumDataRateNotSatisfied, HeartbeatSlow.
  • Microsoft.AspNetCore.Server.Kestrel.BadRequests: ConnectionBadRequest, RequestProcessingError, RequestBodyMinimumDataRateNotSatisfied.
  • Microsoft.AspNetCore.Server.Kestrel.Connections: ConnectionAccepted, ConnectionStart, ConnectionStop, , ConnectionPause, ConnectionResume, ConnectionKeepAlive, ConnectionRejected, ConnectionDisconnect, NotAllConnectionsClosedGracefully, ApplicationAbortedConnectionNotAllConnectionsAborted.
  • Microsoft.AspNetCore.Server.Kestrel.Http2: Http2ConnectionError, Http2ConnectionClosing, Http2ConnectionClosed, , Http2StreamError, Http2StreamResetAbort, HPackDecodingError, HPackEncodingError, Http2FrameReceived, Http2MaxConcurrentStreamsReachedHttp2FrameSending.
  • 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"
    }
  }

Günlük 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, ayrıntı düzeyiyle etkinleştirildiğinde JSON 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 nedenine giriş yapmak 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 bkz . içinde Kestrelgünlüğe kaydetme ve tanılama.

Kabul Yuvasından ConnectionContext Oluşturma

Yeni SocketConnectionContextFactory , kabul edilen bir yuvadan oluşturma ConnectionContext işlemini mümkün kılar. Bu, SocketConnection'da gerçekleşen tüm performans çalışmalarını ve havuz oluşturmayı kaybetmeden özel bir yuva tabanlı IConnectionListenerFactory derlemeyi mümkün kılar.

Bunun nasıl kullanılacağını SocketConnectionContextFactorygösteren bu özel IConnectionListenerFactory örneğine 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 için Kestrel şablon tarafından oluşturulan bağlantı noktaları konusuna bakın.

Kimlik doğrulaması ve yetkilendirme

Kimlik doğrulama sunucuları

.NET 3 ile .NET 5 arasında, SPA ve Blazor uygulamalar için JWT belirteçlerinin verilmesini desteklemek üzere şablonumuzun bir parçası olarak IdentityServer4 kullanıldı. Şablonlar artık Duende Identity Sunucusu'nu kullanır.

Modelleri genişletiyorsanız identity ve mevcut projeleri güncelleştiriyorsanız, kodunuzdaki ad alanlarını 'den'e IdentityServer4.IdentityServer Duende.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.DelayCertificate HttpsConnectionAdapterOptionsbelirterek 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 arabelleğe almalı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();

Cookie kimlik doğrulaması kayan süre sonu artık yeni OnCheckSlidingExpirationkullanılarak özelleştirilebilir veya gizlenebilir. Ö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

Çalışırken Yeniden Yükleme

Çalışırken Yeniden Yükleme 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 bkz. .NET Çalışırken Yeniden Yükleme ASP.NET Core desteği ve .NET Çalışırken Yeniden Yükleme ilerleme durumu ve Visual Studio 2022 Vurguları için güncelleştirme.

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üncelleştirilmiş ASP.NET Core şablonları bu düzenlemeyi tersine çevirir ve çoğu modern ön uç çerçevesinin geliştirme sunucularında yerleşik ara sunucu desteğinden yararlanıyor. 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 daha önce olduğu gibi konak ASP.NET Core uygulamasının web kökünde 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.

Null Atanabilir Başvuru Türü Ek Açıklamaları

ASP.NET Core 6.0 kaynak kodunun bazı bölümleri null atanabilirlik ek 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, başvuru özel durumlarına karşı null koruma. 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.cs ve Program.cs öğesini tek Program.cs bir dosyada birleştirir.
  • Bir uygulama için gereken kodu en aza indirmek için üst düzey deyimleri kullanır.
  • Gerekli deyim satırı sayısını using ortadan kaldırmak veya en aza indirmek için genel using yönergeleri kullanır.

için şablon tarafından oluşturulan bağlantı noktaları Kestrel

Web sunucusu tarafından Kestrel kullanılmak üzere proje oluşturma sırasında rastgele bağlantı noktaları 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ı dosyasında değiştirilebilir Properties/launchSettings.json . 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 hem de appsettings.json appsettings.Development.jsoniçin aşağıdaki değişiklikler yapıldı:

- "Microsoft": "Warning",
- "Microsoft.Hosting.Lifetime": "Information"
+ "Microsoft.AspNetCore": "Warning"

olan "Microsoft": "Warning" "Microsoft.AspNetCore": "Warning" değişikliği, dışında Microsoft.AspNetCoread alanından gelen tüm bilgi iletilerini günlüğe kaydetmeye Microsoft neden olur. Örneğin, Microsoft.EntityFrameworkCore artık bilgi düzeyinde günlüğe kaydedilir.

Geliştirici özel durum sayfası Ara 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

HttpSysServerartık özelliğini HttpSysOptions trueolarak ayarlayarak kodlanmış istek üst bilgilerinin Latin1 kodunu çözmeyi UseLatin1RequestHeaders 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. Zaman damgalarını ve PID'yi günlüğe kaydetmek, birden çok IIS çalışan işlemi çalışırken IIS'de ç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 yapılandırılabilir, tamamlanmamış gelen arabellek boyutu

IIS sunucusu daha önce yalnızca 64 KiB'lık, tamamlanmamış istek gövdesi arabelleğe alınmıştı. 64 KiB arabelleğe alma işlemi, okumaların bu maksimum boyuta kısıtlanmasıyla sonuçlanır ve bu da karşıya yüklemeler gibi büyük gelen gövdelerin 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) { ... }
}

ASP.NET Core 6 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 ASP.NET Core 6.0 şablonu artık Angular 12 kullanıyor.

React şablonu React 17 olarak güncelleştirildi.

Json.NET çıkış biçimlendiricisinde diske yazmadan önce yapılandırılabilir arabellek eşiği

Not: Uyumluluk nedeniyle seri hale getiricinin System.Text.Json gerekli olduğu durumlar dışında çıkış biçimlendiricisini Newtonsoft.Json kullanmanızı öneririz. Seri System.Text.Json hale getirici tamamen async ve daha büyük yükler için verimli 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 diğer yan etkilere neden olabilecek zaman uyumlu GÇ gerçekleştirmekten kaçınmaktır. Ancak, yanıt 32 KiB'tan büyükse, önemli miktarda disk G/Ç oluşur. Bellek eşiği artık diske arabelleğe almadan önce MvcNewtonsoftJsonOptions.OutputFormatterMemoryBufferThreshold özelliği aracılığıyla 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ı alma ve ayarlama

Üzerinde özellik IHeaderDictionary olarak kullanılabilen Microsoft.Net.Http.Headers.HeaderNames tüm ortak üst bilgileri kullanıma sunan yeni API'ler eklendi ve bu da kullanımı daha kolay bir API'ye neden oldu. Ö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. Uygulanamayan üst bilgiler için, erişimciler uygulanan üst bilgilerde ilk aramayı atlayabilir ve aramayı doğrudan gerçekleştirebilir Dictionary<string, StringValues> . Aramanın engellenmesi her iki senaryo için de daha hızlı erişim sağlar.

Zaman uyumsuz akış

ASP.NET Core artık denetleyici eylemlerinden zaman uyumsuz akışı ve JSON biçimlendiricisinden gelen yanıtları destekliyor. IAsyncEnumerable Bir eylemden döndürülerek yanıt içeriği gönderilmeden önce bellekte arabelleğe alınmaz. Arabelleğe alınmaması, zaman uyumsuz olarak numaralandırılabilir büyük veri kümelerini döndürürken bellek kullanımını azaltmaya yardımcı olur.

Entity Framework Core'un veritabanını sorgulamak IAsyncEnumerable için uygulamalarını sağladığını unutmayın. .NET 6'da ASP.NET Core'da için geliştirilmiş destek IAsyncEnumerable , ASP.NET Core ile kullanımı EF Core daha verimli hale getirebilir. Örneğin, aşağıdaki kod artık yanıt göndermeden önce ürün verilerini belleğe arabelleğe almaz:

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üğü, üst bilgiler ve tüm gövde dahil OLMAK üzere 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();

Önceki kodla adresine gitmek / , aşağıdaki çıkışa 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
  • Üst Bilgiler
  • Gövde
  • HTTP Yanıt bilgileri

HTTP günlüğü ara yazılımını yapılandırmak için belirtin 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

İstek özelliği, IConnectionSocketFeature geçerli istekle ilişkili temel alınan kabul yuvasına erişim sağlar. üzerinden erişilebilir FeatureCollection HttpContext.

Örneğin, aşağıdaki uygulama kabul edilen yuvada özelliğini ayarlar LingerState :

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

içindeki genel tür kısıtlamaları Razor

yönergesini @typeparam kullanarak içindeki Razor 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 Serverve 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'ın topluluk katkılarından kaynaklanır. Boyut azaltma ayrıntıları hakkında daha fazla bilgi için bkz . Ben'in GitHub çekme isteği.

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.

Ek kaynaklar