检测程序是否由Visual Studio运行，而不是从Windows资源管理器运行

Question

Is there a way to detect if your program was loaded through Visual Studio vs. whether it was started as a standalone executable?

Our software has a bug reporting feature to handle unhandled exceptions -- we need to be able to distribute debug builds to our beta testers, but we don't want the bug report to go off when we are in the middle of development, because the Exceptions are a lot more useful if VS catches them with a full stack trace, etc.

Right now, I'm disabling the bug report if Application.ExecutablePath includes bin\\Debug or bin\\Release, but I figure there is probably a more robust way of detecting whether the program was loaded through VS.

Obviously, we could set up a different build with some preprocessor macros, but for the sake of the question, assume that isn't a possibility -- I don't mind adding code, but I'm trying to make the fewest modifications to the build process, which is why command-line options are kind of a last resort as well.

If it matters, I'm using VS2003/.NET 1.1.

Answer 1

If you're doing this to determine if it is in any debugger (clarified by @JaredPar ), you can use Debugger.IsAttached in the exception handler.

try
{
    // ...
}
catch(Exception ex)
{
    if (!Debugger.IsAttached)
    {
        ExceptionHandler.Frob(ex);
    }
    else
    {
        throw;
    }
}

Alternatively:

public static void Frob(Exception ex)
{
    if (Debugger.IsAttached)
    {
        Debugger.Break();
    }
}

Answer 2

Have you considered command line arguments? Run the program from Visual Studio with a --no-exception-handling flag (or whatever sounds appropriate), and don't handle exceptions if that argument is passed in. When you start the program elsewhere, without this argument, it'll behave normally.

Answer 3

I don't do .net development, but in java I have done this by passing a flag into the startup options of the application. So you could pass a debug flag into the app from the IDE, and then check for that, when the app is run as an executable the flag would not be present. I would be surprised if .net didn't have something similar.

Answer 4

I know this is old but the provided solutions are not very satisfying.

I used the following class instead:

using System.IO;
using System.Reflection;

public static class Program
{
    public static string ExecutablePath
    {
        get;
        private set;
    }

    static Program()
    {
        var assemblyPath = Assembly.GetEntryAssembly().Location;
        var assemblyDirectory = Path.GetDirectoryName(assemblyPath);

        if (assemblyDirectory.EndsWith(@"\Debug") || assemblyDirectory.EndsWith(@"\Release"))
        {
            string projectFile = Path.GetFileNameWithoutExtension(assemblyPath) + ".csproj";

            var root = new DirectoryInfo(assemblyDirectory);

            while (root.Parent != null)
            {
                if (File.Exists(Path.Combine(root.FullName, projectFile)))
                    break;

                root = root.Parent;

                if (root.Parent == null) // we could not find it (should not happen)
                    ExecutablePath = assemblyDirectory;
            }

            ExecutablePath = root.FullName;
        }
        else
        {
            ExecutablePath = assemblyDirectory;
        }
    }
}

Then you can just use Program.ExecutablePath . If you already have a class named Program you can just extend it by those properties and methods.

If running from Visual Studio it will give you the project path where the csproj-file resides. This is the executable path without the "bin\\*\\Debug" or "bin\\*\\Release" stuff.

If not running from Visual Studio it will give you the path where the executable resides.

The solution is independent of debug settings, other attached debuggers or build configurations. The only important thing is, that your configurations are named "Release" and "Debug".

Note: As Troy Gizzi mentioned in the comments, this solution only works if you run the executable from another directory than the output directory. For my use case (simulate the deployment directory structure with the project directory as the root directory), this is a suitable solution. In general I copy my executable later to the deployment directory and expect the same behavior as if I run my program from within Visual Studio. Content and other dependencies are located relative to the project directory in my case.

Answer 5

Instead of tracking by process tree, I would add a configuration flag that enables the reporting feature. The flag can always default to "true" unless you are in your DEV environment then you set it to "false".

Answer 6

Sometimes the application is started outside the debugger and the debugger gets attached later. (Doubleclick on a file where the application is assigned to ...) I use this code to wait for the debugger attach.

using System.Diagnostics;

Process[] procName = Process.GetProcessesByName("devenv");

if(procName.Length > 0)
  MessageBox.Show("Wait for debugger attach");