stride3d / stride3d/stride

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

Open
#3,225 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
C#
Stars
7.8k
Forks
1.2k
Avg merge
2d 17h
Merged PRs (30d)
49

Description

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:

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.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Search the repository for ProcessStartInfo usage, beginning with TestProcessExtensions.cs, SessionViewModel.cs:847-848, and NuGetConsumerTests.cs:46-57. Read the .NET 11 process API reference, then classify each call site by intent and record which candidates need modernization, immediate follow-up, or behavioral verification on Windows and Unix.

Written by the indexing model from the issue text.

Assessment

Tech stack
csharp
Domain
operating-systems, tooling
Issue type
Refactor
Difficulty
4/5
Estimated time
3-5 days
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
45/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.