Не удалось привязать точку останова-Visual Studio 2015


Я только что обновился с Visual Studio 2013 до 2015, и теперь у меня возникли проблемы с точками останова.

Это хит или промах, где точки останова действительно будут работать, и если я установлю один во время отладки, я получу ошибку:

точка останова не удалось привязать.

любая помощь будет оценили. Я почти готов отказаться от 2015 года и вернуться.

19 125

19 ответов:

У меня была та же проблема, но другое решение. Обратите внимание, что я обновился до VS 2015 Update 1, и проблема все еще существует.

в предыдущей версии VS starting debug автоматически запускал сборку в режиме отладки. Но с VS2015 это не так.

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

вы должны вручную строить в режиме отладки, а затем начать отладку.

У меня была та же проблема.

Я решил отключить опцию "оптимизировать код" на вкладке свойства проекта.

Это может показаться тривиальным, но после большого количества головных уборов с теми же проблемами, о которых вы упомянули, я обнаружил, что моя сборка была установлена на "release" вместо "debug", когда я попытался отладить.. повторное построение решения для "отладки" исправлено, и я мог бы установить точки останова как обычные

У меня была аналогичная проблема с точками останова, которые не удалось связать, а также с некоторыми локальными переменными, не оцениваемыми в окне Locals. Что, наконец, исправлено, это включение опции" подавить JIT-оптимизацию при загрузке модуля (только управляемый) " на вкладке Параметры->отладка - >общие. Как только я установил, что он был в состоянии связать без проблем.

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

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

Я запускаю производительность на моем решении, и это добавило это в мою сеть.конфигурации

<compilation debug="true" targetFramework="4.5" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/> 

the assemblyPostProcessorType это проблема, я удалил его, и это решило мою проблему

решение состоит в том, чтобы отключить оптимизацию дизайна.

Project Properties> Build> Advanced Compile Options> Enable Optimizations

Я не менял "оптимизировать", но на основе других ответов здесь, я

  1. установите Обозреватель решений, чтобы показать все файлы для проекта
  2. удалены скрытые папки bin и debug
  3. выполнил "чистку" на проекте
  4. выполнена "перестройка" на проекте

до сих пор это исправило его для меня. Похоже, обновление до VS2015 Update 2 вызвало несколько вещей в моей системе.

сегодня я столкнулся с ошибками точки останова привязки. И я решил свою проблему, делая belows.

Если все ваши конфигурации отладки не являются правильными, вы не можете исправить проблему, делая belows.

  1. Очистить Проект
  2. если путь вывода отличается от папки bin, замените его на папку bin (это самое важное правило)
  3. восстановить

может быть, это решение кому-то поможет.

VS точки останова не могут привязываться к асинхронным методам.

У меня был установлен агент динамики приложений, который вызвал это. Удалите это, и вы хорошо идти.

У меня была та же проблема, но я не понял, что "Debug" изменился на "Release" на панели инструментов отладки(обычно прямо под меню). Поэтому я установил его на "отладку", он работал.

новая обновление для Microsoft Visual Studio 2015 Update 3 (KB3165756) Исправлена проблема точки останова для меня, где я пытаюсь проверить локальные переменные в коде C#, встроенном в файлы cshtml в ASP.NET основные приложения.

Шаг 1, исключите очевидное:

  • компиляция в режиме отладки.
  • попробуйте очистить решение перед установкой точки останова.
  • перейдите в папку отладки и удалите [ваше приложение].PDB-файл.
  • затем выполните сборку или перестроение приложения.
  • перейдите в папку отладки и подтвердите, что у вас есть новый [Ваш приложение.]PDB-файл.
  • затем попробуйте установить перерыв точка.

Шаг 2 для проектов C++:

проверьте следующие свойства проекта:

  • C++/Общая/Отладочная Информация Формат: База Данных Программы.
  • C++/Оптимизация: Отключено.
  • C++/Code generation / Runtime library: многопоточная отладка.
  • Компоновщик / Отладка / Генерация Отладочной Информации: Да.
  • Компоновщик / отладка / создание программы база данных: $(TargetDir)$(TargetName).распределительная плата.
  • Компоновщик / Файл Манифеста / Создать Манифест: Нет.
  • Компоновщик / Файл Манифеста / Разрешить Изоляцию: Нет.
  • Компоновщик / встроенный IDL / игнорировать встроенный IDL: да.
  • Сделайте Шаг 1 Еще Раз

    вы можете попробовать добавить __debugbreak(). Этот оператор должен войти в ваш исходный файл, где вы хотите сломать.

Шаг 2 для проектов C#:

  • в свойства проектов строительства/общие/оптимизировать код должен быть нетрудоспособный.
  • в настройки IDE для отладки/настройки и параметры/отладка/общие подавить Джит оптимизация при загрузке модуля (только управляемая): включено
  • Сделайте Шаг 1 Еще Раз

попробуйте открыть свое решение на других машинах. Если вы можете привязать точку останова на другой машине, это может означать, что существует проблема с вашим VS или вашей ОС.

Шаг 3, убедитесь, что ваш VS до-до-даты:

были сообщения о таких проблемах в VS2013 RTM, а также VS2015 Update 1 и Update2.

в VS перейдите в раздел Инструменты / Расширения и обновления/обновления / обновления продукта и посмотрите, какую версию вы используете. Если обновление необходимо, оно появится там.

Шаг 4, Убедитесь, что ваша ОС обновлена:

наконец, если вы используете ОС Win 10, появилась ошибка, связанная с этой проблемой, которая существовала в построить 14251. Это было решено в сборке 14257 (и выше).

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

TL / DR:
В сообщении SOAP была запись с плохими данными, из-за которой точка останова не попадала.

полный История:

У меня есть служба WCF на основе WSDL из другой команды. Не мое определение, никакого контроля над ним... Я получаю сообщения от этой другой команды через эту службу. В моем случае я получаю сообщения, могу записать сообщение в таблицу журнала сообщений в базе данных (что происходит до вызова моего метода службы), метод службы, по-видимому, называется (возможно, это не так), и сервер отвечает 202 принятым. Связь работает, за исключением того, что данные не сохраняются к базе данных во время вызова метода.

поскольку служба возвращает успешный ответ, я исключил проблемы, связанные с http и транспортом.

поэтому я запустил VS2015 для отладки службы. Сообщение, о котором идет речь, велико, но вполне в пределах того, что я ожидал бы. Я поставил точку останова в первой строке метода службы и отправил большое сообщение, но точка останова никогда не попадала. Я попробовал меньшее сообщение, которое, как я знал, работало на том же экземпляре run и точка останова была поражена просто отлично. Так что все в настройках было нормально. Я подумал, может быть, что-то было в размере сообщения.

я попробовал все, что мог найти - убедившись, что я был в конфигурации отладки, очистите и перестройте, вручную подключив отладчик к процессу w3wp (который уже был VS), используя Debugger.Break() вместо точки останова, установка нескольких проектов запуска, выгрузка моего тестового проекта, чтобы проект службы был единственным, обновление .NET, перезапуск VS2015, перезагрузка, переключение с локального IIS на IIS Express и обратно, воссоздание службы с гарантированным последним WSDL. Ничто не имело значения. Точка останова так и не была достигнута.

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

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

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

<compilation debug="true" targetFramework="4.5.2" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

to:

<compilation debug="true"/>

я помахал резиновым цыпленком над моей машиной разработки, нарисовал мелом контур звезды вокруг него, и это сработало. Прежде чем вы усмехнетесь, это не менее бессмысленно, чем другие не-решения, предлагаемые для этой ошибки. Вы просто не собираетесь делать это уходя с любой из коротких или длинных шагов в любом из решений, предлагаемых здесь. Я считаю, что отказ от Visual Studio 2015 является единственным практическим способом избежать этого.

очистить все решение, прежде чем пытаться любой из других решений. После попытки почти все остальное сказано в предыдущих ответах, и перезапуск visual studio несколько раз, просто очистка решения сделал трюк!

Я просмотрел предыдущие ответы и @Will's answear исправлена основная проблема, с которой я столкнулся, другая возможность редактирования и продолжения, но более пристальный взгляд на AssemblyInfo.cs-файл я обнаружил некоторые функции отладки, где отключено.

затем я удалил старые атрибуты отладки и добавил следующее, что я взял из другого проекта

#if DEBUG
[assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.DisableOptimizations | System.Diagnostics.DebuggableAttribute.DebuggingModes.EnableEditAndContinue | System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | System.Diagnostics.DebuggableAttribute.DebuggingModes.Default)]
#endif

но я чувствую, что это не лучший способ делать это.