Can.NET исходный код жесткий-код точки останова отладки?

Я ищу способ в .NET (2.0, C# в частности) для исходного кода, чтобы вызвать разрыв отладки, как если бы точка останова была установлена в этой точке, без необходимости помнить, чтобы установить определенную точку останова там в отладчике, и без вмешательства в производственную среду выполнения.

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

моя попытка использовать Debug.Assert(false) было меньше, чем идеально, и я предполагаю, что Debug.Fail() будет вести себя так же. Теоретически он не должен иметь никакого эффекта в производстве, и он успешно останавливается при отладке, но по дизайну нет (насколько я могу судить) никакого способа продолжить выполнение, если вы хотите игнорировать эту ошибку, как вы могли бы с фактической точкой останова, и как это было бы в производстве, где мы проглатываем ошибка. Это также, по-видимому, нарушает оценку состояния переменной, потому что отладчик фактически останавливается в собственном системном коде, а не в нашем, поэтому отладочная помощь ограничена. (Может быть, я упускаю какой-то способ вернуться к вещам, чтобы посмотреть на переменные и так далее, где это произошло. ???)

Я надеялся на что-то вроде Debug.Break(), но он, похоже, не существует (если только не в более поздней версии .NET?), и никаких других Debug методы кажутся применимыми, любой.

обновление: хотя ответ ctacke является лучшим соответствием тому, что я искал, с тех пор я также обнаружил трюк с отладкой.Assert ()--при запуске в отладчике--приостановите отладчик, перейдите к коду для отладки.Assert call pending (выделен зеленым цветом, потому что он не работает в коде фреймворка) и нажмите Step-Out (shift-F11), затем нажмите Ignore в диалоговом окне assert. Это оставит отладчик приостановлен по возвращении assert (и в состоянии продолжайте выполнение, как если бы оно не произошло, потому что оно было проигнорировано). Могут быть и другие способы сделать то же самое (делает ли повторная попытка это более непосредственно?), но этот способ был интуитивным.

7 62
c# visual-studio-2017 breakpoints .net-2.0

7 ответов:

Вы, наверное, что-то вроде этого:

if(System.Diagnostics.Debugger.IsAttached)
  System.Diagnostics.Debugger.Break();

конечно, это все равно будет скомпилировано в сборке выпуска. Если вы хотите, чтобы он вел себя больше как объект отладки, где код просто не существует в сборке выпуска, то вы можете сделать что-то вроде этого:

[Conditional("DEBUG")]
void DebugBreak()
{
  if(System.Diagnostics.Debugger.IsAttached)
    System.Diagnostics.Debugger.Break();
}

затем добавьте к нему вызов в своем коде.

120
11

однажды я столкнулся с ситуацией, когда это не сработало

System.Diagnostics.Debugger.Break();

но это

System.Diagnostics.Debugger.Launch();
8

Если вы хотите иметь только одну строку кода вместо 4, обернуть 

#if DEBUG
       if (Debugger.IsAttached)
            Debugger.Break();
#endif

на

public static class DebugHelper
{
    [DebuggerHidden]
    [Conditional("DEBUG")]
    public static void Stop()
    {
       if (Debugger.IsAttached)
            Debugger.Break();
    }
}

и использовать

DebugHelper.Stop();

DebuggerHiddenAttribute добавляется для предотвращения остановки отладчика на внутреннем коде метода Stop и перехода в метод с помощью F11.

6

Как насчет того, чтобы просто настроить Visual Studio, чтобы всплывать с отладчиком, даже если вы его проглотите?

этого:

  • перейти к отладке - > исключения...
  • найти правильное исключение, или добавить его, если это ваш собственный
  • установите флажок "брошено" для исключения

Это остановит Visual Studio в том месте, где создается исключение, а не только если оно не обрабатывается.

вы можете увидеть больше информации здесь.

4

хороший трюк, который я нашел, - это отладчик.Break() в ctor вашего исключения.

3

в Visual Studio 2010, попав повтор на Debug.Assert диалоговое окно приведет вас к неудачному утверждению отладки, как если бы у вас была точка останова.

1