SEKTöR HABERLERI

.NET 11 Önizleme 3: Bir Geliştiricinin İncelemesi

.NET 11, Kasım 2026'da planlanan GA'dan yaklaşık altı ay önce üçüncü önizlemesine ulaşıyor ve Preview 1 ve 2'den farklı olarak, ki çoğunlukla tesisattı, Preview 3'te yayın şeklinin gerçekten hissettirildiği durum.

Durdur ve devam ettir pelikül özellik kapısı deneyi olmaktan çıkar, JIT başka bir ücretsiz para optimizasyonu yığını toplar, ASP.NET Core Zstandard'ı kutudan hazır alır ve C# 15, daha iyi bir on yılın bir parçasını talep eden dil özelliği birlik türlerini alır.

Bu bir LTS sürüm değil, .NET 11 sonraki Standart Süre Destek sürümü olup 24 ay destek alır, bu da yükseltip yükseltmeme hesaplayıcısını zaten değiştirir. Aşağıda, bir geliştirici olarak gerçekten dikkate değer olanlar ve hala pürüzlü olan yerler vardır.

C# 15 birlik türleri: büyük olan

Eğer OneOf<T1, T2> kütüphaneleri yazıyorsanız, mühürlü kayıt hiyerarşilerini elle oluşturuyorsanız veya sadece F# geliştiricilerini kıskanıyorsanız, işte manşet. C# 15, bir değerin tam olarak sabit bir tür kümesinden biri olduğunu beyan eden, derleyici tarafından zorunlu kapsamlılık sağlayan bir birlik anahtar kelimesi tanıtıyor. Union türleri Preview 2'ye geldi; Preview 3, IDE desteğini parlatıyor.

C# ekibinin yaklaşımı, F# ayrım gözeten birliklerinden daha çok bir tür birleşimine yakındır: üye türleri, birleşim bildirimine iç içe geçmiş etiket durumları değil, ayrı ayrı tanımladığınız mevcut türlerdir. Bir grup temelde bir nesneyi sarıp, içine ne konulabileceğini kısıtlayan bir yapı. Çağrı noktasından, doğal hissediliyor - üye türlerden birliğe örtük dönüşüm, Pet.Value üzerinde kapsamlı switch ifadeleri ve derleyici tüm durumları görebiliyorsa varsayılan bir kola gerek yok.

[Union]
public partial struct Pet : IUnion
{
    public Pet(Dog dog);
    public Pet(Cat cat);
    public Pet(Bird bird);
}

string Describe(Pet pet) => pet.Value switch
{
    Dog d  => $"Dog named {d.Name}",
    Cat c  => $"Cat ({c.Color})",
    Bird b => $"Bird, {b.Species}",
    // no default - compiler knows the set is closed
};
[Union]
public partial struct Pet : IUnion
{
    public Pet(Dog dog);
    public Pet(Cat cat);
    public Pet(Bird bird);
}

string Describe(Pet pet) => pet.Value switch
{
    Dog d  => $"Dog named {d.Name}",
    Cat c  => $"Cat ({c.Color})",
    Bird b => $"Bird, {b.Species}",
    // no default - compiler knows the set is closed
};
<Union>
Public Partial Structure Pet
    Implements IUnion

    Public Sub New(dog As Dog)
    End Sub

    Public Sub New(cat As Cat)
    End Sub

    Public Sub New(bird As Bird)
    End Sub
End Structure

Function Describe(pet As Pet) As String
    Return pet.Value Select Case
        Case d As Dog
            Return $"Dog named {d.Name}"
        Case c As Cat
            Return $"Cat ({c.Color})"
        Case b As Bird
            Return $"Bird, {b.Species}"
        ' no default - compiler knows the set is closed
    End Select
End Function
$vbLabelText   $csharpLabel

Avantajlar gerçek: kapalı türler, geçersiz durum yok, derleme zamanında kapsamlılık yerine NotImplementedExceptionat sabah 3'te. PET üzerinde her anahtarla bağlantı kurana kadar her anahtarlama aktar ışıkları ile, bir köpekbalığı birliğine ekleyin.

Eksiler de gerçek ve her dürüst incelemede işaret lemeye değer. Açık GitHub tartışması, daha güvenli bir türün arkasında saklamak için açık bir GitHub tartışmasıdır, görünür nesne Değeri özelliği bir koku. Herkise açık yapıcılar, birliğin hangi türleri kabul ettiğini tanımlar ki bu da keşfedilebilir veya açık değildir. F# birlikte çalışabilirlik, çözümlenmemiştir (iki model temelde farklıdır). Ve daha geniş exhaustiveness hikayesi hala boşluklara sahiptir: resmi tamamlayacak olan iki teklif olan kapalı hiyerarşiler ve kapalı enumlar hala tekliflerdir. Birlikler tek başına harika. Birlikler artı kapalı enumlar artı kapalı hiyerarşiler nesil değişimi olur. Tam olarak orada değiliz.

Çalışma Zamanı Async V2 ve JIT iyileştirmeleri

Çalışma Zamanı Async, .NET'in async/await'in gerçekten nasıl çalıştırıldığının sessiz yeniden yazımıdır. C# derleyicisinin her async yöntemine bir durum makinesi sınıfı yayması yerine, çalışma zamanı kendi başına askıya alma ve devam ettirmeyi yönetir. Görünür getirisi: daha temiz yığın izleri, daha küçük tahsisatlar ve bir hata ayıklayıcı bu kendi kodunuzu bulmak için MoveNext karelerinin ötesine geçmek zorunda kalmayan.

Önizleme 3'te, Runtime Async EnablePreviewFeatures gerekliliğini kaldırıyor. Özellik anahtarını hala çeviriyorsunuz - <Features>runtime-async=on</Features> - ama artık her API çağrısını önizleme alanına almak zorunda değilsiniz. NativeAOT ve ReadyToRun desteği de bu önizlemeye vardı, ki bu da JIT ve AOT senaryoları arasındaki boşluğu kapatır. Devam fonksiyonları daha agresif bir şekilde yeniden kullanılır ve değişmeyen yereller, askıya alma boyunca kaydedilmez. Async-ağır kod yollarında - bir Kestrel hattı veya bir EF Core sorgu işçisi düşünün - bu tahsis baskısında anlamlı bir düşüştür.

JIT, 'mevcut kodunuz artık daha hızlı, hiçbir şey yapmayın' şeklinde olağan bir yığın aldı:

  • x 0 veya 1 veya 2 veya 3 veya 4 gibi çok hedefli değişiklik ifadeleri şimdi dallanmayan kontrollerde birleştirilir.
  • values[^1] + values[^2] desenlerindeki sınır kontrolleri, daha agresif bir şekilde elenir ve döngülerdeki yaygın i + cns < len durumu temiz bir şekilde çöker.
  • İşaretsiz tam sayıdan yüzen nokta dönüştürmeleri ve işaretsiz tam sayıdan çift dönüştürmeleri, ön-AVX-512 x86 donanımında daha hızlıdır - eski kutular üzerinde gerçek ama çok nadir.

WebAssembly kullanıcıları, çalışma zamanı içinde doğrudan WebCIL yükü yükleme, daha iyi hata ayıklama sembolleri ve float[] / Span<float> / ArraySegment<float> yönlendirmesinden yararlanıyor, geri dönüş yükü olmadan. Bunların hiçbiri ayrı ayrı dramatik değildir, ancak birlikte Blazor WASM'ı bir taviz gibi hissettiren bileşik çalışmaları türünde.

Tek yakalanan, donanım tabanı. .NET 11, x86/x64 ve Arm64 için minimum komut seti gereksinimlerini yükseltir. Apple Silicon ve çoğu Linux SBC'si iyi - Arm64 üzerinde ReadyToRun hedefi sadece LSE ekler - ama çok eski x86 donanımı dışarıda. Filonuzu yerinde bir güncelleme varsaymadan önce denetleyin.

ASP.NET Core ve Blazor

Zstandard burada başrolde. ASP.NET Core artık hem yanıt sıkıştırma hem de istek sıkıştırma için varsayılan olarak aktif durumda olan zstd'yi destekliyor. Yapılandırma, bekleneceğiniz şekildedir:

builder.Services.AddResponseCompression();
builder.Services.AddRequestDecompression();
builder.Services.Configure<ZstandardCompressionProviderOptions>(options =>
{
    options.CompressionOptions = new ZstandardCompressionOptions { Quality = 6 };
});
builder.Services.AddResponseCompression();
builder.Services.AddRequestDecompression();
builder.Services.Configure<ZstandardCompressionProviderOptions>(options =>
{
    options.CompressionOptions = new ZstandardCompressionOptions { Quality = 6 };
});
Imports Microsoft.Extensions.DependencyInjection

builder.Services.AddResponseCompression()
builder.Services.AddRequestDecompression()
builder.Services.Configure(Of ZstandardCompressionProviderOptions)(Sub(options)
    options.CompressionOptions = New ZstandardCompressionOptions With {.Quality = 6}
End Sub)
$vbLabelText   $csharpLabel

JSON veya metin yüklerini zaten zstd ile iletişim kurabilen mobil ve yakınlarda yer alan gRPC ekosistemlerinde API'lar için, bu, üçüncü parti bir kütüphaneye bağımlı olmadan ölçülebilir bir bant genişliği başarısıdır. Ayrıca, belirgin bir şekilde Microsoft içi değil de, topluluk katılımıdır, bu sağlıklı bir işarettir.

Blazor'un Virtualize<TItem>, en sonunda her satırın aynı yükseklikte olduğunu varsaymayı bırakıyor. Değişken içerikli her liste - yorumlar, sohbet mesajları, sarılmış metinli herhangi bir şey - manuel geçici çözümler gerektirirdi. Artık bileşen, çalıştırma zamanında ögeleri ölçüyor. Önizleme 3 sürümü de bir dizi Blazor hatasını düzeltiyor: Virtualize içindeki bir null başvuru, taşma-x ile kaydırma-kapsayıcı algılama, yayınlanan WASM uygulamalarında Web Worker şablonu, TempData tembel yükleme köşe vakaları ve IJSObjectReference sızıntısı ResourceCollectionProvider içinde. Bireysel olarak küçük, toplu olarak çerçevenin her yayın yeni bir şey aşamasının ötesine geçtiğini işaret eder.

Kestrel ayrıca yeni bağlantılardaki ilk istek gecikmesini azaltmak için HTTP/3 isteklerini kontrol akışı ve SETTINGS çerçevesini beklemeden işle As. HTTP/3 P99'leri ölçtüyseniz ve tuhaf soğuk başlatma kuyrukları gördüyseniz, bu sizin düzeltmenizdir.

.NET MAUI

Preview 3'te MAUI, onu uzun süredir bir beta gibi hissettiren boşlukları kapatmaya odaklanıyor. Map kontrolü pin kümeleme, özel pin simgeleri, özel JSON stillendirme ve daireler, çokgenler ve poligonlar üzerinde tıklama olayları alıyor - bunların hepsi gerçek üretim harita UI'larının ihtiyaç duyduğu ve daha önce her platform için özel işlemciler gerektiren şeyler. Yerleşik bir LongPressGestureRecognizer artık kendi başınıza yazmadan kullanılabilir. Örtük XAML ad alanı bildirimleri varsayılan olarak açık olduğunda, her dosyanın üstünde 'boilerplate' yi kısar.

Platform eşitliği bir yükselme alıyor: Permissions.PostNotifications artık iOS'ta uygulanmış durumda (önceden sadece Android içindi) ve Android, Android 17 ve API seviyesi 37 için önizleme desteği alıyor.

Dürüst değerlendirme: bu istikrarlı, mantıklı sürekli yinelemedir, yeniden icat değil. 2026'da MAUI, 2023'teki MAUI'den çok daha iyi bir yerde, ama önce yaşamında uzaklaştıysanız, sadece Preview 3 sizi geri sürüklemeyecek. Zaten MAUI'deyseniz, tam olarak istediğiniz QoL (Yaşam Kalitesi) değişiklikler bunlar.

SDK, CLI ve .NET izleme

Burada küçük şeylerin biriktiği bölüm. Günlük iş akışını gerçekten değiştirdiğini düşündüğüm birkaç şey:

.NET sln artık doğrudan CLI'dan çözüm filtreleri (.slnf) oluşturabilir ve düzenleyebilir. Monorepos ve büyük Microsoft tarzı çözümler için üç tanesi üzerinde çalışmak için 200 projelik bir SLN açmak gerçek bir maliyet olmuştur. Şimdi terminalden kapsama yapabilirsiniz:

dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj
dotnet new slnf --name MyApp.slnf
dotnet sln MyApp.slnf add src/Lib/Lib.csproj
SHELL

Dosya tabanlı uygulamalar (bu .NET uygulaması.cs iş akışı) sonunda destek #:include, ki bu, C# betiklerinin yardımcı araçları ayrı dosyalara ayırmasını sağlar. Roslyn'deki yönerge için düzenleyici tamamlanması ile kombinlenmiş olarak, bu dosya tabanlı uygulamaları 'oyuncak' dan 'gerçek otomasyon araçları için uygun hale' iter - yıllardır PowerShell ve küçük Python betiklerinin sahip olduğu niş.

.NET run -e FOO=BAR, ortama değişkenlerini kabuk durumu dışa aktarmadan veya başlatma profillerini düzenlemeden komut satırında geçirmenizi sağlar. Küçük, ama eğer hiç farklı ASPNETCORE_ENVIRONMENT değerleriyle üç terminal açık olduğunda acıyı biliyorsanız.

.NET izleme Aspire uygulama ana bilgisayarlarıyla entegre olur, bir çökme sonrası bir sonraki dosya değişikliklerinden sonra kendiliğinden yeniden başlar ve Ctrl+C'yi daha zarif bir şekilde WinForms ve WPF (kalıcı bir kağıt kesik) için ele alır. .NET format, çok hedeflenen projeler için --framework'ü kabul eder. .NET test MTP modunda --artifacts-yolu destekler. Ve .NET tool exec / dnx artık bir ekstra onay gerektirmiyor, bu da tek seferlik araç çalıştırmalar için bir sürtünme noktasıydı.

Ağrı noktaları

Dengeli bir inceleme, pürüzlü kenarları borçlandırır ve Preview 3 bunları içerir.

Araç hikayesi kaba. Visual Studio 2026, .NET 10'un piyasaya sürülmesinden altı ay sonra hala önizleme aşamasında ve Microsoft barındırmalı yapı aracıları henüz kararlı VS 2026 desteği taşımıyor. .NET 10 SDK yama sürümündeki bir değişiklik, semver garantilerini ihlal eden MSBuild 18 (VS 2026) kullanılmasını gerektiriyordu. Microsoft tarafından barındırılan ajanlarda CI çalıştıran herkes ya SDK 10.0.4'i sabitlemek ya da önizleme yapı görüntülerine geçmek zorunda kaldı. CI hatlarını .NET 11 önizlemelerine geçirmeyi düşünüyorsanız, daha fazlasını bekleyin - önizleme SDK'larının, ekibin kendi kabulüyle, 10.0.2 ve 10.0.3'te şeyleri kırdığı ve ardından sabitlenmiş olduğu biliniyor.

Runtime Async hala tercih edilen bir seçenektir. Önizleme-özellik kapısı kaldırılmış olsa da, runtime-async=on çevirmeniz gerekiyor. Bu, başlangıç kodları için uygun; NuGet'te dağıtılan kütüphaneler için, kullanıcılarınızın bu anahtarı açtığını varsayamıyorsunuz, bu yüzden pratik faydalar özelliğin varsayılan olarak açık olduğu zamana kadar ertelenir (bu, .NET 11'de değil).

Donanım gereksinim artışları. Minimum x86/x64 talimat seti gereksinimleri arttı. Çoğu ekip bunu fark etmez. Bazıları fark edecek ve denetlemezlerse dağıtım zamanında öğrenecekler.

STS, LTS değil. .NET 11, 24 ay boyunca desteklenir. Güncel LTS olan .NET 10, 36 ay alır. Yavaş yükseltme kadanslarında olan mağazalar için, .NET 10 hala daha muhafazakar bir seçenektir ve .NET 11'i benimsemek, 2028'de başka bir yükseltme taahhüdünde bulunma anlamına gelir. STS'yi benimsemenin dayanağı özelliklerdir; karşı dava ise takvimdir.

Önizleme, önizleme demektir. Bu, bir istikrar tiradı değil - Microsoft'un önizleme süreci iyi olmuş - ancak Önizleme 3 bir sürüm adayı değildir. Üretim dağıtımları en erken RC1'i bekler. Dahili araçlar, yan projeler ve keşif şu an için doğru kapsam.

Karar

Her gün C# yazıyorsanız, .NET 11 Önizleme 3, özellikle yıllardır en önemli dil değişikliği olan birlik türlerini deneyimlemek için bu hafta yüklemeye değer. Kütüphaneleri sürdürüyorsanız, JIT ve Runtime Async çalışması, kodunuzun .NET 11'de hiçbir düzenleme yapmadan daha hızlı olacağı anlamına gelir, bu en iyi türden bir yükseltmedir. MAUI uygulamaları yayımlıyorsanız, Harita ve jest çalışması gerçek bir ilerlemedir.

Üretim .NET iş yüklerini çalıştırıyorsanız, cevap sıkıcı olandır: planlamaya devam edin, izlemeye devam edin ve Kasım'da GA'yı yer imi olarak kaydedin. Heyecanlandıran parçalar düşüyor, ancak araç zinciri - VS, yapı ajanları ve SDK yama kadansları - aslında sürtünmenin yaşandığı yerdir ve henüz çözülmemiştir.

| --- |

Kaynaklar: .NET Blogu duyurusu, .NET 11'de yenilikler (Microsoft Learn), Çalışma zamanı sürüm notları, ASP.NET Core sürüm notları, SDK sürüm notları, C# 15'te birlik türlerini keşfedin.