Точка зупинки не вдалося зв’язати - Visual Studio 2015

Я щойно перейшов з Visual Studio 2013 до 2015 року, і тепер у мене виникають проблеми з точками прориву.

Це хіт або промах, де фактично працюватимуть точки перерви, і якщо я встановлю його під час налагодження, я отримую помилку:

Точку розриву не вдалося зв’язати.

Будь-яка допомога буде вдячна. Я готовий відмовитись від 2015 року та повернутися назад.

У мене була та сама проблема, але інше рішення. Зауважте, я оновив оновлення 1 до VS 2015, і проблема все ще існує.

У попередній редакції VS стартова відладка автоматично запускала збірку в режимі налагодження. Але з VS2015 це не так.

Тож якщо ваша остання збірка була в режимі випуску, і ви спробуєте налагоджувати, точка перерви не буде працювати.

Спершу вам потрібно вручну побудувати в режимі налагодження, а потім розпочати налагодження.

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

Я вирішив це, відключивши опцію "Оптимізувати код" на вкладці "Створення будівель".

Це може здатися тривіальним, але після великої кількості головних задач з тими ж проблемами, що ви згадували, я виявив, що моя збірка була встановлена ​​на "випуск" замість "налагодження", коли я спробував налагоджувати. "виправили це, і я міг встановити точки перерви як звичайні

У мене була схожа проблема з точками перерви, які не вдалося прив’язати, а також з певними локальними змінними, які не оцінюються у вікні локальних даних. Нарешті, це було виправлено, що ввімкнено опцію "Придушити оптимізацію 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 (видалив налаштування продуктивності 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чому проблема, я видалив її, і це вирішило мою проблему

Змініть режим випуску на налагодження. У моєму випадку це вирішило мою проблему.

Я не змінив налаштування "оптимізувати", але на основі інших відповідей тут

1. Встановіть Solution Explorer для показу всіх файлів для проекту
2. Видалено приховані папки бін та налагодження
3. Виконав проект «Очистити» над проектом
4. Виконували проект «Відбудувати» над проектом

Поки що це зафіксувало це для мене. Здається, що оновлення до оновлення VS2015 2 оновило декілька речей у моїй системі.

Я знаю, що це стара публікація, але якщо всі інші прийоми, описані вище, не спрацюють, ви переконайтеся, що зображення, яке ви намагаєтеся налагодити, є поточним. Чомусь після публікації та перенесення проекту .NET Core на мій Raspberry Pi 'unzip' на RPi не було копіювання та перезапис деяких DLL-файлів у робочому каталозі. Коли я приєднав налагоджувач, думаючи, що все гаразд, деякі точки перерви потрапляли, інші - ні, а деякі інші давали мені помилку "не можу пов'язати". Як тільки я вирішив розпаковувати проблему, всі мої точки перерви та символи повернулися. Я сподіваюся, що це допомагає.

Я сьогодні зіткнувся з помилками точки перерви прив’язки. І я вирішив свою проблему, роблячи нижню частину.

Якщо всі ваші конфігурації налагодження неправильні, ви не можете вирішити проблему, виконуючи нижче.

1. Чистий проект
2. Якщо вихідний шлях відрізняється від папки бін, замініть його на папку бін (це найважливіше правило)
3. Перебудувати

Можливо, це рішення комусь допоможе.

Точки зупинки VS не можуть прив'язуватися до методів асинхронізації.

У мене був встановлений агент "Динаміка додатків", який спричинив це. Видаліть це, і ви готові йти.

У мене була така ж проблема, але я не зрозумів, що "Налагодження" змінилося на "Випуск" на панелі інструментів налагодження (як правило, безпосередньо під меню). Тому я встановив його на "Налагодження", що він працював.

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

КРОК 1, виключіть очевидне:

• Компілювати в режимі налагодження.
• Спробуйте очистити розчин перед тим, як встановити точку розриву.
• Перейдіть у папку Налагодження та видаліть [Ваш додаток] .pdb файл.
• Потім зробіть збірку або відновіть свою програму.
• Перейдіть у папку Налагодження і переконайтеся, що у вас є абсолютно новий [Ваш додаток] .pdb файл.
• Потім спробуйте встановити точку перерви.

КРОК 2 Для проектів C ++:

Перевірте такі властивості проекту:

• C ++ / Загальний / Формат інформації про налагодження: база даних програми.
• C ++ / Оптимізація: вимкнено.
• C ++ / Генерація коду / Бібліотека виконання: Багатопотокова налагодження.
• Linker / Debugging / Створення інформації про налагодження: Так.
• Linker / Debugging / Створення бази даних програми: $ (TargetDir) $ (TargetName) .pdb.
• Файл зв’язків / маніфестів / генерувати маніфест: ні.
• Файл маніфесту / маніфесту / Дозволити ізоляцію: Ні.
• Linker / Embedded IDL / Ігнорувати вбудований IDL: Так.

• Зробіть крок 1 ще раз

  Ви можете спробувати додати __debugbreak (). Цей вислів повинен міститись у вихідному файлі, де ви хочете зламати.

КРОК 2 для проектів C #:

• У властивостях проектів Build / General / Оптимізація коду слід вимкнути.
• У налаштуваннях IDE Налагодження / Параметри та налаштування / Налагодження / Загальне придушення оптимізації JIT на завантаженні модуля (лише керований): Увімкнено
• Зробіть крок 1 ще раз

Спробуйте відкрити своє рішення на інших машинах. Якщо ви можете прив’язати точку розриву на іншій машині, це може означати, що виникла проблема з вашим VS або вашою ОС.

КРОК 3. Переконайтесь, що ваш VS оновлений:

Були повідомлення про подібні проблеми в VS2013 RTM, а також VS2015 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"/>

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

Я спробував усе, що тут запропоновано. Врешті-решт я встановив "Конкретну сторінку" в "Властивості проекту" -> "Веб" для моєї локальної початкової URL-адреси, сторінки та запиту. Очистив та відновив у режимі налагодження, і це потрапило на мій пункт перелому.

Хоча це набагато пізніша збірка (VS2017), у мене виникли проблеми з проектами C #. Спробували прибирання, перебудову, перезапуск візуальної студії тощо.

Виправлено це закриття Visual Studio та видалення папки .vs, яка є прихованою папкою, розташованою в каталозі рішення. Видалення папки .vs не повинно викликати проблем, хоча вам потрібно буде скинути проект запуску.

У моєму випадку з’явився новий файл web.config, створений після використання Profiler. Відновлення web.config до попередньої версії вирішило цю проблему. Це був веб-додаток VS2015 C #.

Якщо ви публікуєте перевірку веб-додатків, Configurationвстановлену Debug(за замовчуванням у конфігурації налагодження встановлено таке, що код не оптимізовано, а таблиця символів повністю створена).

Я переглянув попередні відповіді, і в одязі @ Вілла виправлено основну проблему, яка у мене була, інша - можливість редагувати та продовжувати, але детальніше ознайомившись з файлом 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

Але я відчуваю, що це не найкращий спосіб зробити це.