.NET 11 Preview 5: Sessiz Gelen Yenilikler, Büyük Etki
Küçük bir detay: Preview sürümleri bazen insanı çok da heyecanlandırmıyor. Hani “bir sonraki büyük şey” diye bekliyorsunuz ya, çoğu zaman masaya küçük. Işe yarayan dokunuşlar geliyor..NET 11 Preview 5 için ilk hissim de buydu; sonra release notes’a biraz daha dikkatli bakınca fikrim epey değişti. Bu paket tek bir yerde bağırmıyor, ama runtime’dan SDK’ya, C#’tan ASP.NET Core’a kadar her yere ufak ufak el atmış.
Açık konuşayım, ben bu tip preview’leri seviyorum. Çünkü gerçek projede farkı çoğu zaman o gösterişli özellik değil, kenarda köşede kalan hız artışı ya da build sırasında gelen bir güvenlik kontrolü yaratıyor. AZ-305 ve AZ-104 tarafında yıllardır şunu gördüm: Kurumsal ekipler önce “yeni dil özelliği güzel de pipeline kırılır mı, deploy süresi uzar mı, bakım yükü artar mı?” diye soruyor. Haklılar da.
İlk Bakışta Ne Değişiyor?
Şahsen, Bu sürümün hoş yanı şu: herkesin işine yarayacak küçük ama somut iyileştirmeler var. JSON Lines desteği geliyor, LINQ full outer join kazanıyor, cryptography tarafında X25519 key agreement ekleniyor… yanı günlük işte karşınıza çıkabilecek ihtiyaçlara dokunulmuş. Mantıklı değil mi? Bir de Random için generic numeric API’ler var ki bu kısım bana baya iş görüyor gibi geldi.
Geçen yıl Şubat ayında İstanbul’da bir finans müşterisinde benzer bir preview dalgasını test etmiştik. Orada ekip “dil yeniliği” peşinde değildi; log işleme hattı daha hızlı olsun istiyordu. İşin aslı şu ki performans artışı bazen yeni bir framework özelliğinden daha değerli oluyor (özellikle üretimde kimse romantik davranmadığı için). Sistem hızlıysa seviliyor.
Bir başka örnek: 2024 sonbaharında Ankara’daki bir e-ticaret ekibinde build sırasında güvenlik açığı kontrolünü ayrı araçla yapıyorduk. Sonra pipeline içine gömdük ve ciddi rahatladık. Buradaki ders netti: Güvenlik sonradan eklenen bir katman olunca unutuluyor; build’in doğal parçası olunca hayat kurtarıyor.
Libraries Tarafı: Küçük Görünüp Çok İş Gören Dokunuşlar
System.Text.Json artık JSON Lines serialization destekliyor. Log akışlarıyla çalışanlar için bu bayağı kullanışlı olabilir. En çok da olay tabanlı mimarilerde satır satır JSON üretmek pratik oluyor; düz dosya gibi sakla, sonra satır satır işle… mış gibi.
Bence, LINQ full outer joins işe benim gözümde sessiz kahramanlardan biri. E tabi SQL bilen herkes bunu yıllardır istiyordu zaten. Ama C# içinde doğrudan gelmesi iyi olmuş. Mesela raporlama servislerinde iki veri kümesini karşılaştırırken ekstra yardımcı fonksiyon yazma derdi azalıyor.
Kryptografi tarafındaki X25519 key agreement, özellikle modern güvenlik protokollerini takip eden ekipler için anlamlı. Ben burada hep şuna bakarım: Kağıt üstünde iyi mi? Evet. Üretimde yönetmesi kolay mı? İşte kritik soru bu.
Preview sürümlerinde en büyük hata şu oluyor: Her şeyi aynı anda denemek istemek. Ben genelde önce tek bir senaryo seçiyorum — mesela JSON Lines veya yeni LINQ davranışı — sonra önü gerçek veriyle test ediyorum.
Kimin işine yarar?
Bi saniye — Küçük ekiplerde bu yeniliklerin hepsi aynı anda cazip gelebilir ama bence öncelik sırası önemli. Startup iseniz JSON Lines ve LINQ tarafına odaklanın; çünkü hızlı geliştirme döngüsünde bunlar hemen fayda sağlar.
Enterprise tarafta işe güvenlik ve uyumluluk öne çıkıyor. X25519 gibi modern kripto seçenekleri ile runtime performans iyileştirmeleri daha değerli hâle geliyor. Ölçek büyüdükçe ufak kazançlar toplamda ciddi fark yaratıyor.
Runtime ve SDK: Asıl Fark Orada Saklı
.NET sürümlerinde çoğu kişi dili konuşur ama ben hep runtime’a bakarım. Runtime-async suspension’ın hızlanması kulağa sıkıcı gelebilir; değil aslında! Web API’lerde yoğun istek altında nefes alan yer tam orasıdır. Bu konuyla ilgili Azure DevOps’tan GitHub’a Kesintisiz Geçiş: ELM ile Yeni Dönem yazımıza da göz atmanızı tavsiye ederim.
JIT optimize etmeları ve GC trimming/compaction iyileştirmeleri de önemli parçalar arasında yer alıyor (ki bu çoğu kişinin gözünden kaçıyor). Hafıza baskısı yaşayan servislerde GC davranışı düzgünleşince gecikme grafikleri daha stabil oluyor (özellikle mikroservislerde). Bu arada evet, bazen fark küçücük görünür ama P95 latency’de kendini belli eder.
SDK tarafında file-based apps’in diğer C# dosyalarına referans verebilmesi ilginç bir adım olmuş. Hızlı prototipleme yapan geliştirici için iyi haber; fakat kurumsal kod tabanı açısından biraz temkinliyim açıkçası. Çünkü esneklik arttıkça düzen ihtiyacı da artıyor… yoksa proje kısa sürede karmaşa yığınına dönebiliyor.
Hmm, bunu nasıl anlatsamdı… Daha fazla bilgi için GitHub’ın Unuttuğu Depolar İçin Güvenlik Kontrolü: Bence Asıl Mesaj Bu yazımıza bakabilirsiniz.
| Konu | Küçük Ekip | Büyük Kurum |
|---|---|---|
| File-based app referansları | Hızlı deneme için çok iyi | Sıkı standart gerektirir |
| Sürüm öncesi güvenlik kontrolleri | Bazı adımları elle yönetebilir | Pipelineda otomatik olmalı |
| Runtime iyileştirmeleri | Daha az görünür ama faydalı | Maliyet ve ölçek etkisi büyük olur |
| C# yeni sözdizimi özellikleri | Ekip motive olur | Kod standardı şarttır |
Maliyet açısından ne düşünüyorum?
Bunu Türkiye’deki şirketler açısından değerlendirirsek mesele sadece teknik değil; maliyet de var tabiî ki TL bazında düşününce her optimizasyon kıymetli hâle geliyor (özellikle yüksek trafik alan sistemlerde). Azure üzerinde çalışan uygulamalarda CPU süresindeki ufak düşüş bile ay sonunda faturaya yansıyabiliyor.
Bazen müşteri bana “bu kadar preview’i neden önemseyelim?” diye soruyor. Cevabım net: Eğer production workload’unuz varsa erken test etmek sizi ilerideki upgrade krizinden korur! Geçen sene İzmir’de bir SaaS firmasının migration planında bunu yaşadık; preview aşamasında yakaladığımız uyumsuzluk sayesinde canlıya sorun taşımadık. Daha fazla bilgi için Discovery to Execution: Foundry’de Ajanları Toolbox ile Ölçeklemek yazımıza bakabilirsiniz.
C# ve ASP.NET Core Tarafı Daha Cesurlaşıyor mu?
İnanın, C# tarafındaki closed class hierarchies ile union declarations/patterns gerçekten dikkat çekici görünüyor.. Bunlar dili biraz daha ifade gücü yüksek hâle getiriyor ama dürüst olayım, ilk okuduğumda “güzelmiş” dedim; sonra kafamda bakım maliyeti sorusu belirdi. Daha fazla bilgi için Teams’te Çalışan Ajanlar: İşin Olduğu Yerde Başlamak yazımıza bakabilirsiniz.
Neden? Çünkü dil ne kadar güçlenirse ekip içi öğrenme eğrisi de o kadar önem kazanıyor! Küçük startup ortamında bunu çabuk sahiplenirsiniz ama enterprise ortamda eğitim dokümantasyonu olmadan geçiş yapmak riskli olabilir.
Ben kendi projelerimde böyle özellikleri önce dar kapsamda denerim — mesela yalnızca domain model katmanında — sonra yaygınlaştırırım. Azure Cosmos DB’de Vektörler Kendini Güncelliyor: AI Uygulamalarda Yeni Dönem yazımızda bu konuya da değinmiştik.
Peki neden?
ASP.NET Core’da Blazor SSR’ın client-side validation desteklemesi hoşuma gitti doğrusu. QuickGrid’in interactivity olmadan çalışması da ayrı güzel; çünkü bazı ekranlarda etkileşim uğruna tüm sayfayı ağırlaştırmak gerekmiyor artık.
Tatlı nokta nerede?
Tatlı nokta şu bence: kullanıcı deneyimini artırırken mimariyi gereksiz yere şişirmemek gerekiyor.
Ha bu arada SupplyParameterFromSession özelliği de belirli senaryolarda işe yarar görünüyor ama session bağımlılığına fazla yaslanırsanız test edilebilirlik zayıflayabilir — burası biraz hayal kırıklığı yaratabiliyor.
.NET MAUI ve EF Core: Uygulama Katmanına İnince İş Değişiyor()
Animations için CancellationToken-aware overload’lar pratikte iptal edilen ekran geçişlerini temiz yönetmeye yardım eder.
Windows Maps’in Azure Maps ile gerçek implementasyon kazanması işe özellikle kurumsal saha uygulamalarında anlam taşıyabilir.
Bir lojistik projesinde Mart 2025’te buna benzer harita bağımlılığını çözmeye çalışmıştık; hazır entegrasyon olmayınca takım üç farklı yerde aynı işi tekrar etmişti…
Ama dürüst olayım, MAUI hâlâ her senaryoda kusursuz değil.
Bazı ekranlarda native his vermesi güzel fakat platform çeşitliliği arttıkça test yükü de artıyor.
EF Core cephesinde işe dotnet ef’nın file-based apps’i desteklemesi kullanım kolaylığı sağlıyor.
SQL Server 2022 compatibility default olması da kurumsal dünyada hoş karşılanır;
zira kimse bağlantı açıp sürpriz davranış görmek istemez.
EF1004 uyarısı işe bence doğru yönde atılmış adım — async sorguyu sync çalıştırmaya kalkmak üretimde gizli bela çıkarabiliyor.
// Basit yaklaşım
var query = await context.Users
.Where(x => x.IsActive)
.ToListAsync(cancellationToken);
// Sync çağrı yerine async kalmak çoğu zaman daha sağlıklı
}
Sonra küçük bir senaryo seçin:
1) build,
2) temel API çağrısı,
3) logging/telemetry.
Hepsini aynı anda kırmaya çalışmayın.
}
}
Bende Kalan İzlenim: Güzel Paket Ama Biraz Ham Tarafları Var
>
.NET 11 Preview 5 bana göre “büyük manşet”ten çok “sağlam temel” sürümü gibi dürüyor.
Yanı sahnede bağırmıyor ama kuliste işi toparlıyor.
Böyle sürümlere ben genelde saygı duyarım çünkü uzun vadede gerçek etkiyi bunlar yapar.
Yine de her şey pembe değil.
File-based app yaklaşımı bazı geliştiriciler için özgürlük demekken bazı kurumsal ekipler için kontrol kaybı hissi yaratabilir.
Blazor SSR’daki yeni yetenekler heyecan verici olsa da ekibiniz server-side rendering disiplinine hazır değilse faydadan çok kafa karışıklığı getirebilir.
Benim tavsiyem şu:
Eğer küçük ekipseniz birkaç özelliği hemen deneyin.
Eğer büyük kurumdaysanız önce upgrade matrix çıkarın,
sonra dependency taraması yapın,
en son pilot ortamda ölçün.
Neyse uzatmayayım…
Bu tür preview’lerin asıl değeri meraktan çok disiplinle ortaya çıkıyor.
Ve evet, ilk denediğimde aldığım hatayı da söyleyeyim:
bir test ortamında eski tooling yüzünden dotnet ef komutu beklediğim gibi çalışmadı;
çözüm basitti — SDK’yı güncelledim ve PATH karmaşasını düzelttim.
Klasik ama öğretici!Sizin İçin Pratik Başlangıç Planı
>
Eğer bugün oturup.NET 11 Preview 5’i deneyecekseniz şöyle başlayın:
önce isolated bir VM ya da container hazırlayın,
sonra mevcut uygulamanızdan küçük bir servis seçin,
ardından yalnızca tek değişiklik yapın.
Mesela sadece JSON Lines ya da sadece EF Core command line akışı.
Kurumsal tarafta ben bunun yanına mutlaka telemetry koyuyorum;
Application Insights veya OpenTelemetry ile başlangıç metriğini alın,
sonra değişiklik sonrası kıyaslayın.
Aksi hâlde “iyi öldü galiba” seviyesinde kalırsınız ki bu bana pek sağlam gelmez.
Bir arkadaşım Kadıköy’de geçen ay tam tersini yaptı:
hemen beş özelliği birlikte aktifleştirdi,
iki gün sonra hangi değişikliğin neyi bozduğunu ayıklamakla uğraştılar.
O yüzden lafı gevelemeden söyleyeyim —
küçük adımlar genelde daha hızlı götürüyor.
- Neyi test edeceğinizi daraltın.
- Pilot uygulamayı seçin.
- Metrikleri önceden alın.
- Sadece tek risk faktörü değiştirin.
Sıkça Sorulan Sorular
.NET 11 Preview 5 üretimde kullanılmalı mı?
Hayır, preview sürümlerini üretime almak pek önerilmiyor. Aslında bu sürüm daha çok test, uyumluluk kontrolü ve gelecek planlaması için biçilmiş kaftan (yanlış duymadınız). Canlı sistemde kullanmayı düşünüyorsanız, açıkçası çok sıkı bir pilot süreç şart.
.NET 11 Preview 5 hangi alanlara yenilik getiriyor?
Bakın, Libraries, runtime, SDK, C#, ASP.NET Core, MAUI ve EF Core taraflarında güncellemeler geliyor. Yanı epey geniş bir yelpaze var. Bir bakıma, en çok da de performans, geliştirici deneyimi. Modern dil özellikleri öne çıkıyor — bence en heyecan verici kısımlar da bunlar.
Küçük ekipler bu sürümden nasıl faydalanabilir?
Küçük ekipler önce hızlı değer üreten alanlara odaklanmalı. Mesela JSON Lines, LINQ geliştirmeleri ve SDK kolaylıkları iyi bir başlangıç noktası. Her şeyi aynı anda almaya çalışmak yerine dar kapsamla ilerlemek, tecrübeme göre çok daha sağlıklı oluyor.
Büyük kurumlarda nelere dikkat etmek gerekir?
İlginç olan şu ki, Büyük yapılarda uyumluluk, gözetilebilirlik ve geri dönüş planı kesinlikle şart (inanın bana). Hani pipeline içi güvenlik kontrolleri, test matrisi ve rollback stratejisi olmadan geçişe kalkışmak gereksiz risk almak demek — valla güzel iş çıkarmışlar —. Açıkçası bu adımları atlamak sonradan çok pahalıya patlayabiliyor.
Kaynaklar ve İleri Okuma
Orijinal duyuru yazısı -.NET Blog
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.








Yorum gönder