Точка останова не привязана - Visual Studio 2015

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

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

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

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

+144
30 июл. '15 в 19:59
источник поделиться
22 ответа

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

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

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

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

+206
11 дек. '15 в 10:39
источник

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

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

+78
03 нояб. '15 в 8:48
источник
другие ответы

Связанные вопросы


Похожие вопросы

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

+36
13 авг. '15 в 12:12
источник

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

+32
25 авг. '15 в 20:38
источник

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

+14
07 авг. '15 в 20:03
источник

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

+5
26 нояб. '15 в 7:59
источник

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

Project Properties> Build> Advanced Compile Options> Enable Optimizations

+5
04 апр. '16 в 13:58
источник

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

+4
09 дек. '15 в 15:30
источник

Измените режим Release на Debug, в моем случае это исправило мою проблему.

enter image description here

+2
13 дек. '18 в 9:36
источник

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

  • Установить обозреватель решений для отображения всех файлов для проекта
  • Удалены скрытые папки и папки отладки
  • Выполнено "Очистить" в проекте
  • Выполнено "Перестроить" в проекте

Пока это зафиксировало это для меня. Кажется, что обновление до версии VS2015. Обновление 2 укусило несколько вещей в моей системе.

+1
27 апр. '16 в 23:20
источник

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

+1
03 окт. '17 в 19:47
источник

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

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

  • Очистить проект
  • Если выходной путь отличается от папки bin, замените его на папку bin (это самое важное правило)
  • Перестроить

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

0
07 янв. '16 в 2:28
источник

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

0
30 мая '16 в 7:28
источник

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

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

0
18 июн. '16 в 10:17
источник

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

0
01 авг. '16 в 11:15
источник

ШАГ 1, Измените очевидное:

  • Скомпилировать в режиме отладки.
  • Попробуйте очистить решение перед настройкой точки останова.
  • Перейдите в папку "Отладка" и удалите файл [Ваше приложение].pdb.
  • Затем выполните сборку или перестройте приложение.
  • Перейдите в папку Debug и убедитесь, что у вас есть новый [ application].pdb.
  • Затем попробуйте установить точку останова.

ШАГ 2 Для проектов на С++:

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

  • С++/Общий/Отладочный формат информации: База данных программ.
  • С++/Оптимизация: отключено.
  • С++/Генерация кода/Библиотека времени выполнения: Многопоточная отладка.
  • Linker/Debugging/Generate Debug Info: Да.
  • Linker/Debugging/Создать базу данных программы: $ (TargetDir) $(Имя_целевого_объект).pdb.
  • Файл компоновщика/манифеста/Создать манифест: Нет.
  • Файл компоновщика/Манифест/Разрешить изоляцию: Нет.
  • Linker/Embedded IDL/Игнорировать встроенный IDL: Да.
  • Повторите шаг 1

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

ШАГ 2 Для проектов С#:

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

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

ШАГ 3, убедитесь, что ваш VS обновлен:

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

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

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

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

0
25 июл. '17 в 8:08
источник

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

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

Полная история:

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

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

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

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

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

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

0
11 авг. '17 в 16:58
источник

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

<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"/>
0
26 сент. '17 в 16:05
источник

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

0
28 авг. '18 в 10:38
источник

Я перепробовал все предложенное здесь. В конце концов, я установил "Определенную страницу" в "Свойствах проекта" → "Интернет" для моего локального начального URL, страницы и параметра запроса. Сделал чистку и перестроил в режиме отладки и он достиг моей точки останова.

0
23 окт. '18 в 15:41
источник

Хотя это гораздо более поздняя сборка (VS2017), у меня была эта проблема с проектами на С#. Пробовал чистить, перестраивать, перезагружать визуальную студию и т.д.

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

0
26 окт. '18 в 19:45
источник

Я просмотрел предыдущие ответы и @Will 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

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

-1
01 авг. '16 в 9:40
источник

Посмотрите другие вопросы по меткам или Задайте вопрос