Ошибка привязки точки останова-Visual Studio 2015

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

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

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

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

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

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

Я запускаю производительность в своем решении, и это добавило это в мою сеть.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"/> 

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

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

Project Properties> Build> Advanced Compile Options> Enable Optimizations

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

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

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

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

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

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

возможно, это решение поможет кому-то.

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

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

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

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

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

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

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

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

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

• Повторите Шаг 1

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

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

• в свойства проектов Build/General / Optimize код должен быть нетрудоспособный.
• в настройках IDE Debug / Options и Settings/Debugging / General подавить JIT оптимизация загрузки модуля (только управляемая): включено
• Повторите Шаг 1

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

Шаг 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"/>

в:

<compilation debug="true"/>

очистить все решение перед попыткой любого из других решений. Попробовав почти все, что говорилось в предыдущих ответах, и перезапустив 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

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