.NET 11 Preview 3: Gelen Yenilikler ve Sahadan Notlar
Geçen hafta bir müşterimizle sprint planlama toplantısındayken, ekipten biri “ya.NET 11 Preview üç çıkmış, union type gelmiş!” diye lafa girdi. Herkes bir an sustu. Ben de dahil. Çünkü union type konusu C# tarafında yıllardır dönüp duran, “acaba olur mu” diye beklenen şeydi; gelmişti işte, ama sadece o değil, bu preview içinde epey dolu bir paket var.
Bakın, her preview sürümünde “şu geldi, bu geldi” diye liste dökmek kolay. Ama asıl soru şu: bunlar gerçek projede neyi değiştiriyor? Ben de Logosoft’taki danışmanlık işlerinden gördüklerimle anlatayım, hani teoride güzel duran şeylerin sahada nasıl davrandığını biraz kurcalayalım (ciddiyim)
Runtime Tarafında Neler Değişti?
En çok dikkatimi çeken şeylerden biri runtime async tarafındaki preview-API opt-in zorunluluğunun kalkması öldü. Önceki preview’larda runtime async kullanmak için ekstra bir flag açmanız, üstüne bir attribute iliştirmeniz gerekiyordu. Şimdi gerek yok. Küçük gibi dürüyor ama öyle değil; yüzlerce geliştiricinin olduğu bir enterprise projede herkesin o flag’i doğru yere koymasını beklemek… açık konuşayım, pek gerçekçi değildi.
Şöyle söyleyeyim, JIT tarafında da switch ifadeleri, bounds check’ler ve cast işlemleri için iyileştirmelar gelmiş. Somut rakam vermek isterdim. Henüz kendi benchmark’larımı koşturamadım — bu hafta sonu bir denemem var, sonuçları ayrı bir yazıda paylaşırım muhtemelen. Yine de Microsoft’un paylaştığı sayılara bakınca, özellikle switch-heavy kodlarda gözle görülür bir kıpırdanma var gibi dürüyor.
Durun, bir saniye.
Bir de WebAssembly ve Browser tarafında WebCIL iyileştirmeleri ile debugging geliştirmeleri var. Geçen yıl bir Blazor WebAssembly projesi yapmıştık; debugging deneyimi resmen can sıkıcıydı. Breakpoint koyuyorsun, bazen tutuyor bazen kaçıyor. Böyle detaylar kağıtta sıkıcı görünür ama sahada çalışan biriyseniz hayat kurtarıyor.
C# Union Type: Heyecan mı, Biraz Bekleyelim mi?
Tamam, itiraf edeyim. Union type geldiğini duyunca ilk tepkim “sonunda!” öldü. İkinci tepkim işe “acaba ne kadarı geldi?” idi. F# kullananlar bilir; discriminated union’lar o tarafta yıllardır var ve baya iş görüyor.
C#’a gelen union desteği şimdilik preview aşamasında ve tam oturmuş değil. Ama temel iskelet orada. Mesela bir API response’ünü modellerken artık şöyle bir yapı kurabiliyorsunuz:
union ApiResult
{
Success(string Message),
Error(int Code, string Detail),
NotFound
}
// Kullanımı
var result = ApiResult.Success("İşlem tamam");
var text = result switch
{
ApiResult.Success s => s.Message,
ApiResult.Error e => $"Hata {e.Code}: {e.Detail}",
ApiResult.NotFound => "Bulunamadı",
};
İnanın, Güzel görünüyor. Ama dur bir saniye — bazı edge case’lerde compiler uyarıları hâlâ eksik kalabiliyor. Pattern matching ile entegrasyon fena değil gibi dürüyor ama mesela generic union’lar konusunda henüz ortada pek bir şey yok (bizzat test ettim). Kağıt üstünde iyi, pratikte işe biraz daha pişmesi lazım.
Türkiye’deki kurumsal projelerde bunun ne işe yarayacağını sorarsanız: domain modelleme tarafında ciddi rahatlık sağlayacak. Bankacılık projelerinde “TransactionResult” — kendi adıma konuşayım — gibi tipler için sürekli sınıf hiyerarşileri kuruyorduk ya, işte orada sadeleşme gelecek gibi dürüyor. Sız ne dersiniz? Ama production’a almak için GA’yı beklemek lazım — preview ile üretime çıkan müşterim öldü, sonra epey pişman öldü; o ayrı hikâye.
Libraries: JSON ve Sıkıştırma Tarafı
Yanı, System.Text.Json’a gelen naming ve ignore defaults kontrolü baya kullanışlı olmuş. En çok da — kendi adıma konuşayım — microservice mimarilerinde farklı servisler farklı JSON convention’ları kullanıyorsa bu esneklik çok iş görüyor. Eskiden custom converter yazmak zorunda kalıyorduk; şimdi daha deklaratif biçimde halledebiliyoruz.
Ha bu arada Zstandard’ın (zstd) System.IO.Compression namespace’ine taşınması da önemli. Zstd’yi bilmeyenler için kısa söyleyeyim: gzip’ten daha hızlı sıkıştırıyor ve çoğu senaryoda daha iyi oran veriyor. Biz bir loglama projesinde zstd kullanıyorduk. Üçüncü parti NuGet paketi üzerinden gidiyorduk; şimdi native destek gelince o bağımlılıktan kurtulacağız gibi.
Çok konuştum, örnekle göstereyim.
ZIP okumalarında CRC32 validasyonu da eklenmiş. Küçük detay gibi görünüyor ama değil — bir keresinde müşteride corrupt ZIP dosyası yüzünden saatlerce hata ayıklamıştık (inanın bana). Dosya açılıyor sanıyorsunuz ama içeride veri bozuk çıkıyor. CRC32 olsaydı o gün üç saat cebimizde kalırdı herhalde. Neyse uzatmayayım.
Regex ve Unicode Newline Desteği
Regex artık bütün Unicode newline sequence’larını tanıyor. Farklı platformlardan gelen verileri parse ederken bu baya önemli oluyor. Linux ayrı çekiyor, Windows başka davranıyor, macOS’un line ending derdi ayrı; üstüne Unicode’un kendi newline karakterleri geliyor… Metin işlemesi yapan herkes bu baş ağrısını az çok bilir.
Evet.
Peki neden? Bu konuyla ilgili GitHub’da Deployment Context: Repo ve Alert Yönetimi yazımıza da göz atmanızı tavsiye ederim.
Çünkü bazen tek satırlık fark bütün parser’ı bozuyor.
ASP.NET Core: Zstandard ve HTTP/3
ASP.NET Core tarafında en dikkat çeken yeniliklerden biri Zstandard response compression ve request decompression desteği olmuş. Aslında bu, library tarafındaki zstd desteğinin web katmanına yansıması gibi düşünebilirsiniz.
Şöyle kaba bir tablo hazırladım; sıkıştırma algoritmalarını yan yana görmek için iyi oluyor: Bu konuyla ilgili azd update Komutu: Paket Yöneticisi Derdine Son yazımıza da göz atmanızı tavsiye ederim.
| Algoritma | Sıkıştırma Hızı | Sıkıştırma Oranı | CPU Kullanımı | .NET 11 Native? |
|---|---|---|---|---|
| gzip | Orta | Orta | Orta | Evet (zaten vardı) |
| Brotli | Yavaş | Yüksek | Yüksek | Evet (zaten vardı) |
| Zstandard | Hızlı | Yüksek | Düşük | Evet (yeni!) |
İşin garibi, Baktığınızda zstd hem hızlı hem de iyi sıkıştırıyor gibi dürüyor.
Bilhassa API response’ları büyük JSON payload’lar taşıyorsa fark ciddi olabilir.
Bir finans kuruluşundaki projemizde günlük milyonlarca API çağrısı vardı — sıkıştırma algoritmasını değiştirmek bile aylık bandwidth maliyetini aşağı çekebilir.
Azure’da bandwidth ucuz değil; bunu hepimiz biliyoruz zaten.
Virtualize Bileşeni Artık Daha Akıllı
Blazor’daki Virtualize bileşeni artık değişken yükseklikteki item’lara runtime’da adapte oluyor.
Daha önce büyük çoğunluk item’ların aynı yükseklikte olması gerekiyordu ya da tahmini yükseklik vermeniz lazımdı.
Bu sınırlama gerçekten sınır bozucuydu — özellikle chat uygulamaları veya sosyal medya feed’i gibi yapılarda.
Artık düzelmiş.
Güzel de olmuş.
.NET MAUI: Harita ve Gesture Tarafı
MAUI tarafında en büyük yenilik harita bileşenine gelen clustering, styling ve zengin etkileşim API ‘leri.
Bu konuyu ayrı bir yazıda detaylıca ele aldım : .NET MAUI 11 Harita Pin Kümeleme : Sahadan Rehber — ilgilenenler oraya baksın. Bu konuyla ilgili.NET MAUI 11 Harita Pin Kümeleme: Sahadan Rehber yazımıza da göz atmanızı tavsiye ederim.
İşte tam da bu noktada devreye giriyor.
LongPressGestureRecognizer artık MAUI ‘nın içinde built-in geliyor.
Eskiden bunu custom renderer ya da community paketi ile yapıyorduk.
Küçük ama güzel bir adım.
Bir de Android 17 / API 37 preview desteği eklenmiş — erken adopter ‘lar için fena olmayan bir haber.
Doğrusu, XAML. Styling iyileştirmeleri startup süresini kısaltıyormuş.
Bunu henüz ölçemedim ama MAUI’nın startup süresi zaten en çok şikayet edilen konulardan biri idi, özellikle Android ‘de.
Umarım gerçekten hissedilir fark vardır.
Bak şimdi, burada beklenti yüksek. Bu konuyla ilgili Azure MCP Araçları Visual Studio 2022’de Yerleşik Geldi yazımıza da göz atmanızı tavsiye ederim.
Entity Framework Core ve SDK Değişiklikleri
Küçük bir detay: EF Core tarafında ChangeTracker.GetEntriesForState() metodu gelmiş.
Bu, ekstra change detection çalıştırmadan belirli state ‘teki entity ‘leri almanızı sağlıyor.
Büyük veri setleriyle çalışırken performans farkı yaratabilir.
Mesela batch import işleminde binlerce entity track ediyorsanız, sadece “Modified” olanları almak için artık gereksiz yere tüm change detection ‘ı tetiklemiyorsunuz.
SQL generation tarafında gereksiz JOIN ‘ların kaldırılması da var. Bu tür optimizasyonlar EF Core ‘un olgunlaştığını gösteriyor ; hani eskiden “EF ürettiği SQL berbat” diye söylenirdik ya, her sürümde biraz daha toparlıyor. Yine de karmaşık sorgularda raw SQL yazmak gerekebiliyor ; bu konuda %100 doğru olmayabilir ama sanırım uzun süre daha böyle devam edecek.
SDK Tarafı
dotnet run -e ile environment variable geçebilmek güzel olmuş.
Ayrıca solution filter ‘ların CLI’dan düzenlenebilmesi geliyor.
File-based app ‘ler artık birkaç dosyaya bölünebiliyor ; CI/CD pipeline ‘larında bunların hepsi iş görebilir. Bu konuyla ilgili VS Debugger Agent: Bug Avı Artık Ajan İşi yazımıza da göz atmanızı tavsiye ederim.
dotnet watch içine Aspire desteği, crash recovery (yanlış duymadınız). Windows desktop iyileştirmeleri eklenmiş.
Bir de şunu söyleyeyim : crash recovery baya önemli.
Geliştirme sırasında uygulama çöktüğünde watch’ın da beraber gitmesi insanı yoruyordu.
Artık kendi kendine toparlanabiliyor.
Production ortamına kesinlikle çıkmayın — preview sürümleri Go-Live lisansı olmadan desteklenmiyor.
Container Images Artık İmzalı
İnanın,.NET container image ‘ları artık imzalı geliyor.
Bu, supply chain security açısından boş geçilmeyecek bir adım.
Mesela finans ve sağlık sektöründeki müşterilerimiz için bu tür güvenlik şartları zorunlu olabiliyor.
Eskiden image ‘ların gerçekten Microsoft’tan gelip gelmediğini doğrulamak için ekstra uğraş gerekiyordu ; şimdi signature verification ile bunu otomatikleştirebilirsiniz.
Şunu söyleyeyim, Türkiye’deki şirketler açısından düşünürsek — KVKK ve BDDK düzenlemeleri giderek sıkılaşıyor. Container image signing, audit trail’inize eklemeniz gereken kontrol noktalarından biri hâline geliyor. Bunu yapmayan şirketler denetimde başını ağrıtabilir. Küçük ekipseniz belki şimdilik kenara koyarsınız ama kurumsal taraftaysanız pipeline’a ekleyin derim.
Bunu biraz açayım.
.NET 11 Preview 3, özellikle C# union type ve Zstandard desteği ile günlük geliştirme deneyimini somut biçimde iyileştiren bir sürüm. Ama union type’ın oturması için birkaç preview daha beklemek gerekecek gibi dürüyor.
Türkiye’deki Ekipler İçin Pratik Tavsiyeler
Açık konuşayım : Preview 3’ü hemen production’a almanız gerekmiyor. Ama kesinlikle sandbox ortamında denemenizi öneririm. Hele bir de de şu adımlarla başlayın :
- B ir Docker container’da.NET 11 Preview 3 SDK’yı kurun — ana makinenizi kirletmeyin (bu kritik)
- M evcut projelerinizden birini target framework olarak net11.0’a çevirip derleyin, breaking change var mı bakın
- L union type’ı küçük bir domain modelde deneyin — production kodu değil, proof of concept
- Z std sıkıştırmayı mevcut API’nizde benchmark’layın, gzip ile farkını ölçün
S tartup ‘lar için : Eğer greenfield bir proje başlıyorsanız ve GA tarihi (Kasım 2026) sizin timeline’ınza uyuyorsa,.NET 11’i hedefleyerek başlayabilirsiniz.
Ama mevcut ürününüz varsa acele etmeyin.
E nterprise tarafta : Preview sürümlerini sadece değerlendirme amaçlı kullanın.
Migration planınızı şimdiden hazırlayın ama uygulamayı RC’ye bırakın.
Bu arada eski güvenlik yamalarını takip etmeyi unutmayın — .NET ve.NET Framework Nisan 2026 Güvenlik Yamaları yazımda detayları bulabilirsiniz.
D evelopment ortamınız için Visual Studio 2026 Insiders ‘ı kurmanız gerekiyor.
VS Code tercih edenler C# Dev Kit ile de çalışabilir — bu arada VS Debugger Agent : Bug Avı Artık Ajan İşi yazısına da göz atın, debugging tarafında güzel yenilikler var.
>
Sıkça Sorulan Sorular
.NET 11 Preview 3’ü production’da kullanabilir mıyım?
Hayır, kullanma. Preview sürümler aslında sadece denemek ve değerlendirmek için var. Go-Live lisansı yoksa Microsoft’tan herhangi bir destek de alamıyorsunuz. Mantıklı değil mi? Açıkçası production için.NET 10 ya da.NET 9 LTS ile devam etmek çok daha mantıklı.
C# union type ile enum arasında ne fark var?
Enum yalnızca sabit değerler tutuyor, yanı veri taşıyamıyor. Union type’ta işe her varyant kendi verisini beraberinde getirebiliyor. Mesela Error(int Code, string Detail) gibi bir varyant hem hata kodunu hem de detay mesajını aynı anda tutabiliyor. Bence bu fark gerçekten büyük, enum bunu yapamaz.
Zstandard sıkıştırma için hâlâ üçüncü parti paket lazım mı?
Açık konuşayım,.NET 11 ile birlikte artık gerekmiyor. Zstandard, System.IO.Compression namespace’ine native olarak girdi. Ama eski sürümlerde hâlâ üçüncü parti NuGet paketlerine ihtiyacınız var, önü atlamamak gerek.
.NET 11 ne zaman GA oluyor?
Yanı, Microsoft’un yol haritasına göre Kasım 2026’da GA olması bekleniyor. Şunu da belirteyim:.NET 11 bir STS (Standard Term Support) sürümü olacak, yanı yalnızca 18 ay destek alıyor (en azından benim deneyimim böyle). Tecrübeme göre LTS isteyenler için.NET 12’yi beklemek çok daha iyi bir seçenek.
Mevcut.NET 8/9 projemi.NET 11’e taşımak zor mu?
Genelde target framework’ü değiştirmek yeterli oluyor, hani çoğu zaman o kadar (evet, doğru duydunuz). Ama breaking change’ler olabiliyor, bu yüzden dikkatli olmak gerek. Ayrıca preview aşamasında API’lar değişmeye devam edebiliyor, açıkçası GA’dan önce migration yapmak biraz riskli. Önce release notes’taki breaking changes listesine bir göz atmakta fayda var.
Kaynaklar ve İleri Okuma
.NET 11 Preview 3 Resmî Duyuru Yazısı —.NET Blog
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
2 comments