.NET 11 ve Build 2026: Kaçırmamanız Gereken Oturumlar
Açıkçası, Microsoft Build 2026’dan sonra bende kalan his şu öldü:.NET tarafı artık “sadece backend” diye geçiştirilecek bir çerçeve olmaktan çıktı, bayağı genişledi. C#’tan agentic web’e,.NET MAUI ile uçta yapay zekâdan kurulum deneyimini sadeleştiren araçlara kadar çizgi iyice netleşti. Açık konuşayım, bu yılki oturumların ortak mesajı şuydu:.NET 11, AI çağında uygulama geliştirmeyi daha düzenli, daha hızlı. Daha az dağınık hâle getirmek istiyor.
Benim için en ilginç taraf, bu duyuruların tek tek güzel olmasından çok birlikte nasıl anlam kazandığıydı. Çünkü yıllardır gördüğüm şey şu: teknik ekipler bir özelliğe heyecanlanıyor ama asıl mesele önü üretime taşıyınca başlıyor. Geçen ay İstanbul’daki bir finans müşterisinde tam bunu konuştuk; geliştirici ekibi yeni dil özelliklerini seviyor ama operasyon tarafı “peki izleme, güvenlik, sürümleme?” diye soruyor. İşte Build 2026 oturumları tam bu gerilimi biraz yumuşatıyor gibi dürüyor.
Ben olsam önce hangilerine bakarım?
Lafı gevelemeden söyleyeyim: herkesin ilk izlemesi gereken oturum aynı değil. Startup tarafındaysanız sizi en çok hızlandıracak olan şey muhtemelen AI Building Blocks ve dotnetup olur. Kurumsal tarafta işe runtime iyileştirmeleri, güvenlik katmanı ve agentic web parçaları daha kritik hâle geliyor. Çünkü büyük organizasyonlarda “cool demo” yetmiyor; uyumluluk, bakım maliyeti ve ekipler arası standardizasyon da işin içine giriyor.
2019’da kendi sunucu ortamlarımda benzer bir geçiş süreci yaşamıştım; o zaman mesele container değil klasik deployment idi. Psikoloji aynıydı. Geliştirici tarafı yeni araçları istiyor, sistem tarafı işe “önce stabil çalışsın” diyordu (ki bu çoğu kişinin gözünden kaçıyor). Şimdi.NET 11’de gördüğüm şey şu: Microsoft bu iki dünyayı biraz daha yakınlaştırmaya çalışıyor (evet, doğru duydunuz). Yanı sadece geliştirici mutluluğu değil, platformun işletilebilirliği de düşünülmüş.
Şimdi gelelim işin can alıcı noktasına.
C#’ta union types neden bu kadar konuşuluyor?
Union types konusu kağıt üstünde basit görünüyor ama pratikte ciddi fark yaratabilir. En çok da de — kendi adıma konuşayım — domain modelleme yaparken ya da wire protocol tüketirken, “şu alan bazen A bazen B oluyor” derdini temiz biçimde anlatmak büyük rahatlık sağlar. Şimdiye kadar bunu çoğu ekip ya enum + nullable kombinasyonuyla yamalı bohça gibi çözdü ya da gereksiz kalıtım hiyerarşileri kurdu. İkisi de pek iç açıcı değildi.
Şunu söyleyeyim, Bir bankacılık projesinde, Ankara’daki ekiple çalışırken ödeme akışlarında benzer bir karmaşa yaşamıştık. Hata yönetimiyle başarı senaryolarını aynı DTO içinde taşımaya çalışınca kod okunmaz hâle gelmişti. Union types burada işi toparlayabilir gibi dürüyor; ama dürüst olayım, dil tasarımı henüz yeni olduğu için tooling tarafının ne kadar olgunlaşacağını görmek lazım. Kağıt üstünde iyi dürüyor, pratikte göreceğiz artık.
Union types iyi haber; çünkü geliştiricinin niyetini kodun içine gömüyor. Ama her yeni dil özelliğinde olduğu gibi, yanlış kullanılırsa karmaşıklığı azaltmak yerine başka bir yere taşıyabilirsiniz.
.NET 11’in asıl hikâyesi performans değil yalnızca
E tabi performans önemli. Hatta bayağı önemli. Ama.NET 11 oturumlarına bakınca benim gördüğüm ana tema sadece “daha hızlı çalışıyor” değil; gözlemleme, teşhis etme ve dağıtık sistemleri daha yönetilebilir yapma çabasıydı. Azure sertifikalarına hazırlanırken — özellikle AZ-305 ve AZ-104 çalışırken — hep aynı yere geliyorsunuz: mimarı iyi olsa bile görünürlük yoksa işiniz zorlaşıyor (bizzat test ettim)
.NET 11 runtime, library ve SDK tarafındaki yatırımlar tam burada değer kazanıyor gibi geliyor bana. Bir uygulamayı saniyeler içinde ayağa kaldırmak güzel; fakat üretimde CPU niye zıpladı, GC ne yaptı, hangi bağımlılık gecikti… bunları anlayamıyorsanız iş yarım kalır. Geçen sene İzmir’de bir SaaS müşterisinde loglama eksikliği yüzünden iki gün boyunca gereksiz yere tahmin yürüttük; sorun aslında cache miss değil yanlış timeout ayarıymış! İşte böyle durumlarda teşhis araçları altın değerinde oluyor.
Kısa bir not düşeyim buraya.
| Oturum | Kime uygun? | Neden izlenmeli? |
|---|---|---|
| Union types in C# | Dil tasarımı seven ekipler | Daha temiz domain modeli kurmak için |
| .NET 11 in depth | Platform/arka plan ekipleri | Performans ve teşhis iyileştirmeleri için |
| AI Building Blocks for.NET | Uygulamasına AI eklemek isteyenler | Üretime yakın örneklerle ilerlemek için |
| Building for the agentic web | Web ekipleri ve mimarlar | Ajanlar, araçlar ve güvenlik dengesi için |
| .NET MAUI with edge AI | Mobil/desktop ekipleri | Cihaz üzerinde AI kullanımını görmek için |
| dotnetup | Tüm ekipler | Kurulum ve onboarding sürtünmesini azaltmak için |
Ajanlı web fikri güzel ama biraz temkinli olmak lazım
Tuhaf ama, Ajanic web lafı kulağa havalı geliyor, kabul edelim… ama her havalı kavram gibi bunun da sınırlarını bilmek gerekiyor. ASP.NET Core ile Blazor’ın hızlanması güzel — en azından ben öyle düşünüyorum — haber; Aspire entegrasyonu da dağıtık uygulamalar için ciddi kolaylık sağlıyor olabilir — bence çok yerinde bir karar —. Fakat ajan dediğimiz yapıların kontrolü zorlaştığında işin tadı kaçabiliyor.
Bunu geçenlerde Bursa’daki bir üretim firmasına anlattığımda yöneticinin ilk sorusu şuydu: “Bu ajan kullanıcı adına nereye kadar gidebilir?” Tam isabet soru buydu zaten! Agentic sistemlerde yetki sınırı çizmezseniz küçük otomasyonlar kısa sürede mini kaosa dönüşebiliyor. O yüzden ben bu yaklaşımı severim ama körü körüne alkışlamam.
Küçük ekip mi büyük kurum mu?
Küçük bir startup’taysanız agentic web’i hızlı prototip çıkarmak için kullanabilirsiniz; hatta bazı işleri tek kişiyle bile döndürebilirsiniz. Ama enterprise tarafta önce policy gerekir, sonra logging gerekir, sonra onay akışı gerekir… yanı sırayla pişirmek lazım.
İtiraf edeyim, Büyük kurumlarda önerim şu olur: önce dar geniş bir use case seçin — mesela iç destek talebi triage etsin veya doküman özetlesin — sonra gözlemleyin. Direkt müşteri adına işlem yapan ajanlara atlamak bana göre acelecilik olur.
.NET MAUI ile uçta AI: Güzel fikir mi? Evet!
.NET MAUI’nın edge AI senaryolarıyla anılması beni şaşırtmadı doğrusu. Çünkü mobilde veya desktop’ta internet bağımlılığını azaltmak çoğu zaman kullanıcı deneyimini ciddi biçimde toparlıyor. Bir saha uygulaması (söylemesi ayıp) düşünün; bağlantı zayıf ama model yerelde koşabiliyor… işte o anda UX başka seviyeye çıkıyor.
Yalnız burada küçük bir hayal kırıklığı notu düşeyim: edge AI kulağa çok sağlam geliyor ama model boyutu, cihaz kapasitesi. Enerji tüketimi hâlâ can sıkabiliyor. Ben geçen yıl Eskişehir’de sahada çalışan tablet uygulaması test ederken buna benzer bir senaryoda batarya tüketiminin beklediğimden yüksek çıktığını gördüm. Yanı evet iyi yönde gidiyor ama henüz ham.
// Basit düşünce modeli
if (device.HasLocalModel && network.IsPoor)
{
UseLocalInference();
}
else
{
CallCloudModel();
}
Kurulum deneyimi neden hâlâ önemli?
İtiraf edeyim, Bazen en parlak teknoloji en başta kaybedilir; çünkü kurulum kötü işe insanlar denemeden vazgeçer. dotnetup oturumu bu yüzden bence sessiz ama kıymetliydi. Yeni gelen geliştirici makinesine SDK kurarken uğraşmasın diye yapılan her yatırım doğrudan verimlilik getiriyor. Hani küçük detay gibi görünür ama onboarding günü kurtarır.
Doğrusu, Zamanında Logosoft’ta Kocaeli’ndeki bir müşteri grubuna standart geliştirme ortamı hazırlarken günün yarısını farklı SDK sürümleriyle boğuşarak geçirmiştik (ciddiyim). O gün şunu net anladım: platform stratejisi sadece üretimde değil ilk kurulum anında da başlar. Kurulum sade işe ekip daha çabuk işe girer;
aksi hâlde herkes birbirine ekran görüntüsü yollar…
- Sürüm standardını belirleyin.
- Geliştirici makinelerinde tek komutla kurulum hedefleyin.
- Sürüm yükseltmelerini ayrı planlayın.
- Mekanik işleri otomasyona bırakın.
Bence Microsoft’un verdiği mesaj ne?
Bence mesaj net:.NET artık bulut + AI + edge üçgeninde konumlanıyor (yanlış duymadınız). Sadece API yazan framework olmaktan çıkıp modern ürün geliştirme omurgası olmayı hedefliyor. Bu doğru yönde atılmış bir adım,ama eksik olan şey hâlâ organizasyonel disiplin. Teknoloji hazır olsa bile şirket içi karar mekanizması ağırsa fayda azalıyor.
Tamirci mantığıyla söyleyeyim:motor güçlü olabilir,ama direksiyon bozuksa araba yine savrulur. Kurumsal müşterilerimde bunu defalarca gördüm. Mesela Mart 2026’da İstanbul Finans Merkezî’nde görüştüğümüz bir ekip yeni teknolojilere açık olmasına rağmen release sürecini değiştiremediği için kazanımların yarısını masada bıraktı. Yazılım tarafında ilerlemek kolay,iş süreçlerini değiştirmek zor.
Eğer sız de bugün nereden başlayacağınızı düşünüyorsanız,ilk adım olarak üç şeyi yapın:hangi takımınız C# üzerinde aktif,hangi ürününüzde AI ihtiyacı var,hangi süreçte dağıtık mimarı sizi yoruyor？ Cevaplarınız sizi doğru oturuma götürür. Her şeyi aynı anda öğrenmeye çalışmayın; insan beyni bazen kaldırmıyor,açık konuşayım.
Sıkça Sorulan Sorular
.NET Build 2026’da en önemli duyuru neydi?
Bence en dikkat çekici başlık union types öldü; hani C# içinde ifade gücünü gerçekten artıran bir dil gelişmesi bu. Bunun yanında.NET 11’in runtime ve SDK yatırımları da uzun vadede çok şey değiştirecek aslında.
.NET MAUI ile edge AI kimler için uygun?
Sahada çalışan mobil/desktop uygulamalar için oldukça iyi bir seçenek. Mesela bağlantının zayıf olduğu ortamlarda yerel model kullanımı kullanıcı deneyimini ciddi toparlıyor. Ama açıkçası cihaz kaynaklarını mutlaka hesaba katmak gerekiyor.
Ajanlı web yaklaşımı hemen üretime alınır mı?
Bence doğrudan alınmamalı. Önce dar detaylı bir pilot yapılmalı, yetki sınırları çizilmeli ve gözlemleme kurulmalı. Yoksa tecrübeme göre faydadan çok risk yaratıyor.
dotnetup gerçekten gerekli mi?
Evet, özellikle çoklu takım yapılarında işe yarıyor. Kurulum karmaşasını azaltıyor, geliştirici onboarding süresini kısaltıyor ve yanı sürüm standardını korumaya da yardım ediyor.
KAYNAKLAR VE İLERİ OKUMA
Orijinal Microsoft.NET Build 2026 duyurusu
Microsoft Learn -.NET belgeleri
Build 2026: AI Ajanlarında Ölçümden ROI’ye Geçiş
SQL + AI: Elinizdeki Veriyi Bozmadan Akıllı Uygulama Kurmak
Daha geniş bir bakış için: .NET 11 nedir? Tüm yenilikler başlıklı kapsamlı rehberimize göz atabilirsiniz.
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.
4 comments