Check if application was started from within Visua

Question

I am working on an application that installs a system wide keyboard hook. I do not want to install this hook when I am running a debug build from inside the visual studio (or else it would hang the studio and eventually the system), and I can avoid this by checking if the DEBUG symbol is defined.

However, when I debug the release version of the application, is there a way to detect that it has been started from inside visual studio to avoid the same problem? It is very annoying to have to restart the studio/the computer, just because I had been working on the release build, and want to fix some bugs using the debugger having forgotten to switch back to the debug build.

Currently I use something like this to check for this scenario:

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

I would call this the "brute force way", which works in my setting, but I would like to know whether there's another (better) way of detecting this scenario.

Answer 1

Testing whether or not the module name of the current process contains the string ".vshost" is the best way I have found to determine whether or not the application is running from within the VS IDE.

Using the System.Diagnostics.Debugger.IsAttached property is also okay but it does not allow you to distinguish if you are running the EXE through the VS IDE's Run command or if you are running the debug build directly (e.g. using Windows Explorer or a Shortcut) and then attaching to it using the VS IDE.

You see I once encountered a problem with a (COM related) Data Execution Prevention error that required me to run a Post Build Event that would execute editbin.exe with the /NXCOMPAT:NO parameter on the VS generated EXE.

For some reason the EXE was not modified if you just hit F5 and run the program and therefore AccessViolationExceptions would occur on DEP-violating code if run from within the VS IDE - which made it extremely difficult to debug. However, I found that if I run the generated EXE via a short cut and then attached the VS IDE debugger I could then test my code without AccessViolationExceptions occurring.

So now I have created a function which uses the "vshost" method that I can use to warn about, or block, certain code from running if I am just doing my daily programming grind from within the VS IDE.

This prevents those nasty AccessViolationExceptions from being raised and thereby fatally crashing the my application if I inadvertently attempt to run something that I know will cause me grief.

Answer 2

Try: System.Diagnostics.Debugger.IsAttached

Answer 3

For those working with Windows API, there's a function which allows you to see if any debugger is present using:

if( IsDebuggerPresent() )
{
    ...
}

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

Answer 4

I would strongly discourage the use of code that only gets run at debug time. Why? You'd like to make sure that what goes into production is what you're testing / seeing locally. This is especially true the lower level language you use as often times differences in code causes the compiler to produce your machine / IL differently.

Perhaps for the purposes of discovering an issue, but that's about it.