Консольное приложение C#: основное возвращаемое значение метода против приложения.Exitcode содержит

я пишу консольную программу для запуска планировщика задач windows. Мой Main() метод имеет тип возвращаемого int и я возвращаю разные номера при выходе, чтобы указать результат выполнения, к которому я могу получить доступ в .BAT скрипт %errorlevel%.

однако при отладке в VS2015, я делаю

return 255;

и я всегда получаю из окна вывода VS2015:

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

теперь, если я хочу, чтобы в окне вывода отображался код выхода моего программа Я должен сделать Application.Exit(255) для того, чтобы показать

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

что странно -%errorlevel% правильно установлено значение 255, если я запускаю программу в CMD.exe С помощью оператора return или Environment.Exit().

у меня вопрос

  1. возвращаемое значение Main() отличается от Environment.ExitCode?

  2. как легко узнать возвращаемое значение Main() метод VS2015?

  3. при выходе из консольной программы, составляет Environment.Exit() предпочтительнее, чем простой оператор возврата? Потому что ответная фраза более лаконична на мой вкус.

может кто-нибудь рассказать мне историю, стоящую за этим? Спасибо.

1 ответов


- возвращаемое значение Main () несколько отличается от окружения.Exitcode содержит?

нет, они одинаковы и идут в одно и то же место. Вы можете увидеть это, экспериментируя с консольным приложением, которое просто возвращает -1 или устанавливает Environment.ExitCode к-1. Вы увидите, что какой бы метод вы ни использовали работает и устанавливает %ERRORLEVEL% правильно.

каков способ легко узнать возвращаемое значение метода Main () в VS2015?

во-первых, небольшое отступление о том, что, кажется, происходит. Вот трассировка стека для консольного приложения, созданного с использованием параметров проекта по умолчанию:

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()

обратите внимание, что процесс VS host существует. При отключенном процессе размещения VS трассировка стека (с теми же параметрами) выглядит следующим образом:

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

если вы посмотрите на определение ThreadHelper.ThreadStart на источник вы увидите, что он определен as:

internal void ThreadStart(object obj)

кажется, что либо это void return используется в качестве возвращаемого значения процесса, либо один из других методов выше него потребляет возвращаемое значение и проглатывает его.

если вы измените конфигурацию проекта и отключите процесс хостинга, вы получите вывод, как:

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

как вы и ожидали. Чтобы отключить процесс размещения, перейдите к свойствам проекта и на вкладке отладка снимите флажок " Включить хостинг Visual Studio процесс"

при выходе из консольной программы-это среда.Exit () предпочтительнее, чем простой оператор return? Потому что ответная фраза более лаконична на мой вкус.

какой вы предпочитаете. Как отметил Йеппе Стиг в комментарии, для получения дополнительной информации о различиях см. документацию для Environment.Exit