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

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

Пример

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

Breakpoint set in code

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

Debugger highlight does not match code structure

В окне Breakpoint отображается точка останова в обоих файлах одновременно:

Breakpoint spans both files

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

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

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

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

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

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

Где я сейчас

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

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

System.Diagnostics.Debugger.Break();

Просто не забудьте удалить его потом...

Ответ 3

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

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

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

Ответ 4

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

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

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

Ответ 5

Я только что столкнулся с этой проблемой в Visual Studio 2017 (версия 15.9.7), когда точки останова были пропущены, а отладчик просто "перепрыгнул" через операторы возврата и т.д.

Через некоторое время я заметил, что недавно добавил в проект файл .runsettings - и оказалось, что в моем случае настройка сборщика данных CodeCoverage вызывает эту проблему. Как только я удалил этот раздел:

<DataCollector friendlyName="Code Coverage" uri="datacollector://Microsoft/CodeCoverage/2.0" assemblyQualifiedName="Microsoft.VisualStudio.Coverage.DynamicCoverageDataCollector, Microsoft.VisualStudio.TraceCollector, Version=11.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"> ... </DataCollector>

из файла .runsettings, он снова работал как шарм.

Ответ 6

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

Ответ 7

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

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

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

Резюме:

  • В обозревателе решений щелкните правой кнопкой мыши по имени решения (например: Solution TestApplication) и выберите "Свойства". Появится диалоговое окно "Страницы свойств решения".
  • В разделе "Общие свойства" выберите "Отладочные исходные файлы"
  • В поисках этих путей для файлов исходного кода (Visual Studio.NET 2003)/Каталогов, содержащих исходный код (Visual Studio 2005), добавьте, удалите и/или измените порядок каталогов по желанию.
  • Нажмите кнопку OK

Ответ 8

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

  • Запустите отладчик и продолжайте, пока не нажмете ошибочную точку останова.
  • Найдите, где отладчик фактически установил точку останова, используя окно "Стек вызовов":
    • Щелкните правой кнопкой мыши строку с желтой стрелкой и включите "Показать имена модулей". (Строка также должна иметь красный символ останова на нем.)
    • Теперь имя сборки отображается в этой строке.
  • Найдите эту сборку в окне "Модули" ( "Отладка" > "Windows" > "Модули" ).
  • Щелкните правой кнопкой мыши на сборке и отключите функцию "Всегда загружать автоматически".
  • Остановить отладчик.
  • Запустите отладку еще раз.

Делая это, вы запрещаете отладчику 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. Разумеется, это не будет правильно отображаться, поэтому во время отладки вы видите всевозможные нечетные проблемы.

Ответ 9

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

Ответ 10

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

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

Ответ 11

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

Ответ 12

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

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

Ответ 13

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

ObjectHandle handle = Activator.CreateInstance

Изменение целевой структуры проекта было одинаковым во всех проектах.