Lors du débogage du code asp.net (exécuté contre IIS et utilisant Visual studio 2013) et dans un point d'arrêt et essayant d'évaluer une variable à l'aide de la surveillance rapide, je suis souvent "incapable d'évaluer l'expression".
la suppression du .suo du dossier du projet asp.net semble résoudre le problème (après le rechargement de la solution)
Est-ce un bug reconnu? obtenir beaucoup maintenant dans Visual studio 2013 sur plus d'une machine.
Je l'ai affronté aujourd'hui avec VS2013.
Allez à Outils -> Options -> Débogage -> Général -> Faites défiler vers le bas pour "Utiliser le mode de compatibilité géré" et sélectionnez l'option.
Capture d'écran du blog (url ci-dessous): Redémarrez votre débogage. J'espère que cela aide les autres.
Ce qui m'a aidé est ci-dessous!
Visual Studio 2013 n'a pas pu évaluer l'anomalie du débogueur d'expression s'est avéré très utile.
En outre, vous pouvez voir @Dreamers répondre Impossible de déboguer le code managé à l'aide de Visual Studio 201
Le moteur de débogage C # s'appuie fortement sur le débogueur CLR pour évaluer les expressions. Ce message indique que le CLR est dans un état dans lequel il n'est pas en mesure d'effectuer des évaluations simples et les raisons peuvent inclure les éléments suivants
Certaines de ces options changent au fil du temps - et les solutions les mieux notées dans d'autres réponses ne semblent plus exister - la recherche dans la boîte de dialogue des options peut aider.
En ce moment pour un projet ASPNET Core j'ai trouvé this , et l'activer semble aider:
Supprimer l'optimisation JIT à la charge du module (géré uniquement): désactive l'optimisation JIT du code managé lorsqu'un module est chargé et que JIT est compilé pendant que le débogueur est connecté. La désactivation de l'optimisation peut faciliter le débogage de certains problèmes, mais au détriment des performances. Si vous utilisez Just My Code, la suppression de l'optimisation JIT peut faire apparaître du code non utilisateur comme code utilisateur ("Mon code"). Pour plus d'informations, voir Optimisation et débogage JIT.
Si cela ne semble pas aider, je suggère de l'éteindre à nouveau.
J'ai fait face à cela pour un projet spécifique et la raison en est Costura.Fody (intègre toutes les DLL dans l'assembly en cours d'exécution).
Dans ce cas, vous pouvez désactiver Costura.Fody.
Commentez Costura de FodyWever.xml
<Weavers>
<!--<Costura />-->
</Weavers>
Désactivez la cible de référence propre (si incluse) dans * .csproj
<!--<Target Name="CleanReferenceCopyLocalPaths" AfterTargets="AfterBuild">
<Delete Files="@(ReferenceCopyLocalPaths->'$(OutDir)%
(DestinationSubDirectory)%(Filename)%(Extension)')" />
<Exec Command="DeleteEmptyDirectory.bat" />
</Target>-->