Açık konuşayım: preview sürümleri benim için hep biraz tatlı kaos. Bir yanım “hemen kur, bak ne varmış” diyor, öteki yanım işe “production’a sakın bulaşma” diye omzuma vuruyor..NET 11 Preview 4 elime geçtiğinde, dürüst olayım, ilk iş laptop’taki açık projeleri kapatıp bir kahve aldım; çünkü bu sürümde gerçekten göze çarpan şeyler var, hem de uzun zamandır beklediğim türden.
Geçen Çarşamba akşamı evde otururken indirdim, banka projemizdeki staging ortamına benzeyen bir sandbox kurup üstünde oynadım. Bazı şeyler beni şaşırttı, bazıları da “eh, nihayet” dedirtti. Şimdi bunları sizinle paylaşacağım; ama klasik release notes okuması gıbı değil. Daha çok sahada ne işime yarar, neyi şimdilik pas geçerim, hangı ekip için anlamlı ölür, ona bakacağız.
Önce Şunu Söyleyeyim: Preview 4 Neden Önemli?
Preview sürümlerinin kendi içinde bir ritmi var. Preview 1-2 genelde “yol buradan geçiyor” mesajıdır — Preview 3-4 işe işin somutlaştığı yer oluyor. Preview 5’ten sonra Microsoft çoğu zaman büyük oynama yapmıyor, daha çok toparlıyor. Yanı şu an gördüğümüz tablo,.NET 11’in Kasım’da çıkacak halının epey büyük bir kısmını gösteriyor olabilir.
Ve işler burada ilginçleşiyor.
Bunu yaşayan biri olarak söyleyeyim, Bu yüzden Preview 4’e ciddi bakmak lazım. Hele bir de takım liderleri ve mimarlar için. Çünkü.NET 11 LTS değil; STS yanı Standard Term Support olacak. Bu da kabaca 18 ay destek demek. Kurumsal müşterilerimde gördüğüm kadarıyla Türkiye’de hâlâ birçok ekip.NET 8’de takılı kalmış durumda, bazıları da.NET 6’yı bırakmamış bile..NET 11’e atlamak isteyenlere ben şimdilik “biraz dür, Preview 6-7’yi gör, sonra POC yap” diyorum. Ama özellikleri konuşmaya başlamak için tam zamanı.
“Bir preview sürümünü production’a koymak, yağmurda paten kaymaya benzer — yapılabilir ama akıllı insanlar yapmaz.” Bu lafı bir mimar arkadaşımdan duymuştum, hâlâ aklımda.
Runtime Tarafında Sessiz Devrim: runtime-async
Şimdi en kritik yere gelelim. Runtime libraries artık runtime-async ile derleniyor. Kulağa teknik dergi başlığı gıbı geliyor ama altında bayağı önemli bir mesele var.
Bakın şöyle anlatayım. C#’taki async/await yıllardır gayet iyi çalışıyor ama altyapı kısmı state machine üretimine dayanıyor. Yanı siz async Task yazınca compiler arkada bir state machine çıkarıyor, allocation oluşuyor, garbage collector da arada devreye girip temizlik yapıyor. Bu durum özellikle yüksek throughput’lu sistemlerde, mesela bir e-ticaret checkout API’sinde, hissediliyor.
Vallahi, runtime-async dediğimiz şey bu işi runtime seviyesinde çözmeye doğru gidiyor. Yanı derleyicinin değil CLR’ın işi üstlenmesi gıbı düşünün. Performans kazancı mı? Henüz net rakamlar yok ama Microsoft’un dahili benchmark’larında bazı senaryolarda %15-20 civarı allocation azalması görülmüş deniyor. Ben kendi sandbox’ımda küçük bir test yaptım — basit bir HTTP handler üstünde — fark vardı ama beklediğim kadar dramatik değildi. Belki testi yanlış kurdum, emin değilim; biraz daha kurcalarım.
Bunu biraz açayım.
Önemli not: Bu özelliğin sizin kodu değiştirmesi gerekmiyor. Yanı async/await kullanımı aynı kalıyor. Sadece perde arkasındaki çalışma biçimi değişiyor (şaşırtıcı ama gerçek)
JIT Optimizasyonları ve Hardware Intrinsics
JIT tarafında her sürümde olduğu gıbı yine ufak ufak ama biriken iyileştirmeler var. Devirtualization, escape analysis, loop optimizations… Hani bazen insanın içinden “her sürüm biraz daha hızlanıyor ama nereden geldiğini tek tek söyleyemiyorum” demek geçiyor ya, işte o his burada da var. Hardware intrinsics tarafı işe özellikle AVX-512. İlginç, değil mi? ARM64 NEON için epey açılmış; ML.NET ya da görüntü işleme yapanlar için bu kısım boş geçilecek gıbı değil.
Library’lerde Beni En Çok Heyecanlandıran: Process API
System.Diagnostics.Process sınıfı yıllardır neredeyse aynı yerde sayıyordu. Buyurun, sonunda ciddi bir genişleme geliyor gıbı duruyor:
- Process tree manipulation (parent-child ilişkilerini yönetme)
- Resource usage tracking — CPU, memory ve I/O detayları
- Cross-platform tutarlılık (Linux tarafı da Windows’a yaklaşmış)
- Async API’ler — artık
WaitForExitAsyncdışında da async seçenekler var (bu kritik)
Geçen yıl bir finans kuruluşunda batch processing sistemi yazıyorduk. Elli küsur child process ayağa kalkıyordu ve hepsinin durumunu izlememiz gerekiyordu. O zaman P/Invoke’a kadar inmek zorunda kalmıştık çünkü.NET’in sunduğu API’ler yetmiyordu. Şimdi bu yeni API’lere bakınca “keşke altı ay önce gelseydi” diyorum. Geç olsun güç olmasın.
Span-based Compression API’leri
Deflate, ZLib ve GZip için Span-based encoder/decoder gelmiş olması güzel haber (ben de ilk duyduğumda şaşırmıştım). Eskiden Stream üstünden çalışırken allocation biraz fazla kaçıyordu; şimdi Span<byte> üzerinden direkt sıkıştırma. Açma mümkün oluyor. Peki, hele bir de gRPC ya da yüksek hacimli mesajlaşma yapan sistemlerde işe yarar diye düşünüyorum. Kendi ölçümlerimde küçük payload’larda bile %30 civarı allocation düşüşü gördüm.
Bakın, burayı atlarsanız yazının kalanı anlamsız kalır. Bu konuyla ilgili GitHub Mobile’da Repo Açma Geldi: Sahadan İlk İzlenimler yazımıza da göz atmanızı tavsiye ederim. Bu konuyla ilgili Açık Kaynağa İlk Katkı: GitHub’da Başlangıç Rehberi yazımıza da göz atmanızı tavsiye ederim.
System.Text.Json: Yine, Yeniden, Bir Daha
Microsoft her sürümde Json’a dokunuyor; bu sefer de öyle olmuş. Polymorphic deserialization, source generator iyileştirmeleri, daha esnek converter’lar (kendi tecrübem). Nasıl desem, Newtonsoft.Json’dan göçü tamamlamak için son rötuşlar atılıyor gıbı duruyor. Ben hâlâ bazı eski projelerde Newtonsoft kullanıyorum ama yeni projelerde System.Text.Json’a geçmemek için bahane kalmadı artık.
ASP.NET Core: HTTP QUERY ve MCP Server Template
ASP.NET Core tarafında iki şey beni durdurdu diyebilirim. Birinçisi, HTTP QUERY method desteğinin OpenAPI dokümantasyonuna girmiş olması. HTTP QUERY nedir diye soranlar için kısa cevap şu: GET ile body göndermenin meşrulaştırılmış hâli gıbı düşünebilirsiniz (evet biraz kaba özet). Yıllardır “GET request’te body ölür mu olmaz mı” diye tartışırdık; şimdi yeni RFC ile QUERY method’u var ve.NET 11 bunu native destekliyor, OpenAPI çıktısına da yansıtıyor. Foundry Local 1.1: Yerel AI Artık Mikrofonu da Dinliyor yazımızda bu konuya da değinmiştik.
Şimdi, bunu yaşayan biri olarak söyleyeyim, Türkiye’de kurumsal müşterilerin çoğu hâlâ query işleri için POST kullanıyor — REST puristleri buna sınır oluyor tabi —. HTTP QUERY çıkınca dengeler değişebilir. Tabii burada asıl mesele API gateway’lerin. Load balancer’ların bu method’u tanıyıp tanımaması; işin can sıkıcı kısmı orası.
MCP Server template SDK’ya geldi. Yanı Model Context Protocol server kurmak isteyenler artık dotnet new mcpserver diyebilecekler. Bu bayağı önemli bir adım bence. AI agent’ları konusunda Foundry Hosted Agents: MAF Ajanını Production’a Almak yazımda biraz daha detay vermiştim ama özetle MCP, agent’ların dış sistemlerle konuşma protokolü ve giderek standartlaşıyor diyebiliriz.NET ekosisteminde first-class destek görmek iyi hissettiriyor açıkçası.
Bir dakika — bununla bitmedi. Bu konuyla ilgili Azure Cosmos DB Shell Public Preview: CLI ve MCP Birlikte yazımıza da göz atmanızı tavsiye ederim.
Blazor’da Server-Initiated Circuit Pause
Açıkçası, Burası Blazor Server kullananlar için önemli bir nokta. Eskiden kullanıcı sayfadan çıkınca ya da uzun süre inaktif kalınca sunucu tarafında kaynaklar boş yere tutuluyordu; şimdi sunucu inisiyatifiyle circuit’i pause edebiliyorsunuz. State korunuyor ama RAM ve CPU serbest kalıyor gıbı düşünün; kullanıcı geri döndüğünde de kaldığı yerden devam ediyor.
Birkaç ay önce bir sigorta şirketi müşterimde Blazor Server ile çalışıyorduk. Şu anda yaklaşık 800 concurrent user dönüyorlardı; resource tüketimi sürekli kıpır kıpırdı yanı rahat yoktu. Bu özelliği duyar duymaz takım lideriyle WhatsApp’tan yazıştık — Kasım’ı bekliyoruz şimdi (evet, doğru duydunuz)
.NET MAUI: Sonunda dotnet watch Geldi (iOS ve Android İçin)
Nihayet.
.NET MAUI ile uğraşan herkes bilir: hot reload kâğıt üstünde vardı ama gerçek anlamda “dotnet watch” deneyimi eksikti diyebilirim. Şimdi dotnet watch, hem iOS hem Android tarafında çalışıyor; üstelik device selection özelliğiyle geliyor — itiraf edeyim, beklentimin üstündeydi —. Yanı birkaç simülatör veya emülatör varsa hangisine deploy edeceğinizi seçebiliyorsunuz.
Yanı, Bunu güzel buldum ama durun, hemen göğe kaldırmayayım. MAUI’nın hâlâ epey sıkıntısı var; iOS tarafında build süreleri insanın sabrını yoklayabiliyor, Android’de bazı NuGet paketleri uyumsuzluk çıkarabiliyor. Yanı dotnet watch güzel,ama MAUI’yi production için seçerken ben hâlâ tereddüt ederim. Flutter veya React Native ile kıyaslayınca olgunluk açısından bence birkaç adım geride. Cosmos DB ile Kurumsal Ölçekte GenAI: AVASOFT Nexus Vakası yazımızda bu konuya da değinmiştik.
Entity Framework Core: SQL Server 2025 ve Vector Search
Eh, Konu ilginçleşti burada.
Sıkça Sorulan Sorular
.NET 11 ne zaman çıkıyor?
Microsoft’un takvimine göre Kasım 2025’te.NET Conf etkinliğiyle birlikte GA olması bekleniyor. Preview 4’e bakılırsa bu takvimden sapma ihtimali pek yok aslında. Yanı önümüzdeki birkaç ay içinde RTM elimizde olacak.
.NET 11 LTS mi, STS mi?
.NET 11 bir STS (Standard Term Support) sürümü, yanı 18 ay destek alıyor. Açıkçası kurumsal projelerde bu fark çok önemli. LTS isteyenler için bir sonraki LTS bir düşüneyim… sürümü.NET 12 olacak (Kasım 2026). Kritik sistemlerde bunu göz önünde bulundurun bence.
.NET 8’den.NET 11’e geçmek riskli mi?
Genelde.NET’in majör sürüm geçişleri oldukça stabil gidiyor, ama her zaman test şart. En büyük risk hani üçüncü parti NuGet paketleri oluyor. Tecrübeme göre şu sırayla ilerlemek mantıklı: önce dependency’lerin uyumluluğunu kontrol edin, sonra CI/CD’de parallel build yapın, en son production’a alın..NET 9 ve 10’u atlayıp doğrudan 11’e geçmek de mümkün, ama o zaman breaking change’leri toplu yaşamış oluyorsunuz.
runtime-async özelliği için kodumu değiştirmem gerekiyor mu?
Hayır, gerekmiyor. async/await kullanım şekliniz aynı kalıyor, değişiklik bayağı runtime tarafında. Sadece.NET 11 hedefli derlediğinizde otomatik olarak yeni davranıştan faydalanıyorsunuz. Tek istisna şu: çok düşük seviyede state machine internal’larına bağımlı kod yazıyorsanız (ki bu yanı gerçekten nadir bir durum), sorun çıkabilir.
Preview sürümünü production’da kullanmak güvenli mi?
Microsoft’un lisansına göre preview’ler “go-live” değil. Yanı bir sorun çıkarsa resmî destek alamıyorsunuz, açıkçası bu ciddi bir risk (inanın bana). Production için RTM’i bekleyin. Test, dev ve staging ortamlarında kullanmak işe bence bayağı faydalı, hatta tavsiye edilir (kendi tecrübem)
Kaynaklar ve İleri Okuma
.NET 11 Preview 4 Resmî Duyurusu -.NET Blog
.NET 11 Preview 4 GitHub Release Notes
Microsoft Learn: What’s New in.NET 11
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.
