Не удалось привязать точку останова-Visual Studio 2015
Я только что обновился с Visual Studio 2013 до 2015, и теперь у меня возникли проблемы с точками останова.
Это хит или промах, где точки останова действительно будут работать, и если я установлю один во время отладки, я получу ошибку:
точка останова не удалось привязать.
любая помощь будет оценили. Я почти готов отказаться от 2015 года и вернуться.
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
Я не менял "оптимизировать", но на основе других ответов здесь, я
- установите Обозреватель решений, чтобы показать все файлы для проекта
- удалены скрытые папки bin и debug
- выполнил "чистку" на проекте
- выполнена "перестройка" на проекте
до сих пор это исправило его для меня. Похоже, обновление до VS2015 Update 2 вызвало несколько вещей в моей системе.
сегодня я столкнулся с ошибками точки останова привязки. И я решил свою проблему, делая belows.
Если все ваши конфигурации отладки не являются правильными, вы не можете исправить проблему, делая belows.
- Очистить Проект
- если путь вывода отличается от папки bin, замените его на папку bin (это самое важное правило)
- восстановить
может быть, это решение кому-то поможет.
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
но я чувствую, что это не лучший способ делать это.