"Impossible d'évaluer une expression car le code de la méthode actuelle est optimisé" dans Visual Studio 2010
J'utilise Visual Studio 2010 en mode débogage et l'option "optimiser le code" n'est pas cochée. Je ne peux pas regarder (ou survoler) rapidement une variable du débogueur. Je reçois cette erreur "Impossible d'évaluer l'expression car le code de la méthode actuelle est optimisé".
Même une ligne comme: int i = -3, faisant une rapide observation de i, j’obtiens «Impossible d’obtenir la valeur de local ou l’argument 'i' car elle n’est pas disponible à ce pointeur d’instruction, peut-être parce qu’elle a été optimisée."
Ce lien référencé dans une question similaire ne semble pas s'appliquer.
Y a-t-il un paramètre qui me manque?
Alors que le projet était en mode débogage, la solution ne l'était pas. Quand je l'ai changé, ça a fonctionné.
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
On dirait que vous déboguez une version optimisée/publiée, même si la case optimisée n'est pas cochée. Les choses que vous pouvez essayer sont:
- Effectuez une reconstruction complète de votre fichier de solution (cliquez avec le bouton droit de la souris sur la solution et sélectionnez Rebuild all).
- Pendant le débogage, ouvrez la fenêtre des modules (Debug -> Windows -> Modules) et recherchez votre assemblage dans la liste des modules chargés. Vérifiez que le chemin répertorié par rapport à votre assembly chargé correspond à ce que vous attendez et que l'horodatage modifié du fichier indique que l'assembly a effectivement été reconstruit.
- La fenêtre de modules devrait également vous indiquer si le module chargé est optimisé ou non - assurez-vous que la fenêtre de modules indique qu'il n'est pas optimisé.
Si vous ne voyez pas l'élément de menu Modules dans le menu Debug -> Windows, vous devrez peut-être l'ajouter dans le menu "Personnaliser ...".
Dans VS2013, accédez à: Outils -> Options -> Débogage -> Général et activez "Utiliser le mode de compatibilité géré". Cela désactive le nouveau comportement d'évaluation de la fonction.
Essayez de fonctionner en mode débogage. Si vous utilisez le mode publication, vous obtiendrez ce message.
J'ai eu le même problème dans VS2008. Dans mon cas, cela a été résolu via solution-reconstruire.
Ma situation n'était couverte par aucune des réponses ci-dessus. J'ai trouvé ce qui suit: Article MSDN sur le threading expliquant que, lorsqu'il est bloqué dans certaines opérations de threading natives primitives, le débogueur ne peut pas accéder aux données. Par exemple, lorsqu'un thread est assis sur Task.Wait (), cela se produit.
J'ai eu le même problème. Mais dans mon cas, l'attribut Debuggable a été codé en dur dans le fichier AssemblyInfo.cs de mon projet et n'a donc pas été écrasé par compilation. Cela fonctionnait après la suppression de la ligne spécifiant l'attribut Debuggable.
À part @Kragen mentionné, si vous déboguez un projet Web
fermez Visual Studio et essayez de supprimer les fichiers temporaires dans C:\Windows\Microsoft.NET\Framework\v2.0.50727\Fichiers ASP.NET temporaires
Lorsque vous voyez le message " Impossible d'évaluer l'expression car le code de la méthode actuelle est optimisé. " après avoir émis une instruction Debugger.Break(), assurez-vous d'appuyer sur F10 pour passer à l'instruction suivante.
Une fois passé à la prochaine instruction, et en supposant que vous exécutiez une construction Debug, ce message devrait disparaître.
J'ai eu le même problème lors du débogage d'une bibliothèque de classe à partir d'une application web testbed. Je faisais référence à la version de publication dans le banc d'essai et cette configuration devait être optimisée dans les propriétés de la bibliothèque de classes.
Décocher la case à cocher optimiser le code de la version dans les propriétés de la bibliothèque de classes, au moment même où je l'écris, a résolu le problème.
Je me rends compte que c’est une réponse ultérieure, mais j’ai trouvé une autre référence à un moyen de résoudre ce problème qui pourrait aider les autres à l’avenir. Cette page Web décrit la définition d’une variable d’environnement (COMPLUS_ZapDisable = 1) qui empêche l’optimisation, du moins l’a fait pour moi! (N'oubliez pas la deuxième partie de la désactivation du processus d'hébergement Visual Studio.) Dans mon cas, cela aurait peut-être été encore plus pertinent car je déboguais un DLL externe via un serveur de symboles, mais je ne suis pas sûr .
Une autre chose à faire est de créer un fichier portant le même nom que la DLL optimisée mais avec une extension ini et d’ajouter ce qui suit:
[Contrôle de débogage .NET Framework]
GenerateTrackingInfo = 1
AllowOptimize = 0
Cela indiquera au JIT de ne pas optimiser vos variables.
Notez que vous avez toujours besoin de la pdb, vous allez donc vous retrouver avec quelque chose comme ceci: VotreDll.dll.
Cela fonctionne particulièrement bien dans les scénarios où vous n'avez pas accès à la régénération des DLL avec l'option de débogage.
http://www.hanselman.com/blog/DebugVsReleaseTheBestOfBothWorlds.aspx
En ce qui concerne le problème de non-vérification de la propriété "Optimiser le code", le code compilant toujours comme optimisé: ce qui m'a finalement aidé après avoir tout essayé était de cocher la case "Activer le débogage de code non géré" sur la même page de paramètres (Propriétés du projet - Débogage). Cela ne concerne pas directement l'optimisation du code, mais avec cette option activée, VS n'optimise plus ma bibliothèque et je peux déboguer.
J'ai eu ce problème avec un projet F # qui avait été ça et là entre Visual Studio et MonoDevelop, peut-être originaire de ce dernier (j'oublie). Dans VS, la case d'optimisation était décochée, mais l'optimisation semblait certainement se produire pour le débogueur.
Après avoir comparé le code XML du fichier de projet à celui du fichier sain, le problème était évident: le projet sain comportait une ligne explicite <optimize>false</optimize>, alors que le mauvais le manquait complètement. VS déduisait évidemment de son absence que l'optimisation était désactivée, alors que le compilateur faisait l'inverse.
La solution consistait à ajouter cette propriété au fichier de projet et à recharger.
J'ai eu le même problème dans VS 2010. J'ai nettoyé et reconstruit la solution et cela a fonctionné.
le commentaire de vickramds ci-dessus, faisant référence à http://torulflundgren.blogspot.com.au/2010/03/cannot-obtain-value-of-local-or.html , l'a fait pour moi. J'ai tout vérifié - j'ai supprimé toutes les dll, fichiers pdb des dossiers bin locaux, Nettoyer, Reconstruire, effacé tous les dossiers de fichiers ASP.NET temporaires, vérifié que les indicateurs TRACE/DEBUG étaient définis, vérifié les chemins DLL, etc.
Pour le résumer de sorte qu'il ne soit pas perdu, pour le (s) projet (s) concerné (s):
Propriétés du projet -> Construire -> Avancé -> Informations de débogage: Complet.
Vous voulez vérifier que la configuration de débogage a bien été sélectionnée avant de procéder ainsi, à moins bien sûr que vous n'ayez voulu autrement.
J'ai commencé à recevoir ce message lorsque j'ai migré vers Visual Studio 2017. Aucune des idées de cette page que j'ai essayées ne fonctionnait pour moi. Sur un autre post, j'ai trouvé cette suggestion et elle DID fonctionne - supprime:
[Assembly: Debuggable(DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints)]
... depuis votre fichier AssemblyInfo.
Pour moi, cela se passait dans VS2017 et VS2019. Cela ne s'est plus produit après avoir sélectionné l'option "Optimisation JIT supprimée lors du chargement du module".
Si vous essayez de déboguer un projet ASP.NET, vérifiez que la liste déroulante Propriétés> Web> Serveurs du projet est définie sur "IIS Express" (en plus de vérifier tout le reste ici).
J'avais mélangé des dlls d'extension c ++/cli mfc, qui étaient optimisées même en configuration de débogage (vue de la fenêtre Modules VS 2017). Comme je l’avais suggéré dans ma réponse précédente, j’ai changé "Dans VS2013, accédez à: Outils -> Options -> Débogage -> Général et activez" Utiliser le mode de compatibilité géré ". Ceci désactive le nouveau comportement d’évaluation de la fonction." Que les paramètres trouvent également dans VS 2017.
Mais cela ne suffisait pas. J'ai donc également copié le paramètre UseDebugLibraries d'un fichier de projet d'une autre application MFC dans un fichier de projet d'extension dll.
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'" Label="Configuration">
...
<UseDebugLibraries>true</UseDebugLibraries>
Ensuite, reconstruisez et que le problème soit résolu.