Copilot Studio .NET 10’a Geçti: WebAssembly’de Hız Devrimi

İnanın, Bir saniye, başlamadan önce şunu söyleyeyim: tarayıcıda C# çalıştırma fikri ilk duyulduğunda ben de “ölür mu yahu, JavaScript dururken kim uğraşacak bununla?” diye düşündüm. 2020’lerin başıydı; Blazor WebAssembly daha yolun başındaydı, indirilen runtime boyutu da açık konuşayım, baya kabarıktı. Şimdi geldiğimiz yere bakın — Microsoft’un kendi Copilot Studio ekibi üretimde.NET WASM kullanıyor ve yakın zamanda.NET 8’den.NET 10’a geçmişler. Sonuçlar… fena değil. Hatta beklediğimden iyi.

2. WasmStripILAfterAOT Artık Varsayılan

Peki ya burası? Şimdi daha teknik yere geldik. Aslında hikâye basit: AOT (Ahead-of-Time) derleme.NET metodlarını WebAssembly’ye önceden çeviriyor; güzel tarafı hızlı başlıyor olması, ama eskiden paketin içinde derlenmiş kodla birlikte orijinal IL (Intermediate Language) de duruyordu (runtime artık önü kullanmamasına rağmen). Yanı fazlalık taşıyorduk.

.NET 8 tarafında WasmStripILAfterAOT ayarı vardı ama varsayılan kapalıydı..NET 10 ile bu iş tersine dönmüş; artık varsayılan açık geliyor ve AOT build sırasında IL temizleniyor. Sonuç? Paket küçülüyor, indirme süresi biraz rahatlıyor, memory tarafı da daha sakın gidiyor.

Kulağa küçük geliyor olabilir. Değil aslında.

Copilot Studio’nün Hibrit Paketleme Stratejisi

Vallahi, Burada iş biraz karışıyor, hani ilk bakışta “tamam, AOT yaptılar bitti” diyorsun ama öyle değil. Copilot Studio düz bir AOT build kullanmıyor; hem hızlı açılış hem de runtime tarafında daha az sürtünme istedikleri için, hem JIT hem AOT engine’ı aynı NPM paketi içinde gönderiyorlar.

Mantık kabaca şu: Sayfa açılınca JIT engine devreye giriyor (küçük olduğu için hızlı yükleniyor), kullanıcı ilk tıklamaları yaparken arka planda AOT engine inmeye başlıyor ve hazır olunca kontrol ona geçiyor — sonra da işler native hıza yakın akıyor (ki bu çoğu kişinin gözünden kaçıyor). Kullanıcı çoğu zaman bu geçişi fark etmiyor bile. Evet, baya sessiz çalışıyor.

Bunu biraz açayım. Daha fazla bilgi için Kubernetes v1.36 DRA: Yeni Sürücüler ve Sahadan Notlar yazımıza bakabilirsiniz.

İki engine’in dosyaları arasında bit-bit aynı olanları deduplicate ediyorlar, yanı tekrar eden parçaları ayıklayıp paket boyutunu şişirmemeye çalışıyorlar. Akıllıca duruyor. Ama tabii burada küçük bir kıvrım var.

Doğrusu, WasmStripILAfterAOT açık olunca AOT assembly’leri JIT karşılıklarıyla artık birebir aynı kalmıyor. Yanı paylaşılabilen dosya — itiraz edebilirsiniz tabi — sayısı düşüyor, bu da deduplication tarafında biraz can sıkıyor. Microsoft bu trade-off’u kabul etmiş gıbı görünüyor. IL’siz AOT’tan gelen küçülme, dedup kaybından daha ağır basıyor.

Performans Karşılaştırması

Bir bakıma, kendi deneyimimden konuşuyorum, Microsoft’un paylaştığı rakamları tek tek uzatmadan toparlayayım; aşağıdaki tablo.NET 8 ile.NET 10 arasındaki tipik kazanımları özetliyor (Copilot Studio’nün kendi raporu ve genel WASM benchmark’ları baz alınmış). Şey, her uygulamada aynı sonucu beklemek pek doğru olmaz ama yönü anlamak için fena değil.

Neline

Türkiye’deki Şirketler Açısından Ne Anlam İfade Ediyor?

Şimdi asıl meseleye gelelim. Yurtdışında Microsoft çıkıp “Copilot Studio’yu.NET 10’a aldık” deyince iş biraz rahatlıyor, tamam da bizim tarafta,. Türkiye’deki kurumsal yapılarda, bunun karşılığı ne oluyor? İşte orası daha ilginç.

Birkaç gözlem bırakayım buraya: Bu konuyla ilgili copilot ile ilgili önceki yazımız yazımıza da göz atmanızı tavsiye ederim. Kubernetes v1.36 Declarative Validation: GA’ya Ulaştı yazımızda bu konuya da değinmiştik.

• Bankacılık ve sigorta sektörü: Tarayıcı içinde hesap yapan bir iş kuralları motoru lazım olduğunda, JavaScript ile yazıp sonra yıllarca taşımak açık konuşayım insanı yoruyor. C# core’u WASM’a derlemek, ortak kod tabanı sayesinde test yükünü baya azaltıyor; bir özel bankada hayat sigortası prim hesaplama motorunu bu şekilde tasarladığımızda, backend ile frontend arasında “neden farklı sonuç çıkıyor?” tartışması da kendiliğinden bitti.
• Telekom ve perakende: Tarife konfigüratörleri, ürün önericiler, kampanya hesaplayıcılar… Bunların hepsi tarayıcıda anlık tepki istiyor, yoksa kullanıcı hemen homurdanmaya başlıyor..NET 10 ile yükleme süresi düşünce deneyim fena ölmüyor, hatta bazı yerlerde gözle görülür fark yaratıyor.
• Kamu projeleri: Burada hikâye biraz başka. İlk yükleme süresi 3 saniyenin üstüne çıkınca son kullanıcı beklemiyor, hele taşrada bağlantı yavaşsa sabır çabuk tükeniyor..NET 10’un boyut tarafındaki iyileştirmeleri bu yüzden baya işe yarıyor. — ciddi fark yaratıyor

Maalesef her senaryoda WASM doğru seçim değil. Uygulama basit form ekranlarıyla CRUD işlemlerinden ibaretse, Blazor Server ya da klasik bir SPA framework çoğu zaman daha hızlı çözüm veriyor; WebAssembly’yi seçmenin asıl nedeni paylaşılan kompleks iş mantığı, bunu arada kaynatmayın. Bir bakıma, peki neden? Çünkü mesele sadece çalışması değil, aynı kuralın hem sunucuda hem tarayıcıda aynı davranması.

Tam da öyle.

Küçük Ekip vs Kurumsal: Hangı Yol Sizin İçin?

Bu soru bana sık geliyor. “Biz 5 kişilik bir startup’ız, Blazor WASM bize uyar mı, yoksa bu iş kurumsal tarafa mı kayıyor?”

Açıkçası, Açık konuşayım, tek bir doğru yok; ama kafamdaki tablo şu: ekip küçükse hız kazanıyorsunuz, büyükse de disiplin arıyorsunuz. İkisi aynı şey değil. Hatta bazen birbirine hiç benzemiyor.

Küçük ekipseniz (1-10 geliştirici)

Eğer ekip zaten C# tarafında yaşıyorsa. Hızlıca bir prototip çıkarmanız gerekiyorsa,.NET 10 Blazor WASM baya iş görüyor. JavaScript dünyaini baştan öğrenmek zorunda kalmıyorsunuz, tek dilde kalıyorsunuz, tooling tarafı da tanıdık geliyor. Dür bir saniye, ilk yükleme boyutu yine de JavaScript SPA’lara göre ağır kalabiliyor, yanı public-facing bir e-ticaret sitesi yapacaksanız iki kere düşünün.

İç kullanıma dönük işlerse konu değişiyor. Admin panel mi? B2B tool mu? Orada iş daha rahat akıyor. Hani kullanıcı beklerken kahve içsin derseniz biraz can sıkabilir. Ekip içi uygulamalarda bu yük o kadar problem ölmüyor.

Peki neden?

Çünkü küçük ekipte en pahalı şey çoğu zaman altyapı değil, bağlam değiştirmek oluyor; bir yanda frontend dili, diğer yanda backend dili derken insanın kafası dağılıyor, o yüzden tek ortamde kalmak bazen performanstan daha değerli hâle geliyor.

Kurumsal yapıdaysanız (50+ geliştirici)

Küçük bir detay: Burada olay biraz başka yere kayıyor. Artık mesele sadece ekranı hızlı açmak değil; kod paylaşımı, standardizasyon ve uzun vadeli sürdürülebilirlik gıbı konular öne çıkıyor. Neden önemli bu? Büyük organizasyonlarda aynı iş kuralını üç farklı yerde tutup sonra hata avına çıkmak var ya, işte asıl can sıkan nokta o. Bu konuyla ilgili Copilot Agent Evaluations: Ajan Kalitesini Ölçen CLI Geldi yazımıza da göz atmanızı tavsiye ederim.

.NET çevreinde olan büyük kurumların WASM’a yönelmesinin ana nedeni performans falan değil, açıkçası tek kod tabanı, iki çalışma yeri fikri (inanın bana). Yanı aynı mantığı hem web’de hem başka tarafta tekrar tekrar yazmıyorsunuz. Microsoft Copilot Studio’nün yaptığı şey de tam olarak buna yakın duruyor (yanlış duymadınız)

Şunu söyleyeyim, Neyse, çok dağıtmadan söyleyeyim: burada kazanç biraz daha organizasyonel oluyor. Şey gıbı düşünün; teknik olarak her şey pırıl pırıl görünmeyebilir ama ekip büyüdükçe o düzen hissi ciddi fark yaratıyor.

“WebAssembly bir performans hilesi değil, mimarı bir karar. Eğer aynı iş kuralını üç farklı yerde sürdürüyorsanız ve hatalar arasında tutarsızlık varsa, WASM cevap olabilir. Yoksa zorla benimsetmeyin.”

Ben olsam böyle bakarım. Küçük ekipte hız. Basitlik ağır basıyorsa tercih edilebilir; kurumsalda işe tekrar eden karmaşayı azaltıyorsa anlam kazanıyor. E sonra? Geri kalan detaylar zaten projenin kokusundan belli oluyor.

Maliyet Tarafı: Azure’da Hosting Ne Tutar?

Vallahi, Bir konu daha var, pek konuşulmuyor ama önemli. Blazor WASM uygulamasını host etmek, Blazor Server tarafına göre genelde daha ucuz kalıyor. Işin özü statik dosyalar, yanı öyle sunucu tarafında sürekli ayakta duran bir yapı yok. Azure Static Web Apps’te aylık ücretsiz plan bile küçük projelerde gayet yetebiliyor, hatta bazen “bu kadar mı?” dedirtiyor. Free tier ay başında 100 GB bandwidth veriyor. Daha fazla bilgi için Kubernetes v1.36 Memory QoS: Katmanlı Bellek Koruması Geldi yazımıza bakabilirsiniz.

Doğrusu, Karşılaştırma yapınca tablo daha net çıkıyor. Blazor Server için en azından bir App Service Plan tutmanız gerekiyor, B1 seviye bile şu an aylık yaklaşık 250-300 TL civarında geziyor; yanı hani küçük bir deneme projesiyseniz biraz can sıkabiliyor. WASM ile statik hosting’e geçince bu maliyet sıfıra iniyor, ama dür bir saniye — backend API’leriniz yine Azure’da çalışmaya devam edecek, o kısmın faturası ayrı hesaplanıyor.

İlgili konularda daha önce Microsoft Agent Framework:.NET’te Akıllı Ajan Devri yazısında.NET’in modern AI çevreine nasıl entegre olduğundan bahsetmiştim, bir göz atın derim. Neyse, konu dağıldı gıbı öldü ama bağlantı aslında yerinde; çünkü bugün artık sadece UI’ı değil, arka taraftaki akıllı servisleri de aynı mimarı içinde düşünmek gerekiyor.

Bunu biraz açayım.

Geçişte Karşılaştığım Bir Hata ve Çözümü

Ne yalan söyleyeyim, Geçen ay bir müşteride.NET 8’den.NET 10 önizlemesine geçiş denedik. Build geçti, içimiz rahatladı,. Tarayıcıda açınca bu kez worker initialization hatası patladı: “dotnet runtime not initialized in worker context“. Kısa sürdü sanmayın; bir saat boyunca ekran başında dönüp durduk, hatta bir ara “nerede kaçırdık bunu?” diye birbirimize baktık. Sonra Microsoft’un blog yazısındaki küçük bir not gözüme çarptı, hani şu dotnetSidecar = true satırı var ya, işte o. Eklediğimiz anda sorun çözüldü. Evet, bu kadar.

Şimdi, garip gelecek ama, Burada şu kodu paylaşayım, sonra lazım olursa elinizin altında dursun:

// WebWorker içinde.NET WASM runtime baslatma
import { dotnet } from './_framework/dotnet.js';
const { setModuleImports, getAssemblyExports, getConfig } = 
await dotnet
.withDiagnosticTracing(false)
.withApplicationArgumentsFromQuery()
.withConfig({ dotnetSidecar: true }) // KRITIK: worker için sart
.create();
await dotnet.run();

Eğer worker kullanmıyorsanız bu satıra ihtiyacınız yok. Ama işin aslı şu: production tarafında WASM uygulamalarında main thread’i boş bırakmak için worker kullanımı baya yaygınlaşıyor, (buna dikkat edin). Kullanıcı arayüzü takılmasın istiyorsunuz, sonra bir bakıyorsunuz küçük bir blokaj bile can sıkıyor. Şimdi, siz ne dersiniz? Hatırınızda bulunsun.

İlk Adım Olarak Ne Yapmalı?

Mevcut bir Blazor WASM projeniz varsa,.NET 10’a geçişte ben önce şu sıraya bakıyorum: lafı gevelemeden bağımlılıkları tek tek kontrol edin, sonra da işi canlıya atmadan önce test ortamında biraz süründürün. Hani ilk bakışta basit duruyor ama, özellikle 3rd party UI kütüphanelerinde küçük bir uyumsuzluk çıkarsa uğraştırıyor.

Çok konuştum, örnekle göstereyim.

1. Bağımlılıkları kontrol edin: NuGet paketlerinizin.NET 10 uyumlu sürümleri var mı? Hele bir de 3rd party UI kütüphaneleri. Burada bazen insan “tamamdır” diyor ama bir bakıyorsun, tek bir paket bütün zinciri bozuyor.
2. Test ortamında deneyin: Production’a almadan önce staging’de en az 1 hafta gözlem yapın. En çok da de de service worker davranışı değişebiliyor. Evet, sıkıcı geliyor; ama sonra kullanıcı tarafında cache garipliği yaşarsanız iş uzuyor.
3. Build pipeline’ı sadeleştirin: Custom rename script’leriniz, integrity hesaplamalarınız varsa hepsini silin. Artık framework hallediyor. Açık konuşayım, eski alışkanlıklar burada gereksiz yük oluyor.
4. AOT’u deneyin: Eğer hâlâ JIT mode’daysanız, AOT build’i bir test edin. WasmStripILAfterAOT sayesinde paket boyutu eskisi kadar şişmiyor. Şey, burada performans tarafı fena değil; ama ilk build süresi biraz can sıkabiliyor.
5. Ölçüm yapın: Lighthouse, WebPageTest gıbı araçlarla “before/after” karşılaştırması yapın. Müşterinize somut sayı göstermek isteyeceksiniz. Çünkü “bence hızlandı” demek yetmiyor, rakam lazım.

İlgili olarak VSTest Newtonsoft.Json Bağımlılığını Bırakıyor: Etkisi Ne? yazımda da.NET ekosistemindeki temizlenme trendinden bahsetmiştim — aynı felsefe burada da işliyor. Az önce sadeleşmeden söz ettim ya, işte tam da o mantık: daha az özel kod, daha az sürpriz demek; ama tabii her projede aynı rahatlık ölmüyor, bazen eski borçlar peşinizi bırakmıyor.

Eksik Tarafları da Söyleyelim

İşte, garip gelecek ama, Hep övüyoruz ya, biraz da tersinden bakalım..NET 10 WASM tarafında beni hâlâ dürten birkaç nokta var, hani her şey yolunda gıbı görünürken bir anda küçük taşlar çıkıyor ya, tam o hesap.

Birinçisi, debug deneyimi. Tarayıcı içinde C# debug ediyorsunuz, evet, ama JavaScript dünyasındaki source map işiyle kıyaslayınca biraz ham kalıyor; breakpoint bazen tutmuyor, watch window bazen boş bakıyor, sonra insan ekrana öylece kalıyor. Sınır bozucu.

İkincisi, cold start hâlâ dert..NET 10 ile iş biraz toparlandı ama React tarafındaki ilk açılışa göre indirme yükü yine hissediliyor, özellikle mobil 4G’de sayfa açılırken kullanıcı beyaz ekranla karşılaşabiliyor (ve bu detay küçük değil). Loading screen koymak şart gıbı.

Üçüncüsü, SEO. SPA’larda zaten ayrı bir uğraş var, WASM’da prerendering yapayım dediğinizde iş Blazor Server’a göre daha dolaşık hâle geliyor; public site düşünüyorsanız hibrit Blazor (Server + WebAssembly modu) akla daha yatkın duruyor (evet, doğru duydunuz). Siz ne dersiniz?

Yanı kağıt üstünde fena değil, hatta bazı yerlerde baya iş görüyor; ama pratikte gözden kaçmaması gereken noktalar var. Yön doğru mu? Bence evet.

Sıkça Sorulan Sorular

Blazor WebAssembly üretim ortamı için yeterince olgun mu?

Aslında Microsoft’un kendi Copilot Studio ekibi production’da kullanıyor — bence bu tek başına yeterince güçlü bir referans..NET 8 ile birlikte ciddi bir olgunluk seviyesine ulaşıyor,.NET 10 ile de build pipeline tarafı epey sadeleşti. Türkiye’de bankacılık ve sigorta sektöründe de örnekleri var hani. Yeter ki use case’ınız uygun olsun.

.NET 8’den.NET 10’a geçiş için kaç gün ayırmalıyım?

Orta büyüklükte bir uygulama için — yanı mesela 50-100 sayfa — 2-5 iş günü yeterli oluyor. Açıkçası bu sürenin çoğu test ve regression — ki bu tartışılır — doğrulamaya gidiyor. Asıl framework upgrade’i 2-3 saatlik bir iş. Kritik bağımlılıklarınız varsa, yanı third-party UI kütüphaneleri gıbı şeyler, sürelere biraz daha ekleme yapın.

WasmStripILAfterAOT açıkken reflection kullanan kütüphanelerim sorun yaşar mı?

Bazıları evet, yaşıyor. Reflection ağırlıklı kullanan eski kütüphaneler, IL strip edildiğinde runtime’da hata verebiliyor. Bu durumda <WasmStripILAfterAOT>false</WasmStripILAfterAOT> diyerek kapatabilirsiniz. Ama tecrübeme göre önce sorunlu metodları [DynamicallyAccessedMembers] attribute’ları ile işaretlemeyi deneyin — çok daha temiz bir çözüm o.

Bir dakika — bununla bitmedi.

JIT + AOT hibrit paketleme yaklaşımını ben de uygulayabilir mıyım?

Teorik olarak evet, ama pratikte oldukça zor. Copilot Studio ekibinin yaptığı şey aslında epey ileri seviye bir mühendislik. Çoğu uygulama için saf AOT veya saf JIT zaten yeterli oluyor. Hibrit yaklaşıma ancak çok büyük bir kullanıcı tabanınız varsa. Milisaniye seviyesinde optimizasyon gerekiyorsa girişin bence. Aksi hâlde harcadığınız efor karşılığını vermiyor.

WASM ile mobile uygulama da yapabilir mıyım?

Doğrudan değil, ama.NET MAUI Blazor Hybrid ile mümkün oluyor. Yanı aynı Blazor componentlerini hem web’de hem mobil app içinde kullanabiliyorsunuz. Performans tarafında native MAUI kadar iyi değil açıkçası, ama kod paylaşımı seviyesi inanılmaz yüksek. İç kullanım uygulamaları için harika bir kombinasyon bence.

Kaynaklar ve İleri Okuma

Copilot Studio gets faster with.NET 10 on WebAssembly (Microsoft DevBlogs)
Blazor WebAssembly Build Tools and AOT — Microsoft Learn
Host and deploy ASP.NET Core Blazor WebAssembly — Microsoft Learn
.NET Runtime — Mono WASM Source Code (GitHub)

Aşkın KILIÇYazar

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.

AZ-305AZ-104AZ-500AZ-400DP-203AI-102

İlgili Yazılar

Bankacılıkta Customer 360: Azure DocumentDB ile Pratik Yol3 May 2026

Claude Code ile Hata Düzeltmeyi Otomatikleştirmek: PR’a Giden Yol14 Nis 2026

Foundry Hosted Agents: MAF Ajanını Production'a Almak7 May 2026

.NET MAUI 11'de Harita Pin Kümeleme: Pratik Rehber19 Nis 2026