C# Dev Kit 11.0: Daha Hızlı Yükleme ve Az Bellek
Visual Studio Code’da.NET geliştirenlerin en çok şikayet ettiği noktalar dil desteğinin açılmasını beklemek, artımlı derlemelerin gereğinden uzun sürmesi ve büyük çözümlerde bellek tüketiminin şişmesiydi. Microsoft,.NET 11 kapsamında C# Dev Kit’in mimarisini baştan kurdu, yükleme süreleri, derleme süreleri ve bellek kullanımında kaynakta ölçülmüş büyük farklar var. Bu yazıda, Drew Noakes’un.NET Blog’da yayımlanan duyurusundaki değişiklikleri ve bunların günlük geliştirme akışına yansımasını özetliyorum.
Baştan bir not. Sürüm numarası artık.NET’in güncel sürümüyle hizalanıyor; eklentinin yeni sürümü 11.0, bir öncekiyse 3.3 idi. Yani 3.3’ten 11.0’a atlamanın sebebi büyük bir sürüm sıçraması değil, numaralandırma politikasının değişmesi.
Yükleme sürelerinde ne değişti?
Microsoft ölçümleri iki gerçek depo üzerinde yapmış: dotnet/orleans (155 proje) ve dotnet/aspire (407 proje). İki ayrı “hazır olma” anı ölçülüyor:
- Aktif dosya hazır: Düzenlediğiniz dosyada tamamlama, tanılama, tanıma git ve hızlı düzeltmelerin çalışmaya başladığı an, yani fiilen iş yapabildiğiniz nokta.
- Çözümün tamamı hazır: Tüm projelerin yüklendiği, herhangi bir dosyada dil desteğinin çalıştığı, çözüm genelinde testlerin keşfedildiği ve “tüm referansları bul” işleminin bütün projeleri kapsadığı an.
| Çözüm | Proje | Ölçülen an | 3.3 | 11.0 | Kazanç |
|---|---|---|---|---|---|
| dotnet/orleans | 155 | Aktif dosya | 50,3 s’ye kadar | 0,53 s | 95× kadar |
| dotnet/orleans | 155 | Çözümün tamamı | 50,3 s | 2,3 s | 22× |
| dotnet/aspire | 407 | Aktif dosya | 84,1 s’ye kadar | 0,47 s | 180× kadar |
| dotnet/aspire | 407 | Çözümün tamamı | 84,1 s | 3,0 s | 28× |
Aktif dosya satırlarındaki “kadar” ifadesi eski davranıştan geliyor. 3.3 projeleri sabit bir sırayla yüklüyordu, açtığınız dosya bu sırada neredeyse bekleme süresi de ona göre uzuyordu. 11.0 ise önce aktif dosyayı yüklüyor, geri kalan çalışma alanı arka planda açılırken siz çalışmaya başlayabiliyorsunuz. Kaynağa göre bu süre proje sayısından bağımsız olarak sabit kalıyor.
Proje önbellekleri
Hızlanmanın ana nedenlerinden biri yeni proje önbellekleri. Eklenti artık her açılışta her projeye ait anlayışını sıfırdan kurmuyor; bir projenin önbelleği ilk yüklemede oluşuyor, sonraki açılışlar önbellekten besleniyor. Dil hizmetleri, testler ve başlatma hedefleri neredeyse anında kullanılabilir oluyor.
Duyuruda pratik bir ayrıntı daha var. Önbellek dosyalarını sürüm kontrolüne eklerseniz taze klonlar ve yeni git worktree’ler de hızlı araç desteğiyle başlıyor. Ajanlarla (agent) çalışırken birden fazla kopya açıp kapatan senaryolarda bu doğrudan kazanç demek.
Altı süreç yerine tek yerel süreç
Önceki sürüm altı yönetilen süreç başlatıyordu. Her biri antivirüs kontrollerinden geçmek, imajını diskten yüklemek, JIT derlemesi yapmak (ReadyToRun ile azaltılmış olsa da) ve birbirine bağlanmak zorundaydı; kodunuzla ilgili tek bir soruya yanıt verilmeden önce bunların tamamlanması gerekiyordu.
11.0’da bu süreçler CSDevKit adlı tek bir süreçte birleştirildi ve bu süreç,.NET’in Native AOT desteğiyle önceden derlenmiş yerel bir çalıştırılabilir dosya. Yüklenecek bir çalışma zamanı ve başlangıç yolunda JIT derlemesi olmadığı için süreç hemen çalışmaya başlıyor.
Artımlı derlemeler
Derleme tarafında iki özellik devreye girdi: hızlı güncel-mi kontrolleri (fast up-to-date checks) ve Build Acceleration. İkisi de Visual Studio tarafında bir süredir mevcuttu. Ölçümler yine 407 projelik Aspire çözümünde, her seferinde çözümün tamamı derlenerek yapılmış.
| Değişiklik | 3.3 | 11.0 | Kazanç |
|---|---|---|---|
| Hiçbir şey değişmemiş | 34,4 s | 0,88 s | 39× |
| Tek bir C# dosyası | 36,1 s | 2,1 s | 17× |
Kazanç, neyin değiştiğini hesaplama ve çıktı dosyalarını kopyalama maliyetlerinin düşmesinden geliyor. Duyuruda derleme sürelerinin çözümün yapısına bağlı olduğu ve her derlemenin bu ölçüde hızlanmayacağı açıkça belirtiliyor. Günlük çalışmada zaten çoğunlukla birkaç değişiklik derleniyor, 11.0’ın en çok fark yarattığı senaryo da tam olarak bu.
Birim testlerini çalıştırırken ve uygulamayı başlatırken fark daha belirgin hissediliyor, çünkü her iki işlem de başlamadan önce derleme yapıyor.
Bellek kullanımı
Süreçlerin tek sunucuda birleşmesi ve Native AOT bellek tarafına da yansımış. Projenin bellekteki temsili de daha kompakt hale getirilmiş.
| Çözüm | Proje | C# dosyası | 3.3 | 11.0 | Azalma |
|---|---|---|---|---|---|
| dotnet/orleans | 155 | 4.010 | 1.307 MB | 208 MB | ~%84 |
| dotnet/roslyn | 398 | 18.153 | 2.000 MB | 379 MB | ~%81 |
| dotnet/aspire | 407 | 4.686 | 2.072 MB | 316 MB | ~%85 |
Tablodaki ilginç nokta, bellek kullanımının proje sayısından çok kod tabanının büyüklüğüyle ilişkili olması. Roslyn, Aspire’a göre daha az projeye sahip olmasına rağmen yaklaşık dört katı C# koduna sahip olduğu için daha fazla bellek kullanıyor. Kompakt proje modeli sayesinde belleğin kod tabanından çok daha yavaş büyüdüğü belirtiliyor.
Ölçümlerin kapsamı konusunda bir uyarı da var. Bu rakamlar yalnızca C# Dev Kit sunucu süreç(ler)inin ayırdığı belleği gösteriyor. C# dil hizmeti (Roslyn) eskisi gibi kendi sürecinde çalışıyor, Visual Studio Code’un da kendi ayak izi var; ikisi de bu karşılaştırmaya dahil değil ve bu sürümde büyük ölçüde değişmeden kaldı.
MSBuild dosyaları için dil desteği
11.0’ın yeni özelliklerinden biri .csproj, .props ve .targets dosyaları için gelen düzenleme deneyimi. Bu dosyalarda artık tamamlama, tanılama, tanıma git, hızlı düzeltmeler ve anlamsal renklendirme çalışıyor, yani C# kodu yazarken beklediğiniz desteğin benzeri.
Paket adları ve sürümleri için tamamlama öneriliyor. Paketlerde ayrıca bir CodeLens girdisi yer alıyor; bu girdi yeni sürüm bulunduğunda ve kullanılan sürümde bilinen bir güvenlik açığı olduğunda uyarı veriyor.
Destek paketlerle de sınırlı değil. Tamamlamalar property, item ve metadata anahtarlarını kapsıyor, tanıma git çeşitli dil ögelerinde çalışıyor ve sizi SDK kaynağına kadar götürebiliyor. Tanılamalar sorunları siz yazarken işaretliyor, hızlı düzeltmeler düzeltme öneriyor.
C# Doctor ile ortam sağlığı
Bir proje yüklenemediğinde ya da beklenmedik davrandığında sebep çoğu zaman ortamla ilgili oluyor: eksik bir SDK, kurulu olmayan bir çalışma zamanı, erişilemeyen bir hedef framework, başarısız bir paket geri yüklemesi, bilinen açığı olan bir paket referansı. Yeni gelen C# Doctor bu kontrolleri tek yerde topluyor, dağınık hata mesajlarından nedeni kendiniz çıkarmak yerine doğrudan çözüme yönlendiriyor.
Mimari neden değişti?
Duyuruda bu çalışmanın gerekçesi IDE’nin rolünün değişmesine bağlanıyor. Ajanlarla geliştirme yapılırken araçlara girip çıkmanın çok daha hızlı olması ve birden fazla örneğin paralel çalıştırılabilmesi gerekiyor. 11.0’daki mimari değişiklikler eklentiyi bu yöndeki ihtiyaçlara hazırlamayı hedefliyor. Microsoft, bu bileşenleri daha fazla ortamda kullanılabilir kılmak için daha uzun vadeli yatırımlar yaptığını da belirtiyor.
Serinin devamındaki yazıların basitleşen mimari, Native AOT sunucusu, önbellekli proje yükleme ve hızlanan derlemeler konularına ayrıntılı gireceği duyuruldu.
Nasıl denenir?
C# Dev Kit 11.0 şu anda ön sürüm (pre-release) kanalında. Eklentiyi kurduktan sonra Extensions görünümündeki C# Dev Kit sayfasında Switch to Pre-Release Version seçeneğini işaretleyerek ön sürüm kanalına geçebilir, farkı kendi çözümlerinizde görebilirsiniz. Kararlı kanal için çalışmalar sürüyor; hata ve öneriler GitHub deposu üzerinden iletilebiliyor.
Kaynaklar ve İleri Okuma
- A faster, lighter C# Dev Kit —.NET Blog (Drew Noakes)
- C# Dev Kit eklentisi — Visual Studio Marketplace
- microsoft/vscode-dotnettools — hata ve öneri bildirimi
- Native AOT dağıtımı — Microsoft Learn
- .NET Blog
- Python in Visual Studio Code – November 2025 Release
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.
Yorum gönder