Oltre a non avere a disposizione il Regedit.exe, mi sono ritrovato a non avere la possibiltà di usare la riga comandi. Non so voi, ma io preferisco digitare services.msc piuttosto che girare per menù a suon di click!!
Come fare? Il primo pensiero è stato "scrivo in VB e uso la funzione Shell": il ragionamento non fa un grinza, tutti i programmi partono che è una bellezza; il problema si pone nel momento in cui voglio usare il tanto amato services.msc... Errore!!! Il programma services.msc non esiste!!!! Ovvio: non è un programma... come faccio a far sì che la shell del sistema operativo interpreti il comando che gli passo (anche se fosse c: o pippo.doc)?? la risposta è System.Diagnostic.Process.Start
Le possibilità per utilizzarlo sono tre (tante quante gli overrides disponibili): la prima, la più semplice, è passare alla funzione Start il comando (qualunque esso sia) in formato stringa e che restituisce un riferimento al processo avviato.
La seconda è aggiungere al comando anche una stringa di parametri (ad esempi una serie di switch - /k, -z, ecc. ecc. -)
La terza possibilità aumenta il controllo sulla modalità di avvio del processo; il tutto viene reso possibile grazie al'oggetto ProcessStartInfo. Questo simpatico oggettino (:-D) ha come finalità di essere passato al terzo dei tre overrides della funzione Start; la simpaticità dell'oggettino deriva dal fatto che posso settargli delle proprietà che fanno sì che l'avvio del processo venga modificato a piacere. CreateNoWindow bool permette di decidere se non deve essere creata la finestra del processo (attenzione se ci fosse di interazione con l'utente!!!!!); UseShellExecute bool, indica se l'attivazione del processo è delegata al sistema operativo (così è possibile passare il nome di un file e Windows attiverà il programma predefinito) oppure richiede che venga esplicitata una riga di comando compresa di parametri (es. c:\windows\notepad.exe pippo.txt); RedirectStandardError bool fa sì che il l'errore (System.Diagnostic.Process.StandardError) venga reindirizzato, magari verso un log, oppure che segua l'output standard (il monitor). Molto interessante la proprietà Verb string che mi permette di passare delle azioni particolari al processo, se previste dall'applicazione lanciata (es. il verb "print" passato a WinWord fa sì che il documento venga stampato direttamente, come se si utilizzasse la voce del menù di contesto su un file .doc); normalmente la finestra dell'applicazione viene aperta così come era stata chiusa in precedenza - se apro Word e lo chiudo massimizzato, la volta successiva, si aprirà massimizzato -, posso, però forzare la WindowsStyle dell'applicazione usando l'enum ProcessWindowsStyle.
L'eccezione che ho deciso di trappare è la System.ComponentModel.Win32Exception che mi permette di ottenere anche il codice di errore nativo cioè il codice di errore di Windows.
Al momento non mi addentro nei meandri dell'oggetto ritornatomi dalla funzione Start, ma mi riprometto che ne approfondirò l'utilizzo che è sicuramente più ampio di quello che ne ho fatto, ma, come recita il titolo, a me serviva replicarmi il Run di Windows ;-)