Que "Ne peut évaluer une expression parce que le code de la méthode actuelle est optimisé." signifier?
J'ai écrit du code avec beaucoup de récursivité, ce qui prend un peu de temps. Chaque fois que je "marque une pause" pour voir ce qui se passe, je reçois:
Impossible d'évaluer une expression car le code de la méthode actuelle est optimisé.
Je pense comprendre ce que cela signifie. Cependant, ce qui me laisse perplexe, c’est qu’après avoir frappé step, le code n’est plus «optimisé» et je peux consulter mes variables. Comment cela peut-il arriver? Comment le code peut-il basculer entre code optimisé et non optimisé?
Le débogueur utilise FuncEval pour vous permettre de "regarder" les variables. FuncEval exige que les threads soient arrêtés dans du code géré à un point sécurisé GarbageCollector. Si vous interrompez manuellement l'exécution dans IDE, tous les threads s'arrêtent dès que possible. Votre code hautement récursif aura tendance à s'arrêter à un point dangereux. Par conséquent, le débogueur est incapable d'évaluer les expressions.
Appuyez sur F10 pour passer au prochain point de sécurité Funceval et activer l’évaluation des fonctions.
Pour plus d'informations, consultez les règles de FuncEval .
Tant que la ligne Debug.Break () est en haut de la pile d’appel, vous ne pouvez pas évaluer les expressions. C'est parce que cette ligne est optimisée. Appuyez sur F10 pour passer à la ligne suivante - une ligne de code valide - et la montre fonctionnera.
Vous essayez probablement de déboguer votre application en mode publication au lieu du mode débogage, ou vous avez des optimisations activées dans vos paramètres de compilation.
Lorsque le code est compilé avec des optimisations, certaines variables sont supprimées une fois qu'elles ne sont plus utilisées dans la fonction. C'est pourquoi vous recevez ce message. En mode débogage avec les optimisations désactivées, vous ne devriez pas avoir cette erreur.
Cela m'a rendu fou. J'ai essayé de joindre avec le code géré et natif - no go.
Cela a fonctionné pour moi et j'ai finalement pu évaluer toutes les expressions:
- Allez dans Projet/Propriétés
- Sélectionnez l'onglet Générer et cliquez sur Avancé ...
- Assurez-vous que les informations de débogage sont définies sur "complet"
- Déboguer votre projet - le tour est joué!
Le dessous a fonctionné pour moi, merci @Vin.
J'avais ce problème lorsque j'utilisais VS 2015. Ma solution: la configuration (Debug) a été sélectionnée. J'ai résolu ce problème en décochant la propriété Optimize Code sous les propriétés du projet.
Projet (clic droit) => Propriétés => Construire (onglet) => décochez Optimiser le code
Assurez-vous de ne pas avoir quelque chose comme ça
[Assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
dans votre AssemblyInfo
Recherchez un appel de fonction avec plusieurs paramètres et essayez de réduire le nombre jusqu’au retour du débogage.
L'ami d'un ami de Microsoft a envoyé ceci: 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-256-argument-bytes-.aspx
Le problème le plus probable est que votre pile d'appels est en train d'être optimisée car la signature de votre méthode est trop grande.
Avait le même problème, mais était capable de le résoudre en désactivant le recouvrement des exceptions dans le débogueur. Cliquez sur [Déboguer] [Exceptions] et définissez les exceptions sur "Non géré par l'utilisateur".
Normalement, je l’ai désactivé, mais il est utile à l’occasion. Je dois juste me rappeler de l'éteindre quand j'ai fini.
J'avais ce problème lorsque j'utilisais VS 2010. Ma configuration de solution a (Debug) sélectionné. J'ai résolu ceci en décochant la propriété Optimiser le code sous les propriétés du projet . Projet (clic droit) => Propriétés => Construire (onglet) => décocher Optimiser le code
Dans mon cas, j'avais 2 projets dans ma solution et exécutais un projet qui n'était pas le projet de démarrage . Lorsque je l'ai changé en projet de démarrage, le débogage a recommencé à fonctionner.
J'espère que ça aide quelqu'un.
Évaluation:
Dans .NET, «Evaluation de la fonction (funceval)» est la capacité du CLR d’injecter un appel arbitraire pendant que le débogage est arrêté quelque part. Funceval prend en charge le thread choisi par le débogueur pour exécuter la méthode demandée. Une fois que funceval a terminé, il déclenche un événement de débogage. Techniquement, les CLR ont défini des méthodes permettant au débogueur d’émettre un funceval.
CLR permet d’initialiser funceval uniquement sur les threads situés au point de sécurité GC (c’est-à-dire quand le thread ne bloque pas le GC) et le point Funceval Safe (FESafe) (c’est-à-dire où CLR peut effectuer le piratage pour le funceval.) Ensemble. Ainsi, scénarios possibles pour CLR, un fil doit être:
arrêté en code géré (et à un point sécurisé du CPG): cela implique que nous ne pouvons pas effectuer de fonction en code natif. Comme le code natif n’est pas sous le contrôle du CLR, il est impossible de configurer le funceval.
arrêté à une première chance ou à une exception gérée non gérée (et à un point de sécurité du GC): c’est-à-dire qu’au moment de l’exception, inspecter autant que possible pour déterminer la raison de cette exception. (par exemple, le débogueur peut essayer d’évaluer et de voir la propriété Message lors d’une exception levée.)
De manière générale, les méthodes habituelles d'arrêt dans le code managé incluent l'arrêt à un point d'arrêt, une étape, un appel Debugger.Break, l'interception d'une exception ou le démarrage d'un thread. Cela aide à évaluer la méthode et les expressions.
Solutions possibles: .__ Selon l'évaluation, si le thread n'est pas à un point FESafe et GCSafe, le CLR ne pourra pas détourner le thread pour initier funceval. En règle générale, le fait de suivre funceval commence normalement lorsque attendu:
Étape 1:
Assurez-vous que vous n'essayez pas de déboguer une version «Release». La publication est entièrement optimisée et entraînera donc une erreur de discussion. En utilisant la barre d'outils Standard ou le Gestionnaire de configuration, vous pouvez basculer entre Debug et Release.
Étape 2:
Si vous obtenez toujours l'erreur, l'option de débogage peut être définie pour l'optimisation. Vérifiez et décochez la propriété «Optimiser le code» sous Projet «Propriétés»:
Cliquez avec le bouton droit de la souris sur l'option ProjetSélectionnez «Propriétés» Cliquez sur l'onglet «Générer» Décochez la case «Optimiser le code».
Étape 3:
Si l'erreur persiste, le mode informations de débogage est peut-être incorrect. Vérifiez et définissez-le sur «complet» sous «Paramètres de construction avancés»:
Cliquez avec le bouton droit de la souris sur l'option ProjetSélectionnez «Propriétés» Cliquez sur le bouton «Générer» Cliquez sur le bouton «Avancé» Définissez «Informations de débogage» sur «Complet».
Étape 4:
Si le problème persiste, essayez ce qui suit:
Faites un “nettoyage” puis une “reconstruction” de votre fichier de solution Pendant le débogage: Allez dans la fenêtre des modules (Menu VS -> Debug -> Windows -> Modules) Trouvez votre assemblage dans la liste. Vérifiez que le chemin indiqué dans l'assembly chargé correspond à ce que vous attendez Vérifiez l'horodatage modifié du fichier pour confirmer que l'assembly a bien été reconstruit Vérifiez si le module chargé est ou non chargé. est optimisé ou non
Conclusion:
Ce n’est pas une erreur, mais une information basée sur certains paramètres et conçue selon le fonctionnement de l’exécution de .NET.
J'ai eu un problème similaire et il a été résolu lorsque j'ai construit la solution en mode débogage et remplacé le fichier pdb dans le chemin d'exécution.
dans mon cas, j'étais en mode de sortie ceux que j'ai changé pour tout mettre au point