When do we need to set ProcessStartInfo.UseShellExecute to True?

//
// Summary:
//     Gets or sets a value indicating whether to use the operating system shell
//     to start the process.
//
// Returns:
//     true to use the shell when starting the process; otherwise, the process is
//     created directly from the executable file. The default is true.
[DefaultValue(true)]
[Monitorin开发者_JS百科gDescription("ProcessUseShellExecute")]
[NotifyParentProperty(true)]
public bool UseShellExecute { get; set; }

If we spawn a new process, when do we need to set UseShellExecute to True?

The UseShellExecute boolean property is related to the use of the windows ShellExecute function vs the CreateProcess function - the short answer is that if UseShellExecute is true then the Process class will use the ShellExecute function, otherwise it will use CreateProcess.

The longer answer is that the ShellExecute function is used to open a specified program or file - it is roughly equivalnt to typing the command to be executed into the run dialog and clicking OK, which means that it can be used to (for example):

• Open .html files or web using the default browser without needing to know what that browser is,
• Open a word document without needing to know what the installation path for Word is
• Run any command on the PATH

For example:

Process p = new Process();
p.StartInfo.UseShellExecute = true;
p.StartInfo.FileName = "www.google.co.uk";
p.Start();

It is very easy to use, versatile and powerful however comes with some drawbacks:

• It isn't possible to redirect the standard input / output / error handles

• It isn't possibly to specify security descriptors (or other cool things) for the child process

• There is a potential to introduce security vulnerabilities if you make assumptions about what will actually be run:

   // If there is an executable called "notepad.exe" somewhere on the path 
   // then this might not do what we expect
   p.StartInfo.FileName = "notepad.exe";
   p.Start();
  

CreateProcess is a far more precise way of starting a process - it doesn't search the path and allows you to redirect the standard input or output of the child process (among other things). The disadvantage of CreateProcess however is that none of the 3 examples I gave above will work (try it and see).

In summary, you should set UseShellExecute to false if:

• You want to redirect the standard input / output / error (this is the most common reason)
• You don't want to search the path for the executable (e.g. for security reasons)

Conversely you should keep UseShellExecute true if you want to open documents, urls or batch files etc... rather than having to explicitly give the path to an executable.

I think mostly for non-executables. For instance if are trying to open a .html file, if you'll have to set UseShellExecute to true and that will open the .html in a browser that's set as default by the user.

From MSDN:

Setting this property to false enables you to redirect input, output, and error streams.

UseShellExecute must be false if the UserName property is not null or an empty string, or an InvalidOperationException will be thrown when the Process.Start(ProcessStartInfo) method is called.

When you use the operating system shell to start processes, you can start any document (which is any registered file type associated with an executable that has a default open action) and perform operations on the file, such as printing, with the Process component. When UseShellExecute is false, you can start only executables with the Process component.

UseShellExecute must be true if you set the ErrorDialog property to true.

If we want to hide the current Application executable window , Then UseShellExecute should be set to true

When the path contains a space or some other special (i.e. accented) characters, CreateProcess (UseShellExecute=false) seems to be using short file names ("DOS" 8.3 notation), ShellExecute (UseShellExecute=true) uses long file names. So when you use UseShellExecute=false, make sure to convert your directory and file names to 8.3 names (google ".net how to get 8.3 filename"). (Not exectly sure what Windows versions and/or file systems do it this way, tested on Windows 7, NTFS.)