it-swarm.com.ru

Точки останова Visual Studio ломаются в неправильном исходном файле (или нескольких файлах одновременно), если несколько файлов имеют одно и то же имя

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

Пример

Я установил точку останова в IdeasController.cs в нашем веб-API:

Breakpoint set in code

Другой файл с именем IdeasController.cs существует в нашем отдельном веб-проекте MVC 4. На приведенном ниже снимке экрана отладчик показывает исходный код Api->IdeasController, но выделение строки соответствует структуре кода Web->IdeasController. Точка останова дублируется, и один из них находится в середине блока комментариев.

Debugger highlight does not match code structure

Окно Точка останова показывает точку останова в обоих файлах одновременно:

Breakpoint spans both files

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

Что я пробовал

Я бродил по интернету. Похоже, что проблема такого рода возникает, когда имеется несоответствие между файлом отладки (*.pdb), исходным файлом и скомпилированным кодом. Есть много возможных причин: дубликаты имен файлов (которые могут сбить с толку отладчик[5]), устаревшие файлы сборки проекта, неверный кеш решения или неправильная конфигурация сборки.

Вот решения, которые я нашел и попробовал:

  • Проверил мою конфигурацию сборки .
    1. Убедитесь, что проект не построен в режиме релиза.
    2. Убедился, что у нас не включена оптимизация кода .
    3. Убедитесь, что модуль отладки проекта был загружен правильно. (Начал отлаживать проект и проверил Debug> Windows> Modules. Обе сборки перечислены, не оптимизированы и имеют статус символа «Символы загружены».)
  • Сброс метаданных отладки и кеша Visual Studio .
    1. Закрыл Visual Studio и удалил файл кэша решения (*.suo).[1]
    2. Удалил выходные данные сборки каждого проекта (папки bin и obj). (Для дальнейшего использования: откройте папку решения в проводнике Windows и введите ее в поле поиска: «type:folder AND (name:=bin OR name:=obj)».
    3. Удалил папку кеша сборки (C:\Documents and Settings\<user>\Local Settings\Application Data\dl3).[2][3]

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

Где я сейчас нахожусь

Страница 14 из моего последнего поиска Google. Предложения будут высоко оценены. :)

42
Pathoschild

Я так рад, что нашел этот пост, думал, что я единственный, и схожу с ума! У меня такая же проблема в VS2012 с VB.Net, и я попробовал все, что упоминалось в OP.

Уникальное именование файлов, похоже, единственное исправление, которое я нашел. Отключение всех точек останова до тех пор, пока приложение не загрузится, а затем повторное включение нужных вам точек останова работает большую часть времени. Точки останова в лямбда-функциях могут по-прежнему вызывать проблемы.

6
Miiir

У меня была точно такая же проблема. Для меня это решило удаление файлов .suo, принадлежащих решению, которое содержало затронутый проект/исходный файл.

Я также удалил свой локальный кэш символов, но не думаю, что это как-то связано с этим.

(Мое решение содержит несколько проектов, это затронуло один файл (DataAdapter.cs) в одном проекте (VisualStudio поместил мои точки останова в pdb, принадлежащий System.Data.DataAdapter). Я открыл файл .csproj напрямую и смог правильно установить точку останова.)

4
Steffen Winkler

Если нет лучших альтернатив, вы можете поместить точку останова в коде:

System.Diagnostics.Debugger.Break();

Только не забудьте потом удалить его ...

4
bdrajer

У меня была такая же проблема сегодня. Я смог проследить это до того факта, что я забыл установить целевую платформу на x86 во время отладки. К сожалению, другие (x64/Any CPU) могут быть проблематичными при отладке. По крайней мере, VS 2008 не любит их. Я думаю, это еще одна причина, чтобы держаться подальше.

Некоторые предположения ... Я думаю, что отладчик (во время работы 64-битного приложения) каким-то образом "крадет" точки останова из файла в некоторых случаях. Для меня это было потому, что сначала была загружена другая сборка с тем же именем файла. Мне удалось избежать этой проблемы, даже в 64-битном режиме, если я сначала вручную загрузил сборку с моими точками останова: Assembly.Load ("MyAssemblyWithBreakpoints");

Надеюсь, что это (мой первый вклад в stackoverflow) поможет.

3
David Beavon

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

1
Jan Lecko

Я столкнулся с этой проблемой в Visual Studio 2015.

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

Я нашел полезную ссылку на [MSDN, которая показывает, как удалить предыдущие связанные исходные файлы в студии по этой ссылке] [1].

Резюме:

  1. В обозревателе решений щелкните правой кнопкой мыши имя решения (например, Solution pp TestApplication ’) и выберите« Свойства ». Откроется диалоговое окно« Свойства страницы решения ».
  2. В разделе «Общие свойства» выберите «Отладка исходных файлов».
  3. В поле Поиск этих путей для файлов исходного кода (Visual Studio .NET 2003)/Каталоги, содержащие исходный код (Visual Studio 2005), добавьте, удалите и/или измените порядок каталогов по желанию.
  4. Нажмите кнопку ОК
1
Patrick

Хотя переименование одного из файлов будет работать, я обнаружил, что самое простое решение - временно отключить автоматическую загрузку символов для «другой» сборки.

  1. Запустите отладчик и продолжайте, пока не достигнете ошибочной точки останова.
  2. Найти, где отладчик фактически установить точку останова, используя стек вызовов window:
    1. Щелкните правой кнопкой мыши строку с желтой стрелкой и включите Показать имена модулей . (Ряд также должен иметь красный символ точки останова.)
    2. Имя сборки теперь отображается в этом ряду.
  3. Найдите эту сборку в окне Модули ( Отладка> Windows> Модули ).
  4. Щелкните правой кнопкой мыши по сборке и отключите Всегда загружать автоматически .
  5. Остановите отладчик. 
  6. Начните отладку снова.

Делая это, вы не позволяете отладчику Visual Studio отображать точку останова на неправильную сборку. Затем он сначала загрузит символы из другой [предположительно] правильной сборки, поэтому отобразит точку останова в правильную сборку.

Почему это происходит?

Кажется, это происходит, когда два разных файла символов (файлы PDB) - для двух разных сборок - оба ссылаются на исходный файл с одинаковым именем. Хотя исходные файлы совершенно разные, отладчик Visual Studio, похоже, запутался.

Например, представьте, что есть два разных файла с именем IdeasController.cs. Первый компилируется в сборку Api.dll, а второй компилируется в сборку Web.dll

Когда отладчик загружает символы, он сначала загружает Api.pdb или Web.pdb. Допустим, сначала загружается Api.pdb. Тогда даже если вы установите точку останова в Web\IdeasController.cs, она найдет совпадение для IdeasController.cs в Api.pdb. Затем он отображает код из Web\IdeasController.cs в Api.dll. Конечно, это не будет правильно отображаться, и поэтому при отладке вы увидите всевозможные странные проблемы.

1
Malarial

Удалите все файлы .pdb проекта, где точка останова ошибается. Это решит проблему.

0
Ramaraj K

Мне случилось (в VS 2008 ) иметь две дочерние точки останова с одним и тем же адресом памяти и одним и тем же связанным файлом . Эти точки останова были созданы в определенное время в течение запуск процесса.

Я заметил, что дублировал .dll файлы в папках моего проекта, и решил удалить дублированный .dll, сохранив при этом только один .dll на имя в структуре папок отладки. (Как пример в моем случае, у меня были /bin/Example.dll и /bin/Plug-in/Example.dll оба в моей структуре папок отладки).

0
Simone

Для меня (VS2017) сработало отключение эта опция в Tools --> Options... --> Debugging --> General: " Требовать, чтобы исходные файлы точно соответствовали исходной версии ", которая включена по умолчанию, но у меня она была включена.

Но этого было недостаточно, мне также пришлось вручную удалять папки obj и bin для всех проектов в решении. 

0
batintherain

Вы также можете попытаться очистить и перестроить (не строить) все проекты.

0
Diogo