Проверьте, было ли приложение запущено из сеанса отладки Visual Studio
Я работаю над приложением, которое устанавливает общесистемную клавиатуру крюк. Я не хочу устанавливать этот хук, когда я запускаю отладку строить изнутри визуальной студии (иначе это повесит студию и, в конечном итоге, систему), и я могу избежать этого, проверив, Определен символ DEBUG.
Однако, когда я отлаживаю версию приложения релиз, есть способ определить, что он был запущен изнутри визуального studio, чтобы избежать той же проблемы? Это очень раздражает, когда приходится перезапустите студию / компьютер только потому, что я работал над сборку выпуска и хотите исправить некоторые ошибки с помощью отладчика, имеющего забыл вернуться к отладочной сборке.
В настоящее время я использую что-то вроде этого, чтобы проверить этот сценарий:
System.Diagnostics.Process currentProcess = System.Diagnostics.Process.GetCurrentProcess();
string moduleName = currentProcess.MainModule.ModuleName;
bool launchedFromStudio = moduleName.Contains(".vshost");
Я бы назвал это «методом грубой силы», который работает в моих условиях, но я хотел бы знать, есть ли другой (лучший) способ обнаружения этого сценария.
Ответы 3
Попробуйте: System.Diagnostics.Debugger.IsAttached
(Обновленный комментарий) Debugger.IsAttached адекватен и удовлетворяет многим требованиям. Однако он касается только того, подключен ли отладчик (любой отладчик, включая WinDbg). Если вы работаете в среде IDE без отладки, он не всегда будет работать так, как заявлено. Предлагаемый OP код - лучший способ определить, работает ли программа в среде IDE. ПРИМЕЧАНИЕ: тесты CodedUI не используют "vshost". Вместо этого они, среди прочего, используют QTAgent.exe, QTAgent32.exe и QTAgent64.exe. Так что используйте moduleName.ToLower.Contains("qtagent");.
@Barniferous, похоже, начиная с VS 2017 проверка ".vshost" больше не работает, поскольку VS 2017 перестала добавлять его к имени. Я не знаю, что делают тесты CodedUI ...
Для тех, кто работает с Windows API, есть функция, которая позволяет узнать, присутствует ли какой-либо отладчик, используя:
if ( IsDebuggerPresent() )
{
...
}
Ссылка: http://msdn.microsoft.com/en-us/library/ms680345.aspx
Я использовал этот подход, но затем увидел блог по следующей ссылке, где он утверждает, что отключил IsDebuggerPresent через скрипт: blogs.msdn.microsoft.com/debuggingtoolbox/2007/05/23/…
Проверка того, содержит ли имя модуля текущего процесса строку ".vshost", - лучший способ, который я нашел, чтобы определить, работает ли приложение из VS IDE.
Использование свойства System.Diagnostics.Debugger.IsAttached также нормально, но оно не позволяет вам различать, запускаете ли вы EXE через команду Пробег VS IDE или запускаете отладочную сборку напрямую (например, с помощью проводника Windows или ярлыка), а затем присоединяетесь к нему. с помощью VS IDE.
Видите ли, однажды я столкнулся с проблемой (связанной с COM) ошибкой Предотвращение выполнения данных, которая потребовала от меня запустить Событие после сборки, который будет выполнять editbin.exe с параметром / NXCOMPAT: НЕТ в созданном VS EXE.
По какой-то причине EXE не был изменен, если вы просто нажали F5 и запустите программу, и поэтому AccessViolationExceptions будет возникать в коде, нарушающем DEP, если запускаться изнутри VS IDE, что чрезвычайно затрудняло отладку. Тем не менее, я обнаружил, что если я запустил сгенерированный EXE с помощью сокращенного набора, а затем подключил отладчик VS IDE, я мог бы протестировать свой код без возникновения исключений AccessViolationExceptions.
Итак, теперь я создал функцию, которая использует метод «vshost», который я могу использовать для предупреждения или блокировки выполнения определенного кода, если я просто занимаюсь ежедневным программированием из среды VS IDE.
Это предотвращает возникновение этих неприятных исключений AccessViolationExceptions и, тем самым, фатального сбоя моего приложения, если я непреднамеренно попытаюсь запустить что-то, что, как я знаю, вызовет у меня горе.
Правильно, также не забывайте такие вещи, как удаленная отладка, другие отладчики, кроме Visual Studio и т. д.
См. Мой комментарий под сообщением OP, вы получите разные имена модулей, если запустите тестовый проект или проект IIS Express.
Раньше я также проверял наличие «.vshost», но теперь похоже, что начиная с VS 2017 проверка «.vshost» больше не работает, поскольку VS 2017 перестала добавлять его к имени. Я наткнулся на эту ветку в поисках нового способа обнаружения отладки из VS.
Примечание. При использовании этой техники vstest.executionengine.x86.exe WebDev.WebServer20.exe запускается из теста Visual Studio и через код, работающий под IIS Express. Так что любому, кто это читает, возможно, придется соответствующим образом скорректировать код.