.NET 11 Sonunda Süreç API'sini Düzeltiyor

Emiliano Montesdeoca — Tue, 26 May 2026 00:00:00 +0000

Hiç bir süreç başlatıp çıktısını yakalamak zorunda kalan her .NET geliştiricisi, aynı tehlikeli kalıp kodun bir varyasyonunu yazmıştır: stdout’tan asenkron okuma, stderr’den asenkron okuma, WaitForExitAsync, her iki akışı da boşaltmayı unutmayın yoksa deadlock olur. Bu yıllardır bilinen bir tuzaktır.

.NET 11 bunu sonunda düzgün bir şekilde düzeltiyor.

RunAndCaptureTextAsync

Temel eklenti: bir süreci başlatan, stdout ve stderr’i yakalayan ve deadlock olmaksızın çıkışı bekleyen tek bir statik metod.

var result = await Process.RunAndCaptureTextAsync("dotnet", "--version");
Console.WriteLine(result.StandardOutput);

Tek çağrı. Manuel akış boşaltma yok. Özenle yerleştirilmiş WaitForExit yok. Sadece bir şey çalıştırmanız ve çıktısını almanız gerekiyorsa, istediğiniz API budur.

Çıktıyı yakalamadan çıkışı beklemek istediğiniz durum için Process.RunAsync da var.

KillOnParentExit

Başlatılan süreçlerle ilgili yaygın bir sorun: üst süreç çöküyor veya sonlandırılıyorsa, alt süreçler yetim olarak çalışmaya devam eder. KillOnParentExit, süreç başlangıcında alt sürecin üst süreç çıktığında sonlandırılması gerektiğini bildirmenizi sağlar.

Bu, platforma özgü şekillerde var olan bir özelliktir (Windows’ta iş nesneleri, Linux’ta prctl) ancak .NET’ten kullanmak için p/invoke veya üçüncü taraf kütüphaneler gerektiriyordu. Artık ProcessStartInfo üzerinde birinci sınıf bir özellik haline geldi.

SafeProcessHandle Tabanlı API’ler

Yeni hafif API yüzeyi, tam Process sınıfı yerine SafeProcessHandle etrafında inşa edilmiştir. Tam Process sınıfı çok fazla durum taşır ve kırpılması zordur — SafeProcessHandle yolu, çıktı boyutunu en aza indirmesi gereken uygulamalar (WASM, yerel AOT) için daha kırpıcı dostu.

Tanıtıcı Kalıtımı Üzerinde Tam Kontrol

Güncellemede ayrıca bir alt sürecin hangi tanıtıcıları miras alacağı ve standart tanıtıcıların nasıl yönlendirileceği üzerinde ayrıntılı kontrol ekleniyor. Daha önce stdin/stdout/stderr’i yönlendirebiliyordunuz ancak OS düzeyinde tam olarak hangi tanıtıcıların miras alınacağını belirleyemiyordunuz. Yeni API’ler bu kontrolü açığa çıkarıyor.

Bu Neden Önemli

Process sınıfı araçlarda, derleme sistemlerinde, test koşucularında ve diğer yürütülebilir dosyaları çağıran her uygulamada kullanılıyor. Eski API yüzeyi .NET Framework döneminden kalmaydı ve yaşını gösteriyordu. Bu bir kırıcı değişiklik değil — eski API’ler hâlâ çalışıyor — ancak yeni kodların yeni yüzeyi tercih etmesi gerekiyor.

Kırpılmış uygulamalar veya AOT derleme senaryoları için SafeProcessHandle yolu özellikle memnuniyetle karşılanıyor. Eski Process sınıfı, kırpmayı karmaşık hale getiren çok sayıda yansıma ağır kodu beraberinde getiriyordu.

Orijinal gönderi: Process API Improvements in .NET 11

Copilot Studio .NET 10 WebAssembly'ye Nasıl Geçti ve %20 Daha Hızlı Oldu

Emiliano Montesdeoca — Sat, 23 May 2026 00:00:00 +0000

Copilot Studio ekibi, tüm Blazor WASM geliştiricilerinin merak ettiği şeyi yaptı: bir üretim uygulamasını gerçekten .NET 8’den .NET 10’a yükseltti ve sonuçları ölçtü. Gönderi, nadir ve gerçekten yararlı olan belirli sayılar paylaşıyor.

Yükseltme Sıkıcıydı (Bu İyi Bir Şey)

Hedef çerçeveyi güncellemek, paket referanslarını yenilemek, son değişiklikleri düzeltmek. Hepsi bu. .NET 10 derlemesi artık üretimde çalışıyor. Geçişin kendisi ilginç kısım değildi — .NET 10’daki değişiklikler ilginç.

Otomatik Varlık Parmak İzi

Önceden, bir WASM uygulaması dağıtmak, önbellek temizleme için yayınlanan varlıkları SHA256 karmaları ile yeniden adlandırmak üzere özel komut dosyaları yazmak anlamına geliyordu. Copilot Studio’nun tam olarak bunu yapan bir PowerShell betiği vardı — dosyaları yeniden adlandırma, JavaScript yükleyicisine integrity özelliklerini enjekte etme, her şeyi manuel olarak yönetme.

.NET 10’da tüm bunlar yerleşiktir. Yayınlanan varlıklar otomatik olarak parmak izi alınır, doğrudan dotnet.js‘den içe aktarılır ve manuel müdahale olmadan bütünlük doğrulaması yapılır. Ekip yeniden adlandırma betiğini sildi.

Kapsamda küçük değişiklik, karmaşıklıkta önemli azalma.

WasmStripILAfterAOT Artık Varsayılan Olarak Açık

.NET 8’de, AOT derlenmiş derlemelerden IL kaldırmak isteğe bağlıydı. .NET 10’da bu varsayılan. AOT derlemesinden sonra, orijinal IL bayt kodu çıktıdan kaldırılır — çalışma zamanında gerekli değildir ve onu korumak paket boyutunu gereksiz yere şişiriyordu.

Copilot Studio belirli bir optimizasyon kullanır: hem JIT motoru (hızlı başlangıç) hem de AOT motorunu (maksimum kararlı durum performansı) dağıtır, her ikisini paralel olarak yükler ve hazır olduğunda JIT’ten AOT’a geçiş yapar. Ayrıca iki motor arasında özdeş dosyaları tekilleştirir.

Yeni IL sıyırma davranışı, AOT derlemelerinin artık JIT karşılıklarıyla bit bit eşleşmediği anlamına gelir, bu nedenle daha az dosya tekilleştirilir:

.NET 8: 59 paylaşılan dosya
.NET 10: 22 paylaşılan dosya

Net sonuç: AOT motoru için yaklaşık %15 daha büyük paket boyutu. AOT indirme hızlı LAN’da ~%6 daha yavaş, 4G’de ~%17 daha yavaş. Ancak tüm bunlar uygulama zaten etkileşimli olduktan sonra arka planda gerçekleşir.

Performans Sayıları

Önemli olan kısım bu:

İlk çağrıda ~%20 daha hızlı (soğuk yol)
Sonraki çağrılarda ~%5 daha hızlı (sıcak yol)

İyileştirmeler, AOT derlenmiş kodun hakim olduğu büyük, karmaşık aracılarda — “büyük botlar"da en görünür. Daha basit iş akışları için kazanım daha küçüktür.

Hâlâ .NET 8’deyseniz

Geçiş hikayesi gerçekten basit: <TargetFramework>‘ü güncelleyin, paket referanslarını yenileyin, özel parmak izi komut dosyalarını kaldırın ve otomatik olarak WasmStripILAfterAOT‘tan yararlanacaksınız. AOT derliyorsanız, benzer performans kazanımları bekleyin.

Gönderiden bir not: .NET WASM çalışma zamanını bir WebWorker içinde yüklüyorsanız, başlatırken dotnetSidecar = true ayarlayın.

Orijinal gönderi: Copilot Studio gets faster with .NET 10 on WebAssembly

Performance | The .NET Blog