visual-studio 检查应用程序是否从 Visual Studio 调试会话中启动
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/101806/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Check if application was started from within Visual Studio debug session
提问by Grimtron
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.
我正在开发一个安装系统范围键盘挂钩的应用程序。当我从 Visual Studio 内部运行调试版本时，我不想安装这个钩子（否则它会挂起 Studio 并最终挂起系统），我可以通过检查是否定义了 DEBUG 符号来避免这种情况。
However, when I debug the releaseversion 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.
但是，当我调试应用程序的发布版本时，有没有办法检测它是从 Visual Studio 内部启动的，以避免出现同样的问题？不得不重新启动工作室/计算机非常烦人，仅仅因为我一直在处理发布版本，并且想使用调试器修复一些错误，而忘记切换回调试版本。
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.
我将其称为“蛮力方式”，它适用于我的设置，但我想知道是否有另一种（更好的）方法来检测这种情况。
回答by TraumaPony
回答by William Casarin
For those working with Windows API, there's a function which allows you to see if any debugger is present using:
对于那些使用 Windows API 的人，有一个功能可以让您查看是否存在任何调试器：
if( IsDebuggerPresent() )
{
...
}
Reference: http://msdn.microsoft.com/en-us/library/ms680345.aspx
回答by TonyT
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.
测试当前进程的模块名称是否包含字符串“.vshost”是我发现的确定应用程序是否在 VS IDE 中运行的最佳方法。
Using the System.Diagnostics.Debugger.IsAttachedproperty is also okay but it does not allow you to distinguish if you are running the EXE through the VS IDE's Runcommand 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.
使用System.Diagnostics.Debugger.IsAttached属性也可以，但它不允许您区分是通过 VS IDE 的Run命令运行 EXE还是直接运行调试版本（例如使用 Windows 资源管理器或快捷方式） )，然后使用 VS IDE 附加到它。
You see I once encountered a problem with a (COM related) Data Execution Preventionerror that required me to run a Post Build Eventthat would execute editbin.exewith the /NXCOMPAT:NOparameter on the VS generated EXE.
你看我曾经遇到过一个（与 COM 相关的）数据执行保护错误的问题，需要我运行一个构建后事件，该事件将在 VS 生成的 EXE 上使用/NXCOMPAT:NO参数执行editbin.exe。
For some reason the EXE was not modified if you just hit F5and run the program and therefore AccessViolationExceptionswould 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.
出于某种原因，如果您只是按F5并运行程序，则不会修改 EXE ，因此如果从 VS IDE 中运行，违反 DEP 的代码会发生AccessViolationExceptions- 这使得调试变得非常困难。但是，我发现如果我通过快捷方式运行生成的 EXE，然后附加 VS IDE 调试器，我就可以测试我的代码，而不会发生 AccessViolationExceptions。
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.
所以现在我创建了一个使用“vshost”方法的函数，如果我只是在 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.
这可以防止那些讨厌的 AccessViolationExceptions 被引发，从而在我无意中尝试运行一些我知道会导致我悲伤的东西时使我的应用程序致命地崩溃。
