.NET 11 w końcu naprawia API Procesów

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

Każdy deweloper .NET, który kiedykolwiek musiał uruchomić proces i przechwycić jego wynik, napisał jakąś wariację tego samego niebezpiecznego powtarzającego się kodu: asynchroniczny odczyt z stdout, asynchroniczny odczyt z stderr, WaitForExitAsync, nie zapomnij opróżnić obu strumieni, albo dostaniesz deadlock. To dobrze znana pułapka, która istnieje od lat.

.NET 11 w końcu naprawia to porządnie.

RunAndCaptureTextAsync

Kluczowe dodanie: jedna statyczna metoda, która uruchamia proces, przechwytuje stdout i stderr, i czeka na zakończenie bez deadlocka.

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

Jedno wywołanie. Bez ręcznego opróżniania strumieni. Bez ostrożnie umieszczonego WaitForExit. Jeśli po prostu chcesz uruchomić coś i uzyskać wynik, to jest właśnie to API, którego szukasz.

Jest też Process.RunAsync dla przypadku, gdy chcesz czekać na zakończenie bez przechwytywania danych wyjściowych.

KillOnParentExit

Częsty problem z uruchamianymi procesami: jeśli proces nadrzędny ulega awarii lub zostaje zabity, procesy potomne nadal działają jako sieroty. KillOnParentExit pozwala zadeklarować przy uruchamianiu procesu, że proces potomny powinien zostać zakończony, gdy zakończy się proces nadrzędny.

Ta funkcja istniała w specyficznych dla platformy formach (obiekty zadań w Windows, prctl w Linux), ale wymagała p/invoke lub bibliotek zewnętrznych do użycia z .NET. Teraz jest właściwością pierwszej klasy w ProcessStartInfo.

API oparte na SafeProcessHandle

Nowa lekka powierzchnia API jest zbudowana wokół SafeProcessHandle, a nie pełnej klasy Process. Pełna klasa Process niesie ze sobą dużo stanu i trudno ją przycinać — ścieżka SafeProcessHandle jest bardziej przyjazna dla trimmera w aplikacjach, które muszą minimalizować rozmiar wyjścia (WASM, natywne AOT).

Pełna Kontrola nad Dziedziczeniem Uchwytów

Aktualizacja dodaje również szczegółową kontrolę nad tym, które uchwyty dziedziczy proces potomny i jak są przekierowywane standardowe uchwyty. Wcześniej można było przekierowywać stdin/stdout/stderr, ale nie można było określić dokładnie, które uchwyty dziedziczyć na poziomie systemu operacyjnego. Nowe API udostępniają tę kontrolę.

Dlaczego To Jest Ważne

Klasa Process jest używana w toolingu, systemach budowania, uruchomieniach testów i każdej aplikacji, która wywołuje inne pliki wykonywalne. Stara powierzchnia API pochodzi z epoki .NET Framework i pokazywała swój wiek. Nie jest to zmiana łamiąca kompatybilność — stare API nadal działają — ale nowy kod powinien preferować nową powierzchnię.

W przypadku przycinanych aplikacji lub scenariuszy kompilacji AOT, ścieżka SafeProcessHandle jest szczególnie mile widziana. Stara klasa Process przynosiła dużo kodu z ciężkimi odwołaniami refleksji, który komplikował przycinanie.

Oryginalny post: Process API Improvements in .NET 11

Jak Copilot Studio Przemigrował do .NET 10 WebAssembly i Stał się 20% Szybszy

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

Zespół Copilot Studio zrobił coś, o co ciekawili się wszyscy programiści Blazor WASM: faktycznie zaktualizowali aplikację produkcyjną z .NET 8 do .NET 10 i zmierzyli wyniki. Post dzieli się konkretnymi liczbami, co jest rzadkie i naprawdę przydatne.

Aktualizacja Była Nudna (To Dobra Rzecz)

Aktualizacja docelowego frameworka, odświeżenie odwołań do pakietów, naprawienie zmian przełomowych. To wszystko. Build .NET 10 teraz działa na produkcji. Sama migracja nie była interesującą częścią — zmiany w .NET 10 są nią.

Automatyczne Odciski Palców Zasobów

Wcześniej dystrybucja aplikacji WASM oznaczała pisanie niestandardowych skryptów do zmiany nazw opublikowanych zasobów z hashami SHA256 dla cache-bustingu. Copilot Studio miał skrypt PowerShell robiący dokładnie to — zmiana nazw plików, wstrzykiwanie atrybutów integrity do loadera JavaScript, zarządzanie wszystkim ręcznie.

W .NET 10 wszystko to jest wbudowane. Opublikowane zasoby są automatycznie oznaczane odciskiem palca, importowane bezpośrednio z dotnet.js i weryfikowane pod kątem integralności bez ręcznej interwencji. Zespół usunął skrypt zmiany nazw.

Mała zmiana w zakresie, znaczące zmniejszenie złożoności.

WasmStripILAfterAOT Jest Teraz Domyślnie Włączony

W .NET 8 usuwanie IL ze skompilowanych AOT zestawów było opt-in. W .NET 10 jest to domyślne. Po kompilacji AOT oryginalny bytecode IL jest usuwany z wyjścia — nie jest potrzebny w czasie wykonywania, a jego zachowanie niepotrzebnie zwiększało rozmiar pakietu.

Copilot Studio używa specyficznej optymalizacji: dostarcza zarówno silnik JIT (szybki start), jak i silnik AOT (maksymalna wydajność w stanie ustalonym), ładując oba równolegle i przekazując z JIT do AOT, gdy jest gotowy. Deduplikuje również pliki identyczne między dwoma silnikami.

Nowe zachowanie usuwania IL oznacza, że zestawy AOT nie pasują już bit po bicie do swoich odpowiedników JIT, więc mniej plików jest deduplikowanych:

.NET 8: 59 współdzielonych plików
.NET 10: 22 współdzielone pliki

Wynik netto: rozmiar pakietu około 15% większy dla silnika AOT. Pobieranie AOT jest ~6% wolniejsze na szybkim LAN, ~17% wolniejsze na 4G. Ale wszystko to dzieje się w tle po tym, jak aplikacja jest już interaktywna.

Liczby Wydajności

To jest ważna część:

~20% szybciej przy pierwszym wywołaniu (zimna ścieżka)
~5% szybciej przy kolejnych wywołaniach (ciepła ścieżka)

Ulepszenia są najbardziej widoczne w “dużych botach” — dużych, złożonych agentach, gdzie dominuje kod skompilowany AOT. Dla prostszych przepływów pracy zysk jest mniejszy.

Jeśli Nadal Jesteś na .NET 8

Historia migracji jest naprawdę prosta: zaktualizuj <TargetFramework>, odśwież odwołania do pakietów, usuń niestandardowe skrypty odciskania palców, a automatycznie skorzystasz z WasmStripILAfterAOT. Jeśli kompilujesz AOT, spodziewaj się podobnych zysków wydajności.

Uwaga z posta: jeśli ładujesz środowisko uruchomieniowe .NET WASM wewnątrz WebWorker, ustaw dotnetSidecar = true podczas inicjalizacji.

Oryginalny post: Copilot Studio gets faster with .NET 10 on WebAssembly

Performance | The .NET Blog