Обнаружение, если программа была запущена Visual Studio, в отличие от запуска из проводника Windows

18

Есть ли способ определить, была ли ваша программа загружена через Visual Studio по сравнению с ее запуском как автономным исполняемым файлом?

В нашем программном обеспечении есть функция уведомления об ошибках для обработки необработанных исключений - нам нужно иметь возможность распространять отладочные сборки для наших бета-тестеров, но мы не хотим, чтобы отчет об ошибках удалялся, когда мы находимся в середине разработки , потому что Исключения намного полезнее, если VS улавливает их с полной трассировкой стека и т. д.

В настоящее время я отключу отчет об ошибке, если Application.ExecutablePath включает bin \ Debug или bin \ Release, но я считаю, что, вероятно, существует более надежный способ определения, была ли программа загружена через VS.

Очевидно, мы могли бы создать другую сборку с некоторыми макросами препроцессора, но, ради вопроса, предположим, что это не возможно - я не против добавления кода, но я пытаюсь сделать меньше всего изменений в процессе сборки, поэтому параметры командной строки также являются последним средством.

Если это имеет значение, я использую VS2003 / .NET 1.1.

    
задан Mark Rushakoff 27.08.2009 в 20:43
источник

5 ответов

41

Если вы делаете это, чтобы определить, находится ли он в любом отладчике (уточняется @JaredPar ), вы можете использовать Debugger.IsAttached в обработчике исключений.

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

В качестве альтернативы:

public static void Frob(Exception ex)
{
    if (Debugger.IsAttached)
    {
        Debugger.Break();
    }
}
    
ответ дан user7116 27.08.2009 в 20:48
источник
  • Это точно один из тех, «я не знаю, что я ищу, но я это знаю, когда увижу» ответы - отлично, спасибо! –  Mark Rushakoff 27.08.2009 в 21:00
  • System.Diagnostics имеет много сочной доброты. –  user7116 27.08.2009 в 21:02
  • . Остерегайтесь того, что это будет связано с подключением любого отладчика, а не при подключении Visual Studio. Прикрепление WinDbg приведет к такому же поведению. –  JaredPar 27.08.2009 в 21:46
  • У наших «бета-тестеров» никогда не будет отладчика; но если бы они это сделали, они бы очень просили, чтобы функция сообщения об ошибках была отключена: P –  Mark Rushakoff 28.08.2009 в 04:23
  • Обратите внимание, что это не сработает, если вы запустите его в режиме Release из Visual Studio. И это также не сработает, если вы запустите его в режиме отладки, но без отладчика (Ctrl + F5). –  Robert S. 15.04.2018 в 15:25
2

Вы считали аргументы командной строки? Запустите программу из Visual Studio с флагом -no-exception-handling (или любым другим звуком) и не обрабатывайте исключения, если этот аргумент передан. Когда вы запускаете программу в другом месте, без этого аргумента, это будет вести себя нормально.

    
ответ дан Rogier Van Etten 27.08.2009 в 20:47
источник
1

Я не занимаюсь разработкой .net, но в java я это сделал, передав флаг в параметры запуска приложения. Таким образом, вы можете передать флаг отладки в приложение из IDE, а затем проверить это, когда приложение запускается как исполняемый файл, флаг не будет присутствовать. Я был бы удивлен, если у .net не было чего-то подобного.

    
ответ дан broschb 27.08.2009 в 20:47
источник
  • Я стараюсь как можно больше не модифицировать процесс сборки / запуска, но да, вы можете читать параметры командной строки в .NET тоже :) –  Mark Rushakoff 27.08.2009 в 20:49
0

Вместо отслеживания по дереву процессов я бы добавил флаг конфигурации, который позволяет использовать функцию отчетности. Флаг всегда может по умолчанию использовать значение «true», если вы не находитесь в вашей среде DEV, а затем установите значение «false».     

ответ дан djangofan 27.08.2009 в 20:51
источник
0

Я знаю, что это старо, но предоставленные решения не очень удовлетворяют.

Вместо этого я использовал следующий класс:

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;
        }
    }
}

Тогда вы можете просто использовать Program.ExecutablePath . Если у вас уже есть класс с именем Program , вы можете просто расширить его этими свойствами и методами.

При запуске из Visual Studio он предоставит вам путь к проекту, где находится файл csproj. Это путь к исполняемому файлу без файлов «bin \ * \ Debug» или «bin \ * \ Release».

Если он не запущен из Visual Studio, он предоставит вам путь, в котором находится исполняемый файл.

Решение не зависит от настроек отладки, других прикрепленных отладчиков или конфигураций сборки. Важно только то, что ваши конфигурации называются «Release» и «Debug».

    
ответ дан Robert S. 15.04.2018 в 14:39
источник