Проблема
Если вы используете какую-либо стороннюю библиотеку, вы, вероятно, знаете, что испытываете боль, если что-то работает не так, как вы ожидали ...
Представьте себе наиболее распространенный сценарий - у вас есть веб-сайт, использующий стороннюю библиотеку. В основном это DLL, которая предоставляет вам некоторые точки интеграции. Вы пытаетесь интегрироваться с ним, это не работает, но вы не понимаете, почему. Если бы это был ваш код, вы могли бы его отладить, но что, если у вас нет кода? Обычно в моем случае это означало обратное проектирование и декомпиляцию с использованием таких инструментов, как ILSpy, и замену кода OOTB, чтобы иметь возможность отлаживать его шаг за шагом…. Но действительно ли это единственный способ сделать это?
Решение
К счастью, есть способ получше.
Шаг 1. Создайте символы с помощью инструмента декомпиляции dotPeek.
Когда библиотека создается в Visual Studio, она также поставляется с файлами * .PDB, которые содержат всю информацию о том, как ее отлаживать. К сожалению, если вы используете сторонние библиотеки DLL, вам, скорее всего, не будут предоставлены файлы символов. Разработчики не ждут, что вы отладите их код! (наверное потому, что думают, что багов там нет?)
Offtop note: файлы PDB используются не только для отладки, но и для отображения подробной информации об источнике исключения в трассировке стека (например, номера строк кода).
К счастью, есть отличные инструменты, такие как JetBrains dotPeek, которые позволяют не только декомпилировать сторонние библиотеки .NET (что также удобно), но и генерировать эти файлы .PDB.
Https://www.jetbrains.com/decompiler/
Итак, теперь мы сгенерировали файлы базы данных отладки, которые мы можем использовать… но это еще не все.
Мы также можем разместить наш собственный сервер символов с помощью dotPeek. Позже я покажу, что он делает и какую мощность мы можем получить от этого инструмента отладки!
Примечание. По соображениям производительности я бы посоветовал размещать информацию о символах только для сборок в проводнике сборок.
Шаг 2. Настройте Visual Studio с новым источником символов
Теперь, когда наш сервер символов запущен, нам нужно добавить его в Visual Studio. Тогда Visual Studio будет знать, где искать символы, когда мы отлаживаем процесс.
Нам также необходимо отключить «Только мой код», чтобы включить отладку сторонних библиотек. Также нам нужно включить «Поддержка исходного сервера».
Нам также необходимо добавить новый источник символа на вкладке «Символы».
Примечание. По соображениям производительности я бы посоветовал указать каталог кэша символов, а также явно указать модули, которые должны быть загружены с сервера символов. Это ускорит загрузку символов с сервера символов.
Шаг 3. Загрузка символов
Итак, теперь все настроено, и мы можем отлаживать сторонние библиотеки DLL. Но у нас нет доступа к их исходному коду - как мы можем их отладить?
У нас есть несколько вариантов в зависимости от того, есть у вас Resharper или нет. Но сначала приступим к отладке.
Для примера я взял код, который интегрирован в Sitecore (.NET CMS).
Как видите, этот класс унаследован от класса OpenExperienceEditor, который является сторонней библиотекой Sitecore - Sitecore.ExperienceEditor.dll.
Я добавил Sitecore.ExperienceEditor.dll в dotPeek, чтобы декомпилировать исходный код. Это также будет означать, что символы будут доступны на сервере символов.
Теперь приступим к отладке!
Я присоединяюсь к w3wp.exe, который представляет собой процесс IIS, на котором размещается мой веб-сайт.
Теперь перейдем в Debug - ›Windows -› Modules, чтобы перечислить модули, которые мы используем в нашем решении.
Чтобы иметь возможность отлаживать модуль, нам нужно загрузить символы. Это укажет Visual Studio пройти через источники символов и найти символы библиотеки.
Примечание. Если символы были загружены успешно, мы увидим, что «Статус символа» изменился на «Символы загружены»
Шаг 4. Где начинается самое интересное
Хорошо ... Итак, подведем итоги. Сервер символов запущен. Visual Studio знает, где его найти, и мы успешно загрузили символы, необходимые для отладки стороннего кода.
Теперь нам нужно добавить точку останова.
Вариант 1 - Без Resharper.
Откройте Debug - ›Windows -› Breakpoints и создайте новую «Function Breakpoint»
Нам нужно будет указать полный путь, включая пространство имен, имя класса и имя функции в диалоговом окне.
Теперь каждый раз, когда вызывается эта функция, мы достигаем точки останова!
Вариант 2 - с Resharper
Это легко. Настройте Resharper для перехода к источнику вместо объявления.
Теперь вы можете просто перейти к декомпилированному коду класса и, как обычно, поставить точку останова.
Удачной отладки!
