Compruebe si la aplicación se inició desde Visual Studio

Question

Estoy trabajando en una aplicación que instala un gancho de teclado de sistema completo . No quiero instalar este enlace cuando estoy ejecutando una depuración compilación desde el interior del estudio visual (o de lo contrario colgaría el estudio y, finalmente, el sistema), y puedo evitar esto comprobando si el símbolo DEBUG está definido .

Sin embargo, cuando puedo depurar la versión liberación de la aplicación, no es una manera de detectar que se ha iniciado desde el interior Visual Studio para evitar el mismo problema? Es muy molesto tener que reiniciar el estudio/la computadora, solo porque he estado trabajando en la versión de lanzamiento y quiero corregir algunos errores usando el depurador que tiene olvidado para volver a la compilación de depuración.

Actualmente utilizo algo como esto para comprobar si este escenario:

System.Diagnostics.Process currentProcess = System.Diagnostics.Process.GetCurrentProcess(); 
string moduleName = currentProcess.MainModule.ModuleName; 
bool launchedFromStudio = moduleName.Contains(".vshost"); 

diría que era el "camino de la fuerza bruta", que funciona en mi entorno, pero me gustaría saber si hay otra (mejor) forma de detectar este escenario.

Answer 1

Probar: System.Diagnostics.Debugger.IsAttached.

Answer 2

Desaconsejaré encarecidamente el uso del código que solo se ejecuta en el momento de la depuración. ¿Por qué? Le gustaría asegurarse de que lo que entre en producción sea lo que está probando/viendo localmente. Esto es especialmente cierto en el lenguaje de nivel inferior que utiliza, ya que a menudo las diferencias en el código hacen que el compilador produzca su máquina/IL de manera diferente.

Quizás con el propósito de descubrir un problema, pero eso es todo.

Answer 3

Para aquellos que trabajan con el API de Windows, hay una función que le permite ver si alguno depurador está presente usando:

if(IsDebuggerPresent()) 
{ 
    ... 
} 

Referencia: http://msdn.microsoft.com/en-us/library/ms680345.aspx

Answer 4

Pruebas de si es o no el nombre del módulo de la corriente proceso contiene la cadena ".vshost" es la mejor forma que he encontrado para determinar si la aplicación se está ejecutando o no dentro del VS IDE.

Utilizando el System.Diagnostics.Debugger.IsAttached alojamiento se encuentra bien, pero que no permite a distinguir si se está ejecutando el EXE a través Run orden del IDE de VS o si está ejecutando la depuración construir directamente (por ejemplo, usando Windows Explorer o un acceso directo) y luego adjuntarlo usando el VS IDE.

Ya ve que una vez detectado un problema con un (COM relacionada) Prevención de ejecución de datos error que me requiere para ejecutar un mensaje Generar eventos que ejecutar Editbin.exe con el /NXCOMPAT: NO parámetro en el EXE generado VS.

Por alguna razón el EXE no se modificó, si usted acaba de golpear F5 y ejecutar el programa y por lo tanto AccessViolationExceptions se produciría el código DEP-violar si se ejecuta desde el IDE de VS - lo que hacía extremadamente difícil depurar. Sin embargo, descubrí que si ejecutaba el EXE generado a través de un atajo y luego adjuntaba el depurador VS IDE, podía probar mi código sin que se produjeran AccessViolationExceptions.

Así que ahora he creado una función que usa el método "vshost" que puedo usar para advertir, o bloquear, que se ejecute cierto código si solo estoy haciendo mi programación diaria dentro del VS IDE.

Esto evita que se levanten esas desagradables AccessViolationExceptions y, por lo tanto, bloquee fatalmente mi aplicación si inadvertidamente intento ejecutar algo que sé que me causará dolor.