Отладочная информация интерфейса C #, не связанная с источниками - PullRequest
3 голосов
/ 17 ноября 2011

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

Мы надеемся, что эта функциональность станет полезной - это функция Resharper Navigate to External Sources, поэтому мы можем легко просматривать источники проектов, на которые мы ссылаемся, из других решений. Я не понимаю, почему VS не может сделать это из коробки.

Это все работает очень хорошо для классов с реализацией. Однако для интерфейсов и классов C #, содержащих только автоматически реализованные свойства, Resharper не может просматривать источники и возвращается к программе просмотра грубых метаданных.

Я использовал srctool.exe, который поставляется с инструментами Symbol Server в MS Debugging Tools for Windows, чтобы просмотреть источники, перечисленные в файле .pdb, и ясно, что источники для этих интерфейсов и пустых (ish) классов не указано в файле pdb. Если я переключу автоматически реализуемые свойства на свойства с полями поддержки, то ссылка на источник появится в pdb.

Я предполагаю, что источники исключены, потому что нет мест, где вы могли бы установить точки останова на интерфейсах и автоматически реализованных свойствах.

Мне интересно, однако, если есть какая-то экзотическая опция компилятора или обходной путь, который мы можем использовать, чтобы заставить файл PDB включать ссылки на источник интерфейсов C #.

Спасибо, Mark

1 Ответ

1 голос
/ 16 июля 2014

В вопросе недостаточно подробностей.Отбросив бедро, я думаю, что вы решили проблемы с медленным массовым решением, преобразовав ссылки на проекты в ссылки на сборки.И использовал сборку Release этих проектов в качестве справочной.

И да, это ставит в тупик любой инструмент, который пытается найти файлы исходного кода из PDB.В сборке релиза проекта .NET используется версия PDB stripped , из которой была удалена вся информация о файле исходного кода и номере строки.Это вполне нормальная вещь для настоящих релизных сборок.Выпуск встроенного кода обычно оптимизирован.Это приводит к переупорядочению кода, который больше не соответствует логической позиции кода в исходном файле.Любая информация, которую вы получаете от источника + линия Информация о PDB, теперь имеет тенденцию переходить между вредной и бесполезной, вы начинаете искать проблему в неправильном месте.

Это, однако, не беспокойствоИнструменты IDE или во время отладки вашего приложения.В таком случае оптимизатор автоматически отключается.Фактически элемент конфигурации в VS: Инструменты + Опции, Отладка, Общие, опция «Подавить оптимизацию JIT при загрузке модуля».Включено по умолчанию.

Очевидно, что любой инструмент, использующий PDB, будет кататоничен, если у него нет возможности найти исходные файлы.Чтобы исправить это, нужно вернуться к исходному проекту, снова выбрать конфигурацию выпуска и изменить настройку: Project + Properties, вкладка Build, прокрутить вниз, кнопку Advanced.Измените комбинацию «Информация об отладке» с «pdb-only» на «full».Перестройте проект.

Должен решить вашу проблему.Также восстанавливает отладчик, вы можете снова войти в исходный код.

Не перемещайте файлы слишком много между прочим, вы можете снова поставить в тупик.По крайней мере, храните PDB с DLL в том же каталоге.Если исходный код больше не присутствует в той же директории, но вы снова проверили его в другой, то вам нужно сообщить об этом IDE.Щелкните правой кнопкой мыши решение, выберите Свойства, Отладка исходных файлов.

...