2016-06-10 16 views
6

Sto scrivendo un programma di console per l'utilità di pianificazione di Windows da eseguire. Il metodo Main() ha un tipo restituito int e restituisco numeri diversi quando si esce per indicare il risultato dell'esecuzione, a cui è possibile accedere in uno script .BAT come %errorlevel%.Applicazione console C#: metodo principale valore di ritorno VS Application.ExitCode

Tuttavia durante il debug in VS2015, faccio un

return 255; 

e ho sempre ottenere dalla finestra Output di VS2015:

The program '[43560] Foo.vshost.exe' has exited with code 0 (0x0). 

Ora, se voglio che la finestra di output per visualizzare il codice di uscita del mio programma devo fare un Application.Exit(255) per poter mostrare

The program '[24400] Foo.vshost.exe' has exited with code 255 (0xff). 

Cosa c'è di strano è %errorlevel% impostato correttamente su 255 se eseguo il programma in CMD.exe con l'istruzione return o Environment.Exit().

Quindi la mia domanda è

  1. è il valore di ritorno di Main() un po 'diverso per Environment.ExitCode?

  2. Qual è il modo per trovare facilmente il valore restituito del metodo Main() in VS2015?

  3. Quando si esce da un programma di console, è preferibile il numero Environment.Exit() rispetto a un semplice rendiconto? Perché una dichiarazione di ritorno è più concisa ai miei gusti.

Qualcuno potrebbe dirmi la storia dietro questo? Grazie.

risposta

6

Il valore di ritorno di Main() è leggermente diverso da Environment.ExitCode?

No, sono uguali e vanno nello stesso posto. Puoi vedere questo sperimentando un'applicazione per console che restituisce -1 o imposta Environment.ExitCode su -1. Vedrai che qualsiasi metodo tu usi funziona e imposta %ERRORLEVEL% correttamente.

Qual è il modo per individuare facilmente il valore restituito dal metodo Main() in VS2015?

In primo luogo, una rapida parentesi su ciò che sembra accadere. Ecco l'analisi dello stack per un'applicazione console creata utilizzando le impostazioni predefinite del progetto:

TestApp.exe!TestApp.Program.Main(string[] args) 
[Native to Managed Transition] 
[Managed to Native Transition] 
mscorlib.dll!System.AppDomain.ExecuteAssembly(string assemblyFile, System.Security.Policy.Evidence assemblySecurity, string[] args) 
Microsoft.VisualStudio.HostingProcess.Utilities.dll!Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly() 
mscorlib.dll!System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) 
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state, bool preserveSyncCtx) 
mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) 
mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() 

noti che il processo host VS è lì.Con il processo di hosting VS disabilitata la traccia dello stack (con le stesse opzioni) si presenta così:

TestApp.exe!TestApp.Program.Main(string[] args) 

Se si guarda alla definizione di ThreadHelper.ThreadStart nel reference source lo vedrai definito come:

internal void ThreadStart(object obj) 

Sembra che questo ritorno vuoto sia utilizzato come valore di ritorno del processo, oppure uno degli altri metodi sopra di esso sta consumando il valore restituito e ingoiandolo.

Se si modifica la configurazione di progetto e disattivare il processo di hosting quindi si otterrà un output simile:

The program '[7992] TestApp.exe' has exited with code -1 (0xffffffff). 

come previsto. Per disabilitare il processo di hosting, andare alle proprietà del progetto, e nella scheda di debug, deselezionare l'opzione "Abilita il Visual Studio che ospita il processo"

Quando si esce un programma di console, è Environment.Exit() preferito di una semplice dichiarazione di ritorno? Perché una dichiarazione di ritorno è più concisa ai miei gusti.

Qualunque sia la vostra preferenza. Come sottolineato da Jeppe Stig in un commento, per ulteriori informazioni sulle differenze, consultare la documentazione di Environment.Exit

+0

Vedere anche [la documentazione del metodo 'Environment.Exit (Int32)') (https://msdn.microsoft.com /en-us/library/system.environment.exit.aspx) per un elenco di differenze. –

+0

@JeppeStigNielsen Buon punto. Aggiunta una nota a riguardo nel caso in cui il tuo commento scompaia. – theB

+2

* Preferisci * per uscire tornando dal principale. Chiamare 'Environment.Exit' è un hack e non dovrebbe essere necessario in un'applicazione ben progettata. –