future: Review and modernize `ProcessStartInfo` usage for .NET 11/12 process API improvements

[VaclavElias]

Summary

.NET 11 introduces significant improvements to System.Diagnostics.Process and ProcessStartInfo, including:

• simpler process execution APIs
• deadlock-free output capture
• better handle inheritance control
• standard handle redirection to safe handles
• KillOnParentExit, StartDetached, and SafeProcessHandle APIs
• better performance and lower allocations for common process scenarios

Reference:

• https://devblogs.microsoft.com/dotnet/process-api-improvements-in-dotnet-11/

Motivation

Stride currently uses ProcessStartInfo in several places for launching external tools and shell commands. These call sites should be reviewed once we evaluate adopting .NET 11+, because some of them may be able to use newer APIs with better correctness, performance, and maintainability.

This is especially relevant for scenarios that:

• launch cmd.exe, dotnet, explorer.exe, or other external tools
• redirect standard output / error
• wait on child processes
• rely on short-lived or long-running helper processes
• may benefit from explicit handle inheritance or detached process behavior

Existing call sites to review

• sources/core/Stride.Core.Design.Tests/Extensions/TestProcessExtensions.cs
• sources/editor/Stride.Core.Assets.Editor/ViewModel/SessionViewModel.cs:847-848
• tests/editor/NuGetConsumerTests.cs:46-57

Scope for future refactoring

Audit all ProcessStartInfo usage across the solution and classify each case:

1. Simple command execution

   • consider Process.Run(...) / Process.RunAsync(...)
   • consider Process.RunAndCaptureText(...) / Process.RunAndCaptureTextAsync(...) when output is needed

2. Output capture

   • replace ad hoc RedirectStandardOutput / RedirectStandardError patterns where possible
   • verify deadlock-safe behavior and cancellation/timeout handling

3. File/folder launching

   • review whether explorer.exe / shell-specific launching still needs manual ProcessStartInfo
   • prefer the safest and most idiomatic platform-specific approach

4. Lifecycle control

   • review whether any helper processes should use KillOnParentExit
   • review whether detached execution is needed

5. Handle inheritance

   • review any process launch that depends on inherited handles
   • consider explicit InheritedHandles / standard handle redirection APIs

Suggested acceptance criteria

• Inventory all ProcessStartInfo usages in the repository
• Categorize each usage by intent: launch-only, output capture, file open, helper process, tests, etc.
• Identify candidates that could benefit from .NET 11 process APIs
• Document which call sites should be updated immediately after the .NET 11 upgrade
• Add follow-up work items for any platform-specific or behavioral changes that need verification
• Ensure any refactor preserves current behavior on Windows and Unix

Notes

This is not necessarily an immediate code change request. It is a future refactoring and modernization task to revisit when Stride moves to .NET 11 or begins evaluating preview adoption.