2014-12-29 5 views
13

Я знаком с DebuggerHiddenAttribute и DebuggerStepThroughAttribute. Сегодня я заметил DebuggerStepperBoundaryAttribute, и если я правильно понял, если вы попытаетесь использовать F10 над свойством (или методом или любым другим), имеющим этот атрибут, он превратится в F5.Какой пример использования DebuggerStepperBoundaryAttribute?

Использовать атрибут DebuggerStepperBoundaryAttribute для перехода от шага через код к запущенному коду. Например, в Visual Studio 2005 , столкнувшись с атрибутом DebuggerStepperBoundaryAttribute при выполнении кода с использованием клавиши F10 (или команды «Шаг за шагом») имеет тот же эффект, что и , нажав клавишу F5 или используя команду «Начать отладки».

Я не могу придумать пример, что это было бы полезно/полезно. Поэтому либо мое понимание неверно, либо я не могу придумать хороший пример того, как это было бы полезно. Каким будет использование DebuggerStepperBoundaryAttribute, которое было бы полезно/полезно?

+0

я могу себе представить, что может быть полезно, если у вас есть планировщик задач или нечто подобное, и вы достигли конца вашей задачи. Вместо того, чтобы возвращаться в ваш код фреймворка, он просто позволит задаче закончить и шипнуть в фоновом режиме. Но лично я не использовал его. – jessehouwing

+0

Кажется очень запутанным для разработчика, который отлаживает. – usr

+0

@usr вот что я подумал. – Daryl

ответ

1

Вот простая программа испытаний (Enable Just My Code, и поставить точку останова на линии тест 1,2,3, & 4) говорится ниже:

class Program 
{ 
    static void Main(string[] args) 
    { 
     TestDebuggerStepperBoundary();      // Test 1 
     Test();            // Test 2 
     TestDebuggerNonUserCode(TestDebuggerStepperBoundary); // Test 3 
     TestDebuggerNonUserCode(Test);      // Test 4 
    } 

    [DebuggerNonUserCode] 
    private static void TestDebuggerNonUserCode(Action action) { action(); } 

    [DebuggerStepperBoundary] 
    private static void TestDebuggerStepperBoundary() { SomethingHorrible(); } 

    [DebuggerNonUserCode] 
    private static void Test() { SomethingHorrible(); } 

    private static void SomethingHorrible() 
    { 
     var foo = "bar"; 
    } 
} 

После reviewing the definition for DebuggerStepperBoundaryAttribute, я не» т думаю, что определение вполне прав:

атрибут DebuggerStepperBoundaryAttribute используется как побег от эффекта DebuggerNonUserCodeAttribute.

Вы можете использовать DebuggerStepperBoundaryAttribute, не будучи в контексте DebuggerNonUserCodeAttribute. F11 на Тест 1 немедленно попадает в следующую точку останова на Тест 2, не находясь в «эффекте DebuggerNonUserCodeAttribute». Я думаю, что это должно действительно читать: «Атрибут DebuggerStepperBoundaryAttribute используется как побег от эффекта Step Into или Step Over во время отладки». Остальная часть Defintion имеет смысл:

При выполнении в пределах границ DebuggerNonUserCodeAttribute, дизайнер предоставляемый код выполняется как шаг-через до следующего пользователь ввел код встречается. Когда переключатели контекста выполняются в потоке , следующий входящий в комплект код модуля кода, входящий в систему, может не связываться с кодом, который был в процессе отладки. Чтобы избежать этого отладки , используйте DebuggerStepperBoundaryAttribute до , чтобы избежать перехода от кода к запущенному коду. Например, в Visual Studio 2005, столкнувшись с атрибутом DebuggerStepperBoundaryAttribute при выполнении кода с использованием клавиши F10 (или команды «Шаг за шагом») имеет тот же эффект, что и нажатие клавиши F5 или с помощью команды «Отладка» Start .

Так, чтобы ответить на мой вопрос, есть ли какой-то другой код, который вы должны были позвонить, что вы не может/не хочет, чтобы добавить DebuggerStepThrough, DebuggerNonUserCode или DebuggerHidden, но если отладчик введен метод будет более чем переходить от кода к запуску кода, а затем использовать DebuggerStepperBoundaryAttribute.(В моей примерной программе F11 на Test 2 вы сразу попадаете в SomethingHorrible, что потенциально хуже, чем прямо на выполнение (F5)). В нее добавлено явно добавленное контекстное переключение потоков, и за пределами этого я не знаю ни одного что это было бы полезно.

+0

отметьте свой ответ как ответ ... – pashute

0

[DebuggerStepperBoundary] буквально означает, что существует граница отладки. отладчик, как правило, перепрыгивает через это (независимо от того, насколько сильно вы любите StepInto), НО ДОЛЖНЫ ПОЗВОЛЯТЬ, чтобы поставить точку останова, и в этом случае она сломается. Но обычным поведением будет перепрыгнуть через эту функцию (пропустить).

[DebuggerStepThrough] это означает, что вы НИКОГДА не заходите сюда. если вы попытаетесь установить точку останова, она будет отключена, если выбран «Только мой код». обычно используется для свойств и LINQ и такого

Когда вы используете это:

У меня есть приложение, которое использует user32.dll для отправки нажатия клавиш в определенное приложение. Я поставил DebuggerStepThrough на 90% этих функций, так как они не влияют, если они разбиты. Им нужно бежать в целом.

Надеется, что это отвечает на ваш вопрос

+0

Я предполагаю, что вы имели в виду «НО« ЭТО », а не IN. Итак, единственная разница между StepThrough и StepperBoundary, что вы не можете установить точку останова в StepThrough, если не выбрано «Только мой код»? – Daryl

+0

Да, его брат [DebuggerNonUserCode] используется сгенерированным кодом, а StepThrough - это не сгенерированный код прямого родства. –

+0

DebuggerstepThough я использую для вещей, я знаю, что другой разработчик будет падать. как мой пример sendkeys или простые свойства, и boudary, когда я просто не хочу видеть его во время отладки –

Смежные вопросы