Проект Visual Studio 2015 більше не працює в режимі налагодження

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

Я показав це шляхом включення функції "Просто мій код" та попередження про відсутність коду користувача під час запуску. Це нещодавно сталося з нашим проектом, і я не впевнений, що ми зробили для цього. Але мені не вдалося це виправити. Точки зупинки не спрацьовують, і швидкий перегляд дає дивні результати.

Я намагався погуглити проблему, але жодне із стандартних рішень "точки зупинки не спрацьовує" не спрацювало. У мене все не вистачає ідей.

Я перевірив диспетчер конфігурацій, і для кожного проекту також встановлено налагодження.

Я вимкнув "Увімкнути оптимізацію", і я більше не отримую діалогове вікно "Ви налагоджуєте випуск збірки". Він знову працює і зупиняється на точках зупинки! Однак вікно виводу відображає це під час запуску:

Символи для модуля 'Navigo.exe' не завантажені.

1. Використовуйте конфігурацію збірки налагодження або вимкніть опцію налагодження "Увімкнути лише мій код".
2. Перевірте параметри «Символи» в розділі «Налаштування».

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

Використовуйте диспетчер конфігурацій, щоб перевірити фактичні параметри конфігурації налагодження - це в меню Побудова → Менеджер конфігурацій ... - на випадок, якщо вони налаштовані на використання версії :

Крім того, переконайтеся, що проект правильно визначає DEBUG , а також, що "Оптимізувати код" не встановлено:

Це трапилося зі мною також у кількох проектах. Я переглянув свої налаштування збірки, як запропонував stuartd . Однак параметр "Оптимізувати код" не був увімкнений у моїх налаштуваннях збірки. Тож я його увімкнув і проект врятував. Потім я відмінив його і знову врятував. Проблема вирішена.

Існує якась помилка, через яку --optimize+прапор передається налагоджувачу. Увімкнути його, а потім відключити - це простий спосіб вирішення, доки помилка не буде виправлена.

Це почало траплятися зі мною після застосування оновлення 1. Існуючі проекти почали це показувати, і я можу повторити це за допомогою абсолютно нового проекту. Вся конфігурація встановлюється в DEBUG і Оптимізувати це НЕ перевіряється.

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

Єдиним рішенням є вимкнення параметра « Просто мій код» - що здається хакерством, як це було на попередньому оновлення 1 без будь-яких проблем.

Якщо жодне із згаданих рішень не допомогло, перевірте AssemblyInfo.cs вашого проекту на наявність явної програми DebuggableAttribute. Здається, це замінює варіанти налагодження / випуску компілятора.

У моєму випадку у мене був цей рядок у файлі (застарілий проект, не маючи уявлення, як він туди потрапив). Видалення вирішило проблему:

[assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]

Виберіть меню Налагодження → Параметри та скасуйте вибір опції Придушити JIT-оптимізацію . Це працює для мене.

Джерело: https://connect.microsoft.com/VisualStudio/feedback/details/2116788/flag-optimize-is-passed-to-the-debugger-even- while- the- build- settings- optimize- code- is- not-enabled-on-mvc-c-web-projects-when-using-just-my-code

Я також зіткнувся з цим питанням. Виправлення, на яке працювало, було просто очищення ( Build > Clean Solution) та відновлення ( Build > Rebuild Solution) моїх проектів.

Жодна з попередніх відповідей не спрацювала для мене. Виправлено перезапуск IIS .

Просто додавши допоміжну примітку до відповіді Стюартда :

Переконайтеся, що ви перевіряєте будь-які залежні проекти на однакові налаштування збірки. Ви отримаєте те саме повідомлення із запитом, якщо ваш основний проект має належні налаштування, але ваші залежні проекти цього не роблять. З огляду на це очевидно, але це не перше, що прийшло в голову.

У моєму випадку проблема полягала в тому, що URL-адресу проекту IIS на веб-вкладці властивостей проекту ASP.NET було встановлено неправильну URL-адресу.

Це вказувало на http: // localhost, яке я використовував з іншою копією проекту. Адреса рішення, яке я відкрив, була фактично налаштована в моєму локальному IIS як http: // localhost: 90 .

Перехід на правильну адресу вирішив проблему.

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

1. Клацніть правою кнопкою миші на рішенні та виберіть "Властивості"
2. У розділі "Загальні властивості" змініть вибір "Кілька стартових проектів" на "Один стартовий проект"
3. Клацніть OK
4. Запустіть налагодження
5. Завершіть налагодження та повторіть кроки 1-3, але поверніться до "Кілька проектів запуску"
6. Знову запустіть налагодження з кількома проектами

У мене була та сама проблема ... Що б я не робив - нічого не працювало.

Проблемою став новий порожній проект. У підсумку я видалив проект і додав новий проект - новий проект повинен був мати іншу назву ; якщо я використовував те саме ім'я, помилка просто з'явилася - навіть після перезавантаження, очищення та відновлення ... Це має бути помилка у Visual Studio 2015.

Для мене це було посилання на NuGet із приватного сервера NuGet. Я не знаю, як це було складено, але зміна посилання на посилання на проект дозволила мені пройти проблему.

Я відкрив свій проект Visual Studio 2012 Pro у Visual Studio 2015 Express і мав ту саму проблему.

Я перевірив свої властивості рішення → Властивості конфігурації та виявив, що для проекту встановлено Release & x86.

Я змінив його назад на Debug and Any CPU , і запит пішов.

У моєму випадку я розробляв плагін VSTO для Outlook , і Outlook випадково завантажував випускну версію файлу DLL, який я нещодавно встановив під час тестування мого інсталятора.

Схоже, Visual Studio намагався використовувати цю DLL замість налагодженої, яку я очікував. Виправлення того, який файл DLL завантажується Outlook, це виправило для мене.

Копіюючи мою іншу відповідь звідси .

Як згадував @romanoza, Microsoft оновила звіт про помилку наступною інформацією:

Зніміть прапорець Налагодження -> Параметри -> Придушити оптимізацію JIT при завантаженні модуля (лише керований)

Це обхідний шлях. Далі вони говорять:

Ми рекомендуємо людям залишати його не позначеним, оскільки його вимкнення покращить як продуктивність, так і поведінку лише мого коду в конкретних сценаріях.

Нарешті, підтвердження:

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

Я зіткнувся з тією ж проблемою і, нарешті, вирішив її, вибравши "Вимкнути лише мій код і продовжити" .

Просто налаштування мого коду

Кроки вирішення:

• Перейти до Будівництву налаштування порушив проекту Властивості сторінки.

• Прокрутіть униз до кнопки «Додатково ...» .

• Переконайтеся , що «Debug Info:" це НЕ  встановлено в «немає» .

  Я рекомендую вам використовувати повний варіант.

Переглянувши посилання Патріка як коментар до запитання , хтось зазначив обхідний шлях, який полягав у зупинці сайту в IIS Express . Я зміг запобігти появі цієї ж проблеми, зробивши саме це після зупинки налагоджувача у Visual Studio.

Однак я розглядав це більше, і я вважаю, що це також може бути пов'язано з налаштуванням "Редагувати та продовжити" для налагоджувача. Коли я відключив це в меню Інструменти → Параметри ... Visual Studio, у мене більше не було проблеми. Але тоді це завадило б вам використовувати функцію « Редагувати та продовжити» , тому я не впевнений, чи це вам того варте.

Інструменти меню → Параметри → Налагоджувач → Редагувати та продовжити (прокрутіть униз загального списку) → зніміть прапорець Редагувати та продовжити .

Я також раптово пережив це після встановлення оновлення 1, але могло бути просто так, що спочатку це налаштування було вимкнено ... Хоча я не впевнений.

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

Це було дивне сповіщення.

Відновлення рішення не обов'язково очистить усі файли DLL (особливо ті, що скопійовані із залежних проектів).

Однак відновлення проекту залежності змусило це сповіщення зникнути.

Я зіткнувся з цим за допомогою Visual Studio 2015, оновлення 3.

Моє рішення трохи відрізнялося від усіх інших і трохи унікальне.

Я працюю з веб-сайтом, що містить поєднання керованого коду та ASP Classic , що посилаються на одну і ту ж збірку. Visual Studio скаржився, що мій керований файл DLL є збіркою випуску.

Ця проблема була невловимим винятком у моїй збірці, але її викидала сторінка ASP Classic через interop. Visual Studio не зміг впоратися з налагодженням цього повідомлення та відобразив повідомлення про помилку. Той самий виняток, викинутий із керованого коду, вивів би налагоджувач, як очікувалося.

Виправлення проблеми у конструкторі моєї керованої збірки все виправило.

Усе це має сенс зараз, коли я оглядаю загальну картину, але в той час повідомлення про помилку вело мене дуже глибоким шляхом, і я намагався все у відповіді тут, поки не з’явилося те "А-ха!" мить.

Я провів два дні, і схоже, що мені скинув експериментальний екземпляр Visual Studio 2017 .