.NET 11 Preview 4: Sessiz Ama Dolu Gelen Sürüm
Preview sürümler neden önemli?
.NET tarafında preview sürümlerini ben hep biraz “erken uyarı sistemi” gibi görüyorum. Kağıt üstünde final değil, evet (kendi tecrübem). Ama sahada asıl ipuçları çoğu zaman burada çıkıyor; hangi API değişiyor, hangi alanlar hızlanıyor, hangi araçlar olgunlaşıyor… Bunları önceden görmek, özellikle kurumsal ekiplerde altın değerinde oluyor.
Geçen yıl, 2025 Eylül’ünde bir finans kuruluşunda.NET yükseltme planı yaparken bunu çok net yaşadık. Preview paketlerini erkenden test etmeseydik, sonradan build sunucusunda patlayacak birkaç uyumsuzluğu atlayacaktık. İşin aslı şu ki, preview takibi sadece merak işi değil; risk yönetimi işi.
Bir de şu var: küçük ekipler genelde “final çıksın bakarız” diyor. Büyük kurumlarda işe durum farklı. Orada güvenlik onayı, regression testi, performans kontrolü derken süreç uzuyor; yanı iş uzuyor da uzuyor. O yüzden.NET 11 Preview 4 gibi bir sürüm, küçük ekip için haber değeri taşırken enterprise tarafta doğrudan planlama girdisi oluyor.
Araya gireyim: Açık konuşayım, her preview eşit değildir. Bazıları daha çok kozmetik gelir, bazılarıysa bayağı sağlam temel değişiklikler taşır. Bu sürüm ikinci gruba yakın dürüyor.
Runtime ve kütüphanelerde neler dikkat çekiyor?
Bak şimdi, bu sürümde beni en çok ilgilendiren kısım runtime ve library tarafı öldü. Mesela de Process sınıfındaki büyük güncelleme dikkat çekici; yıllardır kenarda köşede kalan bazı senaryolar artık daha düzgün ele alınıyor gibi dürüyor. Ayrıca Span-based Deflate/ZLib/GZip API’leri var ki bu iş bellek verimliliği açısından fena değil, hatta baya iş görüyor.
Ben 2019’da kendi lab ortamımda benzer sıkıştırma senaryolarını test ederken gereksiz allocation yüzünden GC baskısı yaşamıştım. Küçük veri akışlarında pek belli olmuyordu ama yük artınca CPU da şişiyor, latency de zıplıyordu; hani ilk bakışta sorun görünmüyor ama sonra bir bakıyorsun sistem nefes nefese kalmış (buna dikkat edin). Şimdi Span tabanlı yaklaşım bu tip yerlerde daha temiz bir yol açıyor.
Floating-point hex formatting. Parsing desteği de kulağa ufak geliyor ama bazı düşük seviye sistemlerde hayatı olabilir. Mesela finansal hesaplama yapan servislerde sayıların temsil biçimi bazen debug süresini kısaltır ya da uzatır — arada ciddi fark olur.
Bence burada güzel olan şey şu: Microsoft sadece yeni oyuncak eklemiyor, altyapıyı da toparlıyor. Yanı geliştirici deneyimi ile runtime verimliliğini aynı pakette itmeye çalışıyorlar. Tabiî hâlâ her şey pişmiş değil; preview olduğu için bazı köşeler ham kalabilir.
Küçük kazanımlar, büyük etki
System.Text.Json tarafındaki iyileştirmeler de tam bu kafada. Tek başına manşet olmayabilir. Mikro servis mimarisinde her milisaniye kıymetli olduğundan böyle dokunuşlar toplamda hissediliyor.
2024 Kasım’ında Logosoft tarafında bir müşteri projesinde JSON payload büyüklüğü yüzünden hem network hem serialization maliyeti can sıkıyordu (kendi tecrübem). Orada gördüğümüz şey şuydu: framework güncellemeleri bazen tek başına mucize yaratmıyor ama doğru kodla birleşince etkisi bariz oluyor.
.NET preview sürümlerinde asıl değer yeni özellikten önce gelir: kırılacak yerleri erkenden görmek.
SDK tarafında günlük işi kolaylaştıran detaylar
Garip gelecek ama, dotnet watch‘un.NET MAUI ve mobile projelerde cihaz seçimini desteklemesi bence iyi haber. Çünkü mobil tarafta emülatör mü gerçek cihaz mı sorusu bazen can sıkıcı bir ritüele dönüşüyor; şey gibi düşünün, her seferinde aynı kapıyı iki kere çalmak gibi. Bu küçük görünür ama zaman kazandıran bir detay.
Aslında — hayır dur, daha doğrusu, Aynı şekilde Fish shell completion desteğinin Bash, Zsh ve PowerShell ile hizalanması da hoş olmuş. Ben açıkçası terminalde çalışan insanlara saygı duyarım; otomatik tamamlama düzgünse çalışma ritmi değişiyor resmen.
dotnet reference benzeri komutların mevcut dizine geri düşmesi de pratikte faydalı olabilir. Hani bazen yanlış klasörde kalırsınız ya… İşte o anlarda komutun sizi kurtarması kötü olmaz.
Aslında, Beni biraz düşündüren kısım işe CLI telemetry tarafında Application Insights yerine OpenTelemetry’ye geçilmesi öldü. Doğru yönde atılmış adım mı? Evet. Ama kurumsal tarafta gözlemleme zinciri oturmuş ekipler için ilk gün biraz ayar ister; yanı kağıt üstünde iyi dürüyor. Sahada ufak pürüz çıkarabilir.
| Alan | Sana ne kazandırır? | Dikkat noktası |
|---|---|---|
| .NET MAUI dotnet watch | Daha hızlı debug döngüsü | Cihaz seçimi politikalarını netleştirmen gerekir |
| Fish completions | Daha rahat terminal kullanımı | Ekip standardizasyonu şart olabilir |
| OpenTelemetry CLI telemetry | Daha açık gözlemlenebilirlik modeli | Tüm izleme hattını birlikte düşünmek lazım |
| C# diagnostics iyileştirmeleri | Daha anlaşılır hata mesajları | Ters giden script’leri erken yakalaman gerekir |
C#, ASP.NET Core ve EF Core cephesinde neler var?
C# tarafında yanlış yere konmuş #! shebang direktifleri için daha anlaşılır diagnostic verilmesi bana göre küçük ama hoş bir kalite artışı. Böyle şeyler özellikle cross-platform script yazan ekiplerde sınır bozucu hataları azaltıyor.
Asp.net Core tarafında OpenAPI üretiminde HTTP QUERY desteği gelmesi güzel; API sözleşmesini daha temiz üretmek isteyen ekipler için iş görür bir yenilik bu.Neyse , Blazor için [SupplyParameterFromTempData] detayı da state taşıma senaryolarında pratik olabilir. Burada dikkat etmek lazım; her problemi TempData ile çözmeye kalkarsanız yapı çabuk karışır.
MCP Server template’in SDK ile gelmesi işe ayrı bir konu… AI ajanlarının kurumsallaştığı dönemde bunun etkisini ileride daha net göreceğiz diye düşünüyorum (özellikle iç araç geliştiren ekiplerde). Bir arkadaşımla Şubat 2026’da Ankara’da bunu konuşurken aynı noktaya geldik: template sağlamak benimsenmeyi hızlandırıyor çünkü başlangıç eşiğini düşürüyor.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır.
MCP ve Blazor neden önemli?
MCP Server template aslında “ilk adımı kolaylaştırma” meselesiyle ilgili. Kurumsalda çoğu teknoloji iyi olduğu için değil, başlaması kolay olduğu için yayılıyor — sert gerçek bu.
Bunun yanında Blazor circuit pause özelliği server-side senaryolarda bağlantı kopmalarıyla uğraşan ekiplerin hayatını biraz rahatlatabilir. Ama dürüst olayım, bu alan hâlâ ince ayar istiyor; özellikle yüksek trafikli ortamlarda davranışı dikkatle ölçmek gerekir.
.NET MAUI ve EF Core: Gözden kaçmaması gerekenler
Araya gireyim:.NET MAUI cephesinde Android. IOS için dotnet watch‘un genişlemesi mobil geliştiriciler açısından gerçekten işe yarar bir gelişme olabilir. İlginç, değil mi? Mobil tarafta deploy-test-deploy döngüsü zaten yeterince yorucu; buna biraz hız katmak fena olmaz (bizzat test ettim)
Hani, User experience açısından baktığımda bu tip geliştirmeler küçük gibi görünür ama ekibin moralini bile etkiler yanı. Derleyip beklemek yerine hızlı geri bildirım almak başka bir seviye sağlıyor.
EF Core tarafında işe SQL Server 2025 için approximate vector search desteği öne çıkıyor; AI uygulamaları yapanlar bunu not etsin derim.E tabi , JSON mapping’in relational modele tam entegre olması da model karmaşıklığını azaltabilir gibi dürüyor.
Kurum mu startup mı?
- Küçük startup iseniz: yeni özellikleri hızlı deneyin ama yalnızca izolasyon ortamında tutun. (bu kritik)
- Büyük enterprise iseniz: önce uyumluluk matrisi çıkarın, sonra pilot uygulama yapın.
- Sık deploy eden ekipseniz: SDK güncellemelerini CI/CD pipeline içine kontrollü alın.
- Düzenleyici baskısı olan sektörseniz: preview kullanımını prod’dan kesin ayırın.
Bence nasıl yaklaşmalı?
Açık konuşayım,.NET 11 Preview 4 “hemen herkes koşup yüklesin” tipi bir sürüm değil; ama takip edilmesi gereken türden kesinlikle öyle. Sız hiç denediniz mi? Mesela de de runtime optimizasyonları ve SDK ergonomisi uzun vadede değer getirir.Neyse uzatmayalım:
# İlk deneme akışı
dotnet --list-sdks
dotnet new web -n Net11PreviewLab
cd Net11PreviewLab
dotnet run
# ardından test projelerini ve publish çıktısını karşılaştırın
Küçük bir detay: Peki ilk iş ne olmalı? Ben olsam şunlarla başlarım:
- .NET 11 SDK’yı ayrı makinede veya ayrı container’da kurarım.
- Kritik projelerde unit/integration testleri koştururum.
- Paket uyumluluğu ve build warning’lerini kayda alırım.
- Maui veya ASP.NET Core kullanan alt sistemleri ayrıca denerim.
- Pilot sonuçlarına göre geçiş planı çıkarırım.
Dürüst olmak gerekirse, Zaten AZ-305 sınavına hazırlanırken de hep aynı şeyi söylerdim: teknoloji listesi okumak yetmez, etkisini mimarı karar olarak yorumlamak gerekir.Aynen öyle…
Sıkça Sorulan Sorular
.NET 11 Preview 4’ü production’da kullanabilir mıyım?
Açıkçası hayır, bence buna gerek yok. Önce test ortamında bir deneyin, hani kritik bağımlılıklarınızın uyumlu çalışıp çalışmadığını görün.
Bu sürüm kimin işine yarar?
Yanı özellikle ASP.NET Core,.NET MAUI ya da mesela performans hassasiyeti olan servislerle uğraşan ekipler için gerçekten anlamlı bir sürüm. Diğerleri için biraz erken sayılabilir.
MAUI geliştiriyorsam ne kazanıyorum?
Bunu yaşayan biri olarak söyleyeyim, Aslında fark oldukça belirgin. Cihaz seçimiyle birlikte dotnet watch akışı çok daha hızlı işliyor, debug döngüsü de bayağı rahatıyor. Tecrübeme göre bu tür iyileştirmeler günlük iş akışını ciddi etkiliyor.
Peki en büyük risk ne?
Preview paketlerin getirdiği kırılmalar var hani, bunlar CI/CD hattınızı bozabiliyor. Bence bu konuya özellikle dikkat etmek gerekiyor.
Kaynaklar ve İleri Okuma
- Orijinal.NET Blog duyurusu
- Microsoft Docs -.NET’te yenilikler
- dotnet/runtime GitHub deposu
- dotnet/sdk GitHub deposu
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.
Yorum gönder