Quando dobbiamo impostare UseShellExecute su True?

135

//
// 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)]
[MonitoringDescription("ProcessUseShellExecute")]
[NotifyParentProperty(true)]
public bool UseShellExecute { get; set; }

Se generiamo un nuovo processo, quando dobbiamo impostare UseShellExecute su True?

c#

— xport
fonte

203

La UseShellExecuteproprietà booleana è correlata all'uso della funzione ShellExecute di Windows rispetto alla funzione CreateProcess : la risposta breve è che se UseShellExecuteè vero, la Processclasse utilizzerà la ShellExecutefunzione, altrimenti la utilizzerà CreateProcess.

La risposta più lunga è che la ShellExecutefunzione viene utilizzata per aprire un programma o un file specificato - è approssimativamente equivalente a digitare il comando da eseguire nella finestra di dialogo Esegui e fare clic su OK, il che significa che può essere utilizzato (ad esempio):

Apri i file .html o il Web utilizzando il browser predefinito senza bisogno di sapere cos'è quel browser,
Apri un documento Word senza dover sapere quale sia il percorso di installazione di Word
Esegui qualsiasi comando sul PATH

Per esempio:

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

È molto facile da usare, versatile e potente, tuttavia presenta alcuni inconvenienti:

Non è possibile reindirizzare gli handle di input / output / errore standard
Non è possibile specificare descrittori di sicurezza (o altre cose interessanti) per il processo figlio

Esiste il potenziale per introdurre vulnerabilità della sicurezza se si fanno ipotesi su ciò che verrà effettivamente eseguito:

 // 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è un modo molto più preciso di avviare un processo: non cerca il percorso e consente di reindirizzare l'input o l'output standard del processo figlio (tra le altre cose). Lo svantaggio di CreateProcesstuttavia è che nessuno dei 3 esempi che ho dato sopra funzionerà (provalo e vedi).

In sintesi, è necessario impostare UseShellExecutesu falso se:

Vuoi reindirizzare l'input / output / errore standard (questo è il motivo più comune)
Non si desidera cercare l'eseguibile nel percorso (ad es. Per motivi di sicurezza)

Viceversa dovresti rimanere UseShellExecutevero se vuoi aprire documenti, URL o file batch ecc ... piuttosto che dover dare esplicitamente il percorso a un eseguibile.

— Justin
fonte

2

Grande roba, ma scrivi che (con ShellExecute), "[si sostiene] non è possibile reindirizzare gli handle di input / output / errore standard" <- Sicuramente ciò è errato o impreciso. Anche con useShellExecute impostato su true, anche se in effetti non puoi farlo processStartInfo.RedirectStandardOutput=true, mi sembra che puoi ancora reindirizzare l'output standard facendo process.Arguments= "cmd /c dir >c:\\crp\\a.a". Allo stesso modo da una finestra di dialogo Esegui puoi farecmd /c dir>c:\crp\a.a

— barlop

4

inoltre, dici che quando UseShellExecute=falsecioè CreateProcess, non controlla il percorso, ma vedo che anche quando faccio "UseShellExecute = false" cioè presumibilmente non controlla il percorso, allora process.FileName = "cmd.exe" funziona così controllando c: \ windows \ system32. E se copio cmd.exe in c: \ windows e lo chiamo cmmmd.exe, allora faccio process1.FileName = "cmmmd.exe" che funziona troppo, quindi controlla c: \ windows, quindi sembra che stia controllando il percorso, oppure qualche gruppo di directory.

— barlop

2

I documenti MSDN concordano con @barlop: "Quando UseShellExecute è falso, la proprietà FileName può essere un percorso completo dell'eseguibile o un semplice nome eseguibile che il sistema tenterà di trovare all'interno delle cartelle specificate dalla variabile d'ambiente PATH."

— Bob,

Impostando UseShellExecutesu truesono stato in grado di condividere una variabile di ambiente (che è stata creata solo nel processo di chiamata). Molto utile

— Mitkins,

14

Penso soprattutto ai non eseguibili. Ad esempio, se stai provando ad aprire un .htmlfile, se devi impostare UseShellExecutesu truee questo si aprirà .htmlin un browser impostato come predefinito dall'utente.

— Bala R
fonte

12

Da MSDN :

L'impostazione di questa proprietà su false consente di reindirizzare flussi di input, output ed errori.

UseShellExecute deve essere falso se la proprietà UserName non è null o una stringa vuota, oppure verrà generata una InvalidOperationException quando viene chiamato il metodo Process.Start (ProcessStartInfo).

Quando si utilizza la shell del sistema operativo per avviare i processi, è possibile avviare qualsiasi documento (che è qualsiasi tipo di file registrato associato a un eseguibile con un'azione aperta predefinita) ed eseguire operazioni sul file, ad esempio la stampa, con il componente Processo. Quando UseShellExecute è falso, è possibile avviare solo file eseguibili con il componente Processo.

UseShellExecute deve essere true se si imposta la proprietà ErrorDialog su true.

— Cheng Chen
fonte

0

Se vogliamo nascondere la finestra eseguibile dell'applicazione corrente, UseShellExecute dovrebbe essere impostato su true

— finto
fonte

0

Quando il percorso contiene uno spazio o altri caratteri speciali (ad esempio accentati), CreateProcess (UseShellExecute = false) sembra utilizzare nomi di file brevi (notazione "DOS" 8.3), ShellExecute (UseShellExecute = true) utilizza nomi di file lunghi. Quindi quando usi UseShellExecute = false, assicurati di convertire i nomi di directory e file in nomi 8.3 (google ".net come ottenere il nome file 8.3"). (Non sono sicuro di quali versioni di Windows e / o file system lo facciano, testato su Windows 7, NTFS.)

— balintn
fonte

Potrebbe essere che stia semplicemente tagliando il percorso nello spazio? Mettere virgolette intorno al "nome percorso / programma" risolve questo problema.

— Gbarry,