Я только что обновил Visual Studio 2013 до 2015 года, и теперь у меня возникают проблемы с точками останова.
Это удар или промах, где точки останова будут работать, и если я установлю его во время отладки, я получу ошибку:
Не удалось привязать точку останова.
Любая помощь будет оценена по достоинству. Я готов отказаться от 2015 года и вернуться.
У меня была такая же проблема, но другое решение. Обратите внимание, что я обновлен до версии VS 2015 Update 1, и проблема все еще существует.
В предыдущем выпуске отладки VS, запускающей отладку, автоматически запускается сборка в режиме отладки. Но с VS2015 это не так.
Итак, если ваша последняя сборка была в режиме выпуска, и вы пытаетесь выполнить отладку, точка останова не будет работать.
Сначала вы должны вручную построить в режиме отладки, а затем начать отладку.
У меня была та же проблема.
Я решил отключить опцию "Оптимизировать код" в закладке "Свойства проекта".
Это может показаться тривиальным, но после большого количества сбоев в работе с теми же проблемами, что и вы упоминаете, я обнаружил, что моя сборка была настроена на "выпуск" вместо "debug", когда я пытался отлаживать. для "debug" исправил его, и я мог бы установить точки останова как обычно
У меня была аналогичная проблема с точками прерывания, которые не удалось связать, а также с некоторыми локальными переменными, которые не оцениваются в окне 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"/>
the assemblyPostProcessorType является проблемой, я удалил ее и решил свою проблему
Измените режим Release на Debug, в моем случае это исправило мою проблему.
Я не изменил настройку "оптимизировать", но, основываясь на других ответах здесь, я
Пока это зафиксировало это для меня. Кажется, что обновление до версии VS2015. Обновление 2 укусило несколько вещей в моей системе.
Я помахал резиновой курятиной над моей машиной для разработки, нарисовал медный контур звезды вокруг нее, и это сработало. Прежде чем вы посмеиваться, это не менее бессмысленно, чем другие не-решения, предлагаемые для этой ошибки. Вы просто не собираетесь делать это с помощью любого из коротких или длинных шагов в любом из предлагаемых здесь решений. Я считаю, что отказ от Visual Studio 2015 - единственный практический способ избежать этого.
Сегодня я столкнулся с ошибками контрольной точки привязки. И я решил, что моя проблема делает сладости.
Если все настройки отладки неверны, вы не можете устранить проблему, которая делает слабые стороны.
Возможно, это решение помогает кому-то.
У меня была та же проблема, но не понял, что "Debug" изменился на "Release" на панели инструментов отладки (обычно непосредственно под меню). Поэтому я установил его в "Debug", он сработал.
Контрольные точки VS не могут связываться с асинхронными методами.
У меня был агент приложения Dynamics, который вызвал это. Удалите это, и вам хорошо идти.
Новое Обновление для Microsoft Visual Studio 2015 Update 3 (KB3165756) устранило проблему точки останова для меня, где я пытаюсь проверить локальные переменные в коде С#, встроенные в файлы cshtml в основных приложениях ASP.NET.
ШАГ 1, Измените очевидное:
ШАГ 2 Для проектов на С++:
Проверьте следующие свойства проекта:
Повторите шаг 1
Вы можете попробовать добавить __debugbreak(). Это утверждение должно идти в исходном файле, где вы хотите сломать.
ШАГ 2 Для проектов С#:
Попробуйте открыть свое решение на других машинах. Если вы можете привязать точку останова на другой машине, это может означать, что есть проблема с вашим VS или вашей ОС.
ШАГ 3, убедитесь, что ваш VS обновлен:
В RTM013 RTM появились сообщения о таких проблемах, как VS2013 Update 1 и Update2.
В VS перейдите в Инструменты/Расширения и Обновления/Обновления/Обновления Продукта и посмотрите, какую версию вы используете. Если обновление необходимо, оно появится там.
ШАГ 4, убедитесь, что ваша ОС обновлена:
Наконец, если вы запустили ОС Win 10, появилась ошибка, связанная с этой проблемой, которая существовала в сборке 14251. Это было разрешено в сборке 14257 (и выше).
Я столкнулся с подобной проблемой, и ни один из ответов здесь не затронул проблему, с которой я столкнулся. Однако, в отличие от вопроса, я никогда не получаю сообщений о том, что не удалось связать. Точка останова никогда не попадает. Надеюсь, это поможет кому-то в будущем ударить головой по стене с помощью 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 не должен был отправлять его на основе контрактов, просто что плохая запись заставила точку останова не попасть.
Мне пришлось изменить файл 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), у меня была эта проблема с проектами на С#. Пробовал чистить, перестраивать, перезагружать визуальную студию и т.д.
Что было исправлено, так это закрытие Visual Studio и удаление папки.vs, которая является скрытой папкой, расположенной в каталоге решения. Удаление папки.vs не должно вызывать у вас никаких проблем, хотя вам нужно будет сбросить загрузочный проект.
В моем случае после использования Profiler был создан новый файл web.config. Восстановление файла web.config до предыдущей версии решило эту проблему. Это было веб-приложение VS2015 С#.
Я просмотрел предыдущие ответы и @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
Но я чувствую, что это не лучший способ сделать это.