Как отлаживать (входить) в библиотеку классов, указанную в моем проекте, и иметь .pdb и исходный код?

При отладке открытого решения/проекта в Visual Studio (2015) я хотел бы отладить (шаг за шагом) вызов метода, который находится в одной из ссылочных ассемблеров. У сборника есть .pdb(скопированный локальный) и исходный код. Эта сборка фактически также является моим проектом класса lib, но не в текущем решении, а в другом решении.

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

Что я сделал/пытался до сих пор:

Я снял флажок Только мой код
Я проверил, что .pdb для другой сборки скопирован в мою текущую выходную папку проекта.
Пытался установить точку останова непосредственно перед вызовом, затем входите. Нет успеха, звонок был просто перешагнут.
Сборка, которую я хотел бы отлаживать, поступает как пакет NuGet (а не просто просматриваемая ссылка). Тем не менее, это мой проект класса lib, поставляется с .pdb, а исходный код доступен на моем локальном диске.
Посмотрел на Window- > Debug- > Modules: Symbol status: Загружены символы. Код пользователя: N/A. Местоположение файла Symbol - это файлы Temp Asp. (Это приложение ASP.NET MVC)
Поскольку он поступает из пакета NuGet, его сборка является сборкой Release, но в настоящее время не оптимизирована и имеет обновленную версию .pdb

Как я помню, эта функция отладки иногда удивительно работала автоматически, но теперь этого не происходит.

Что мне не хватает?

Ответ 1

Наиболее распространенными причинами такого опыта являются:

включен "только мой код" (tools- > options- > debugging)
несоответствующие PDB
несогласованные источники

Вы исключили 1, чтобы проверить другие 2:

Откройте Debug- > Windows- > Modules и найдите сборку, с которой вы столкнулись. Убедитесь, что он загружен из ожидаемого местоположения, есть версия, которую вы ожидаете, проверьте, загружены ли PDB. Возможно, вам придется попробовать загрузить/перезагрузить PDB, чтобы узнать, удовлетворен ли VS PDB, который он размещает.

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

Обратите внимание, что если вы создадите библиотеку для RELEASE, она будет оптимизирована, и для некоторой функции вы не сможете отлаживать их вообще из-за включения в JIT-времени или оптимизации времени компиляции мертвого кода (например, ветвей if (false)), Для обеспечения наилучшего опыта обязательно используйте сборку DEBUG с соответствующим PDB и убедитесь, что вы рано устанавливаете "подавлять оптимизацию при загрузке" в параметрах отладчика.

Ответ 2

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

Желаемый .dll был установлен в GAC (глобальный кэш сборок).

Я удалил его, и я смог снова войти в код dll.

Ответ 3

Мне нужно сделать это много раз, и простой подход, которым я придерживался, - это:

1) Убедитесь, что библиотека классов, которую вы хотите отлаживать, строит с помощью последнего исходного кода

2) Скопируйте файлы dll и .pdb из каталога bin/debug библиотеки классов в каталог вывода приложения

3) Запустите приложение с помощью отладчика (если это веб-приложение, прямое обращение к нему из браузера и если оно является консолью /winform/wpf - просто нажмите соответствующий exe)

4) Прикрепите визуальную студию открытой с исходным кодом библиотеки классов с этим конкретным процессом exe (или рабочим процессом WP3 IIS для веб-приложения) и все настроено на работу.