В командном проекте, над которым я работаю, установка точки останова в файле (скажем IdeasController.cs) приведет к неустойчивому отладчику, если в решении будет другой файл с тем же именем. Я воспроизвел проблему на нескольких рабочих станциях разработчиков.
Я установил точку останова в IdeasController.cs в нашем веб-API:
В нашем отдельном веб-проекте MVC 4 существует еще один файл с именем IdeasController.cs. На скриншоте ниже отладчик показывает исходный код Api->IdeasController, но выделение строки соответствует структуре кода Web->IdeasController. Точка останова дублируется, причем одна из них находится в середине блока комментариев.
В окне Breakpoint отображается точка останова в обоих файлах одновременно:
На некоторых рабочих станциях отладчик выполняет правильные строки (независимо от выделения строки); на других он бодро проходит через нерелевантные строки (включая комментарии и пробелы). Я предполагаю, что это зависит от того, какой исходный файл он отображает.
Я трал Интернет. Такая проблема возникает, когда существует несоответствие между отладочным файлом (*.pdb), исходным файлом и скомпилированным кодом. Существует много возможных причин: дублировать имена файлов (которые могут смутить отладчик [5]), устаревший проект создавать файлы, недействительный кэш решений или некорректную конфигурацию сборки.
Это решения, которые я нашел и попробовал:
Debug > Windows > Modules. Обе сборки перечислены, не оптимизированы и имеют статус символа "Символы загружены".)*.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. Предложения будут высоко оценены.:)
Я так рад, что нашел этот пост, подумал, что я единственный и сошел с ума! У меня такая же проблема в VS2012 с VB.Net, и я попробовал все, о чем упомянул OP.
Уникальное имя файлов, похоже, является единственным исправлением 100%, которое я нашел. Отключение всех контрольных точек до тех пор, пока приложение не загрузится, а затем снова включите точки останова, которые вам нужны, большую часть времени. Точки останова в лямбда-функциях могут по-прежнему вызывать проблемы.
Если нет лучших альтернатив, вы можете поместить контрольную точку в код:
System.Diagnostics.Debugger.Break();
Просто не забудьте удалить его потом...
У меня была точно такая же проблема. Для меня это решило удалить файлы .suo, принадлежащие решению, содержащему затронутый проект/исходный файл.
Я также удалил свой локальный символ, но я не думаю, что это имело к этому отношение.
(Мое решение содержит несколько проектов, один файл (DataAdapter.cs) в одном проекте был затронут этим (VisualStudio поместил мои точки останова в pdb, принадлежащие System.Data.DataAdapter). Я открыл файл .csproj напрямую и был способный правильно установить точку останова.)
У меня была такая же проблема сегодня. Я смог проследить его до того, что я забыл установить платформу на x86 во время отладки. К сожалению, другие (x64/Any CPU) могут быть проблематичными во время отладки. По крайней мере VS 2008 им не нравится. Думаю, это еще одна причина, чтобы держаться подальше.
Некоторые предположения... Я думаю, что отладчик (при работе с 64-битным приложением) каким-то образом "крадет" точки останова в файле в определенных случаях. Для меня это было потому, что сначала была загружена другая сборка, у которой было такое же имя файла. Мне удалось избежать проблемы даже в режиме 64 бит, если я сначала вручную загрузил сборку с моими точками останова: Assembly.Load( "MyAssemblyWithBreakpoints" );
Надеюсь, что это (мой первый вклад в stackoverflow) помогает.
Я только что столкнулся с этой проблемой в 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, он снова работал как шарм.
Я только что скопировал и удалил файл, а затем добавил обратно в проект, который решил проблему. Я просто хочу, чтобы я сделал это, прежде чем переходить в список, упомянутый выше:)
Я столкнулся с этой проблемой в Visual Studio 2015.
У меня была подпапка с DLL, которую я хотел сохранить как Version1. Кажется, что даже после удаления ссылки на эту DLL, а затем добавив ссылку на другую студию проекта, вытащил существующую ссылку и перешел в неправильный исходный файл. Я удалил эту DLL в подпапку, а затем Studio получил правильный источник.
Я нашел полезную ссылку в [MSDN, которая показывает, как очистить предыдущие связанные исходные файлы в студии по этой ссылке] [1].
Резюме:
Хотя переименование одного из файлов будет работать, я обнаружил, что самым простым решением является временное отключение автоматической загрузки символов для "другой" сборки.
Делая это, вы запрещаете отладчику 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. Разумеется, это не будет правильно отображаться, поэтому во время отладки вы видите всевозможные нечетные проблемы.
Вы также можете попробовать очистить и перестроить (не создавать) все проекты.
Что работало для меня (VS2017), было отключить эту опцию в Tools --> Options... --> Debugging --> General: " Требовать, чтобы исходные файлы были в точности совпадают с исходной версией", которая включена по умолчанию но я включил его.
Этого было недостаточно, но мне также пришлось вручную удалить папки obj и bin для всех проектов в решении.
Удалите все файлы .pdb проекта, где точка останова ошибается. Это решит проблему.
Мне случилось (в VS 2008) иметь две дочерние точки останова с одним и тем же адресом памяти и одним и тем же связанным файлом. Эти точки прерывания были созданы в определенное время во время выполнения процесса.
Я заметил, что я дублировал файлы .dll в папках моего проекта, и решил удалить дублированные .dll, сохранив при этом только одну .dll на имя в структуре папок отладки. (В качестве примера в моем случае у меня были /bin/Example.dll и /bin/Plug-in/Example.dll оба в моей структуре папок отладки).
У меня была очень похожая проблема. В моем случае проблема заключалась в другой целевой среде .net в одном из проектов, в результате чего VS2017 неправильно загружал исходный файл (с тем же именем) другого проекта, а не тот, который был активирован с помощью
ObjectHandle handle = Activator.CreateInstance
Изменение целевой структуры проекта было одинаковым во всех проектах.