Что означает "Невозможно оценить выражение, потому что код текущего метода оптимизирован". имею в виду?

Ответ 1

Отладчик использует FuncEval, чтобы вы могли "смотреть на" переменные. FuncEval требует, чтобы потоки были остановлены в управляемом коде в безопасной точке GarbageCollector. Вручную "приостановка" запуска в среде IDE приводит к тому, что все потоки останавливаются как можно скорее. Ваш очень рекурсивный код будет иметь тенденцию останавливаться в небезопасной точке. Следовательно, отладчик не может оценивать выражения.

Нажатие кнопки F10 переместится в следующую безопасную точку Funceval и включит функцию оценки.

Для получения дополнительной информации ознакомьтесь с правилами FuncEval.

Ответ 2

В то время как строка Debug.Break() находится на вершине вызова, вы не можете выражать выражения. Это потому, что эта линия оптимизирована. Нажмите F10, чтобы перейти к следующей строке - действительная строка кода - и часы будут работать.

Ответ 3

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

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

Ответ 4

Это сводило меня с ума. Я попробовал установить с управляемым и родным кодом - не нужно.

Это сработало для меня, и я наконец смог оценить все выражения:

• Перейдите в Project/Properties
• Выберите вкладку "Сборка" и нажмите Дополнительно...
• Убедитесь, что для параметра Debug Info установлено значение "full" (не только pdb)
• Отладить ваш проект - вуаля!

Ответ 5

Ниже я работал у меня, спасибо @Vin.

У меня была эта проблема, когда я использовал VS 2015. Мое решение: у конфигурации есть (отладка). Я решил это, сняв флажок Optimize Code свойства в свойствах проекта.

Проект (правый клик) = > Свойства = > Сборка (вкладка) = > снимите флажок Оптимизировать код

Ответ 6

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

Ответ 7

Убедитесь, что у вас нет чего-то подобного

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

в AssemblyInfo

Ответ 8

Друг друга из Microsoft отправил: http://blogs.msdn.com/rmbyers/archive/2008/08/16/Func_2D00_eval-can-fail-while-stopped-in-a-non_2D00_optimized-managed-method-that-pushes-more-than-256-argument-bytes-.aspx

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

Ответ 9

Имел ту же проблему, но смог ее разрешить, отключив исключение исключения в отладчике. Нажмите [Отладка] [Исключения] и установите исключения для "Пользователь-необработанный".

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

Ответ 10

У меня была эта проблема, когда я использовал VS 2010. Моя конфигурация решения была выбрана (Debug). Я решил это, сняв флажок Свойство "Оптимизировать код" в свойствах проекта. Проект (правый щелчок) = > Свойства = > Сборка (вкладка) = > снимите флажок Оптимизировать код

Ответ 11

В моем случае у меня было 2 проекта в моем решении и выполнял проект, который не был проектом запуска. Когда я изменил его на проект запуска, отладка начала работать снова.

Надеюсь, что это поможет кому-то.

Ответ 12

Оценка:

В .NET "Оценка функции (funceval)" - это способность CLR вводить произвольный вызов, в то время как debuggee останавливается где-то. Funceval отвечает за выбранный поток отладчиков для выполнения запрошенного метода. Когда funceval заканчивается, он запускает событие отладки. Технически CLR определила способы отладки для выпуска funceval.

CLR позволяет инициировать funceval только для тех потоков, которые находятся в точке безопасности GC (то есть, когда поток не будет блокировать GC) и точки Funceval Safe (FESafe) (т.е. там, где CLR может фактически сделать захват для funceval.) вместе, Таким образом, возможные сценарии для CLR, поток должен быть:

• остановлен в управляемом коде (и в точке безопасности GC): Это означает, что мы не можем выполнить funceval в собственном коде. Поскольку собственный код находится вне элемента управления CLR, он не может настроить funceval.

• останавливается при 1-м случайном или необработанном управляемом исключении (и в безопасной точке GC): i.e во время исключения проверять как можно больше, чтобы определить, почему произошло это исключение. (например: отладчик может попытаться оценить и увидеть свойство Message в поднятом исключении.)

В целом, общие способы остановки в управляемом коде включают остановку в точке останова, шаге, вызове Debugger.Break, перехвате исключения или при запуске потока. Это помогает в оценке метода и выражений.

Возможные разрешения: Основываясь на оценке, если поток не находится в точках FESafe и GCSafe, CLR не сможет захватить поток, чтобы инициировать funceval. Как правило, следующее помогает убедиться, что funceval инициирует, когда ожидается:

Шаг # 1:

Убедитесь, что вы не пытаетесь отладить сборку "Release". Выпуск полностью оптимизирован и, таким образом, приведет к ошибке в обсуждении. С помощью стандартной панели инструментов или Configuration Manager вы можете переключаться между Debug и Release.

Шаг # 2:

Если вы все еще получаете ошибку, для оптимизации может быть задана опция Debug. Проверьте и снимите флажок "Оптимизировать код" в разделе "Свойства" :

Щелкните правой кнопкой мыши проект Выберите опцию "Свойства" Перейдите на вкладку "Построить". Снимите флажок "Оптимизировать код"

Шаг №3:

Если вы все еще получаете сообщение об ошибке, может потребоваться неверный режим Debug Info. Проверьте и установите его в "полный" в разделе "Расширенные настройки сборки":

Щелкните правой кнопкой мыши проект Выберите опцию "Свойства" Перейдите на вкладку "Построить". Нажмите кнопку "Дополнительно" Установите "Debug Info" как "полный"

Шаг # 4:

Если вы все еще сталкиваетесь с проблемой, попробуйте следующее:

Сделайте "Очистить", а затем "Восстановить" файла решения При отладке: Перейдите в окно модулей (VS Menu → Debug → Windows → Modules) Найдите свою сборку в списке загруженных модулей. Проверьте, что путь, указанный против загруженной сборки, является тем, что вы ожидаете от него Проверьте измененную временную метку файла, чтобы подтвердить, что сборка была фактически перестроена Проверьте, оптимизирован ли загруженный модуль или нет.

Вывод:

Это не ошибка, а информация, основанная на определенных настройках и разработанная на основе того, как работает среда выполнения .NET.

Ответ 13

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

Ответ 14

У меня была аналогичная проблема, и она была решена, когда я построил решение в режиме отладки и заменил файл pdb в пути выполнения.

Ответ 15

Я считаю, что то, что вы видите, является результатом оптимизаций - иногда переменная будет использоваться повторно, особенно те, которые созданы в стеке. Например, предположим, что у вас есть метод, который использует два (локальных) целых числа. Первое целое объявляется в начале метода и используется исключительно как счетчик для цикла. Второе целое число используется после завершения цикла и хранит результат вычисления, которое позднее выписывается в файл. В этом случае оптимизатор МОЖЕТ принять решение о повторном использовании вашего первого целого числа, сохраняя код, необходимый для второго целого. Когда вы попытаетесь взглянуть на второе целое на раннем этапе, вы получите сообщение о том, что вы спрашиваете "Невозможно оценить выражение". Хотя я не могу объяснить точные обстоятельства, оптимизатор может позже передать значение второго целого в отдельный элемент стека, в результате чего вы сможете получить доступ к значению из отладчика.