Проект Visual Studio 2015 больше не работает в режиме отладки

Вот что я получаю, даже когда запускаю в конфигурации отладки:

Я получил это, чтобы показать, включив «Только мой код» и предупредив, если при запуске нет кода пользователя. Это то, что недавно случилось с нашим проектом, и я не уверен, что мы сделали, чтобы это вызвать. Но я не смог это исправить. Точки останова не срабатывают, и быстрое наблюдение дает странные результаты.

Я попытался найти эту проблему в Google, но ни одно из стандартных решений «точки останова не сработает» не помогло. У меня нет идей.

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

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

Символы для модуля Navigo.exe не загружены.

1. Используйте конфигурацию сборки отладки или отключите параметр отладки «Включить только мой код».
2. Проверьте настройки «Символы» в параметрах отладки.

Таким образом, это решает мою основную проблему: я больше не могу использовать точки останова и всплывающее окно. Это странно, так как я думал, что для работы точек останова нужны символы, которые нужно загрузить. Итак, как могут работать точки останова, если символы не загружены? Может, это просто плохое сообщение?

Используйте Configuration Manager, чтобы проверить, каковы фактические настройки для конфигурации Debug - это в меню Build → Configuration Manager ... - если они настроены на использование Release :

Кроме того, убедитесь, что проект правильно определяет 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- не-включен-на-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. Нажмите ОК
4. Запустить отладку
5. Завершите отладку и повторите шаги 1–3, но вернитесь к «Несколько запускаемых проектов».
6. Снова запустить отладку с несколькими проектами

У меня была такая же проблема ... Что бы я ни делал - ничего не получалось.

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

Для меня это была ссылка NuGet с частного сервера NuGet. Я не знаю, как он был скомпилирован, но изменение ссылки на ссылку на проект помогло мне решить эту проблему.

Я открыл свой проект Visual Studio 2012 Pro в Visual Studio 2015 Express и столкнулся с той же проблемой.

Я проверил свои свойства решения → Свойства конфигурации и обнаружил, что для проекта установлено значение Release & x86.

Я снова изменил его на « Отладка» и « Любой процессор» , и запрос исчез.

В моем случае я разрабатывал плагин VSTO для Outlook , и Outlook случайно загрузил версию Release DLL-файла, которую я недавно установил во время тестирования своего установщика.

Похоже, Visual Studio пыталась использовать эту DLL вместо той, которую я ожидал отладить. Исправление того, какой файл DLL загружается Outlook, исправило это для меня.

Копирую мой другой ответ отсюда .

Как упомянул @romanoza, Microsoft обновила отчет об ошибке следующей информацией:

Снимите флажок с параметра Отладка -> Параметры -> Подавить оптимизацию JIT при загрузке модуля (только управляемый)

Это обходной путь. Позже они говорят:

Мы рекомендуем людям не устанавливать его, так как снятие флажка улучшит как производительность, так и поведение только моего кода в определенных сценариях.

Наконец, признание:

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

Я встретил ту же проблему и, наконец, решил ее, выбрав «Отключить только мой код и продолжить» .

Просто настройка моего кода

Шаги разрешения:

• Перейдите к настройкам сборки на странице свойств проблемного проекта .

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

• Убедитесь , что «Debug Info:» это не  установлено в «никто» .

  Я рекомендую вам использовать полную опцию.

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

Тем не менее, я изучал это больше, и я считаю, что это также может быть связано с настройкой «Изменить и продолжить» для отладчика. Когда я отключил это в меню Инструменты → Параметры ... Visual Studio, у меня больше не было проблемы. Но тогда это помешает вам использовать функцию « Изменить и продолжить» , поэтому я не уверен, стоит ли это того для вас.

Меню Инструменты → Параметры → Отладчик → Изменить и продолжить (прокрутите список до конца) → снимите флажок « Изменить и продолжить» .

Я также испытал это внезапно после установки Обновления 1, но могло быть просто, что у меня изначально был этот параметр ... Я не уверен.

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

Это было странное предупреждение.

Перестройка решения не обязательно приведет к удалению всех файлов DLL (особенно скопированных из зависимых проектов).

Однако при повторной сборке проекта зависимости это предупреждение исчезло.

Я столкнулся с этим с Visual Studio 2015 Update 3.

Мое решение немного отличалось от всех остальных и немного уникально.

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

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

Исправление проблемы в конструкторе моей управляемой сборки исправило все.

Теперь все имеет смысл, когда я оглядываюсь назад на общую картину, но в то время сообщение об ошибке привело меня по очень глубокому пути, и я попробовал все в ответе здесь, пока не получил это «А-ха!» момент.

Я провел два дня и, похоже, мне помог сброс экспериментального экземпляра Visual Studio 2017 .