Introduction

The .NET equivalent of classic Win32 ShellExecute is Process.Start used with ProcessStartInfo. The important decision is whether the OS shell should resolve the target for you or whether you want direct process control. In practice, that usually comes down to UseShellExecute = true for opening files and URLs, and UseShellExecute = false for launching executables with redirected output.

Open a URL or File with the OS Shell

If you want behavior similar to double-clicking a document or opening a URL in the default browser, use the shell.

1using System.Diagnostics;
2
3var psi = new ProcessStartInfo
4{
5    FileName = "https://example.com",
6    UseShellExecute = true
7};
8
9Process.Start(psi);

The same pattern works for local files:

1using System.Diagnostics;
2
3var psi = new ProcessStartInfo
4{
5    FileName = @"C:\reports\weekly.pdf",
6    UseShellExecute = true
7};
8
9Process.Start(psi);

With UseShellExecute = true, the operating system uses file associations and registered handlers.

Launch an Executable Directly

If you want to run a command and manage it explicitly, use direct process execution instead of shell resolution.

1using System;
2using System.Diagnostics;
3
4var psi = new ProcessStartInfo
5{
6    FileName = "dotnet",
7    Arguments = "--info",
8    UseShellExecute = false,
9    RedirectStandardOutput = true,
10    RedirectStandardError = true,
11    CreateNoWindow = true
12};
13
14using var process = Process.Start(psi);
15string stdout = process!.StandardOutput.ReadToEnd();
16string stderr = process.StandardError.ReadToEnd();
17process.WaitForExit();
18
19Console.WriteLine(stdout);
20Console.WriteLine(stderr);

This is the right pattern when you need stdout, stderr, exit code, or strict control over the launched process.

Choose UseShellExecute Based on Intent

A practical rule:

• use true for “open this as the user would”
• use false for “run this executable under program control”

These modes are not interchangeable. For example, stream redirection requires UseShellExecute = false.

Elevation and Verbs

On Windows, ShellExecute-style verbs such as runas are also exposed through ProcessStartInfo.

1using System.Diagnostics;
2
3var psi = new ProcessStartInfo
4{
5    FileName = "powershell.exe",
6    Arguments = "-NoProfile -Command \"Write-Output elevated\"",
7    UseShellExecute = true,
8    Verb = "runas"
9};
10
11Process.Start(psi);

This triggers elevation behavior when supported by the host environment.

Safer Argument Passing

If user input is involved, avoid building command lines through raw string concatenation. Use ArgumentList when available.

1using System.Diagnostics;
2
3var psi = new ProcessStartInfo("git")
4{
5    UseShellExecute = false
6};
7
8psi.ArgumentList.Add("status");
9psi.ArgumentList.Add("--short");
10
11using var process = Process.Start(psi);

This reduces quoting and escaping mistakes and lowers the risk of unintended command behavior.

Cross-Platform Notes

ProcessStartInfo exists across modern .NET runtimes, but shell behavior is still platform-dependent. Opening a URL or a document with UseShellExecute = true often works on desktop systems, but not all environments have the same shell integration.

If the application runs in a service, container, or headless Linux environment, shell-based launching may fail even when the code is correct.

Handle Errors Explicitly

Process launching can fail because of missing files, invalid permissions, or restricted execution contexts. Wrap launches in exception handling and do not assume Process.Start always succeeds.

1using System;
2using System.Diagnostics;
3
4try
5{
6    var psi = new ProcessStartInfo
7    {
8        FileName = "https://example.com",
9        UseShellExecute = true
10    };
11
12    Process? process = Process.Start(psi);
13    if (process == null)
14    {
15        Console.WriteLine("Process did not start.");
16    }
17}
18catch (Exception ex)
19{
20    Console.WriteLine($"Launch failed: {ex.Message}");
21}

This matters especially in restricted production environments.

Common Pitfalls

The most common mistake is enabling standard-output redirection while also using UseShellExecute = true. That combination does not work.

Another issue is expecting shell-style document or URL opening with UseShellExecute = false. Direct execution mode is for running commands, not file-association resolution.

Developers also sometimes concatenate raw user input into Arguments, which creates quoting bugs and can become a security issue.

Summary

• 'ProcessStartInfo plus Process.Start is the .NET replacement for ShellExecute behavior.'
• Use UseShellExecute = true for opening URLs and documents with default handlers.
• Use UseShellExecute = false for direct executable control and output capture.
• Use Verb = "runas" when Windows elevation behavior is required.
• Validate launch assumptions in the real target environment, not only on a developer desktop.