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

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

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

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

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

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

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

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

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

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

Решил, отключив опцию «Оптимизировать код» в свойствах проекта на вкладке «Сборка».

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

У меня была похожая проблема с точками останова, которые не могут быть привязаны, а также с некоторыми локальными переменными, которые не оценивались в окне Locals. В конце концов исправлено было включение опции «Подавить оптимизацию JIT при загрузке модуля (только для управляемого)» на вкладке «Параметры» -> «Отладка» -> «Общие». Однажды я установил, что его можно было связывать без проблем.

У меня была эта проблема. Я запустил сеанс профилирования производительности, который изменил Web.configфайл с настройками для монитора производительности:

<appSettings>
   <add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrLocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Team Tools\Performance Tools\vsinstr.exe"/>
</appSettings>


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


<runtime>
   <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
         <assemblyIdentity name="Microsoft.VisualStudio.Enterprise.AspNetHelper" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
         <codeBase version="16.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/Microsoft.VisualStudio.Enterprise.AspNetHelper.DLL"/>
      </dependentAssembly>
      <dependentAssembly>
         <assemblyIdentity name="VsWebSite.Interop" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
         <codeBase version="8.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/VsWebSite.Interop.DLL"/>
      </dependentAssembly>
   </assemblyBinding>
</runtime>

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

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

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

Project Properties> Build> Advanced Compile Options> Enable Optimizations

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

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

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

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

1. Установите в обозревателе решений значение Показать все файлы для проекта.
2. Удалил скрытые папки bin и debug
3. Выполнил «Чистый» на проекте
4. Выполнено «Перестройка» по проекту

Пока это исправило это для меня. Похоже, что обновление до VS2015 Обновление 2 потерпело неудачу в моей системе.

Я знаю, что это старый пост, но в случае, если все остальные трюки, описанные выше, не работают, убедитесь, что изображение, которое вы пытаетесь отладить, актуально. По какой-то причине после публикации и переноса проекта .NET Core на мой Raspberry Pi 'unzip' на RPi не копировал и не перезаписывал некоторые DLL в рабочем каталоге. Когда я подключил отладчик, думая, что все в порядке, некоторые контрольные точки были сбиты, другие - нет, а некоторые давали мне ошибку «не могу связать». Как только я решил проблему с распаковкой, все мои контрольные точки и символы вернулись. Надеюсь, это поможет.

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

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

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

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

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

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

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

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

ШАГ 1, исключить очевидное:

• Компилировать в режиме отладки.
• Попробуйте очистить раствор перед установкой точки останова.
• Перейдите в папку «Debug» и удалите файл [Your application] .pdb.
• Затем выполните Build или Rebuild your application.
• Перейдите в папку «Debug» и подтвердите, что у вас есть новый файл [Your application] .pdb.
• Затем попробуйте установить точку останова.

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

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

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

• Повторить шаг 1

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

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

• В проектах свойства Build / General / Optimize code должны быть отключены.
• В настройках IDE Отладка / Параметры и Настройки / Отладка / Общие Подавить оптимизацию JIT при загрузке модуля (только управляемая): Включено
• Повторить шаг 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 для отладки сервиса. Сообщение, о котором идет речь, большое, но в пределах того, что я ожидал. Я поместил точку останова в первую строку метода службы и отправил большое сообщение, но точка останова не достигла цели. Я попробовал меньшее сообщение, которое, как я знал, работало на том же самом экземпляре запуска, и точка останова была достигнута очень хорошо. Так что все в конфигурации казалось нормально. Я подумал, может быть, что-то было в размере сообщения.

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

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

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

Мне пришлось изменить файл 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"/>

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

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

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

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

В моем случае после использования был создан новый файл web.config Profiler. Восстановление файла web.config до предыдущей версии решило эту проблему. Это было веб-приложение VS2015 C #.

В случае, если вы публикуете проверку веб-приложения, для Configurationкоторой задано значение Debug(по умолчанию в конфигурации отладки устанавливается так, что код не оптимизируется и таблица символов полностью создается).

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

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