c# - samples - "No se puede evaluar la expresión porque el código del método actual está optimizado" en Visual Studio 2010

visual studio c++ (19)

Estoy usando Visual Studio 2010 en modo de depuración y tengo "optimización de código" sin marcar. No puedo mirar rápidamente (o pasar el mouse sobre) cualquier variable en el depurador. Me sale este error "No se puede evaluar la expresión porque el código del método actual está optimizado".

Incluso una línea como: int i = -3, haciendo una observación rápida en i, obtengo "No se puede obtener el valor local o argumento ''i'' ya que no está disponible en este puntero de instrucción, posiblemente porque se ha optimizado".

Este link referencia en una pregunta similar no parece aplicarse.

¿Hay algún ajuste que me falta?

Además de @Kragen mencionado, si está depurando un proyecto web

cierre el estudio visual e intente eliminar los archivos temporales en C: / Windows / Microsoft.NET / Framework / v2.0.50727 / Archivos temporales ASP.NET

Cuando vea el mensaje " No se puede evaluar la expresión porque el código del método actual está optimizado " después de emitir una instrucción Debugger.Break() , asegúrese de presionar F10 para pasar a la siguiente instrucción.

Una vez que pasó a la siguiente instrucción, y suponiendo que está ejecutando una compilación de depuración, este mensaje debería desaparecer.

El comentario de vickramds arriba, refiriéndose a torulflundgren.blogspot.com.au/2010/03/… , lo hizo por mí. Comprobé todo: borré todos los archivos dll, pdb de las carpetas locales, limpié, reconstruí, borré todas las carpetas de archivos temporales ASP.NET, me aseguré de que los indicadores TRACE / DEBUG se configuraron, verifiqué las rutas DLL, etc.

Para ponerlo abajo para que no se pierda, para el proyecto (s) afectado (s):

Project Properties -> Build -> Advanced -> Debug Info: Full.

Desea comprobar que tiene la configuración de depuración seleccionada antes de hacer esto, a menos que, por supuesto, tenga la intención de lo contrario.

Empecé a recibir este mensaje cuando migré a Visual Studio 2017. Ninguna de las ideas en esta página que probé funcionaron para mí. En otra publicación encontré esta sugerencia y funcionó: eliminar:

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

... desde su archivo AssemblyInfo.

En VS2013, vaya a: Herramientas -> Opciones -> Depuración -> General y habilite ''Usar modo de compatibilidad administrada''. Esto desactiva el nuevo comportamiento de evaluación de funciones.

En cuanto al problema con la propiedad "Optimizar código" está DESCALIFICADO pero el código sigue compilando como optimizado: Lo que finalmente me ayudó después de probar todo fue marcar la casilla "Habilitar depuración del código no administrado" en la misma página de configuración (Propiedades del proyecto - Depurar). No se relaciona directamente con la optimización del código, pero con esto habilitado, VS ya no optimiza mi biblioteca y puedo depurar.

Intenta ejecutar en modo de depuración. Si estás ejecutando en modo de lanzamiento, recibirás este mensaje.

Me doy cuenta de que esta es una respuesta posterior, pero encontré otra referencia a una forma de abordar este problema que podría ayudar a otros en el futuro. Esta página web describe la configuración de una variable de entorno (COMPLUS_ZapDisable = 1) que impide la optimización, ¡al menos lo hizo para mí! (No olvides la segunda parte de deshabilitar el proceso de alojamiento de Visual Studio.) En mi caso, esto podría haber sido aún más relevante porque estaba depurando una DLL externa a través de un servidor de símbolos, pero no estoy seguro.

Mi situación no estaba cubierta por ninguna de las respuestas anteriores. Encontré lo siguiente: artículo de MSDN sobre enhebrado que explica que cuando se bloquea en algunas operaciones primitivas de subprocesamiento nativo, el depurador no puede acceder a los datos. Como ejemplo, cuando un hilo se encuentra en Task.Wait (), aparece esto.

Mientras el proyecto estaba en modo de depuración, la solución no lo era. Cuando lo cambié, funcionó.

Otra cosa que puede hacer es crear un archivo con el mismo nombre que el dll que está optimizado pero con extensión ini y agregarle lo siguiente:

[.NET Framework Debugging Control]
GenerateTrackingInfo = 1
AllowOptimize = 0

Esto le dirá al JIT que no optimice sus variables.

Tenga en cuenta que todavía necesita el pdb, por lo que terminará con algo como esto: yourDll.dll yourDll.pdb yourDll.ini

Esto funciona especialmente bien en escenarios cuando no tiene acceso para volver a generar los dlls con la opción de depuración.

http://www.hanselman.com/blog/DebugVsReleaseTheBestOfBothWorlds.aspx

Parece que está depurando una versión optimizada / versión, a pesar de tener la caja optimizada sin marcar. Las cosas que puedes probar son:

Realice una reconstrucción completa de su archivo de solución (haga clic con el botón derecho en la solución y seleccione Reconstruir todo)
Mientras realiza la depuración, abra la ventana de módulos (Depurar -> Windows -> Módulos) y encuentre su ensamblaje en la lista de módulos cargados. Compruebe que la ruta de acceso indicada en su conjunto cargado es lo que espera que sea, y que la marca de tiempo modificada del archivo indica que el conjunto fue realmente reconstruido.
La ventana de módulos también debe decirle si el módulo cargado está optimizado o no, asegúrese de que la ventana de módulos indique que no está optimizado.

Si no puede ver el elemento del menú Módulos en el menú Depuración -> Windows, entonces puede necesitar agregarlo en el menú "Personalizar ...".

Si intenta depurar un proyecto ASP.NET, asegúrese de que el menú desplegable Propiedades> Web> Servers del proyecto esté configurado en "IIS Express" (además de verificar todo lo demás aquí).

Tuve el mismo problema al depurar una biblioteca de clase de una aplicación web de prueba. Estaba haciendo referencia a la versión de lanzamiento en el banco de pruebas y que estaba configurado para ser optimizado en las propiedades de la biblioteca de clase.

Al quitar la marca de la casilla de verificación optimizar el código para la versión de lanzamiento en las propiedades de la biblioteca de clase, justo mientras lo estoy escribiendo, se ha resuelto el problema.

Tuve el mismo problema en VS 2010. Limpié y reconstruí la solución y funcionó.

Tuve el mismo problema en VS2008. En mi caso, se resolvió mediante la reconstrucción de la solución.

Tuve este problema con un proyecto de F # que había estado aquí y allá entre Visual Studio y MonoDevelop, quizás originado en el último (se me olvida). En VS, la casilla de optimización no estaba marcada, pero la optimización ciertamente parecía estar ocurriendo en lo que respecta al depurador.

Después de comparar el XML del archivo del proyecto con el de uno sano, el problema era obvio: el proyecto saludable tenía una línea explícita <optimize>false</optimize> , mientras que el malo lo echaba de menos por completo. VS obviamente deducía de su ausencia que la optimización estaba deshabilitada, mientras que el compilador estaba haciendo lo contrario.

La solución fue agregar esta propiedad al archivo del proyecto y volver a cargarla.

Tuve este problema cuando estaba usando VS 2010. Mi configuración de solución tiene (Debug) seleccionada. Resolví esto desmarcando la propiedad Optimizar código debajo de las propiedades del proyecto. Proyecto (clic derecho) => Propiedades => Construir (pestaña) => desmarcar código de Optimizar

Yo tuve el mismo problema. Pero en mi caso, el atributo Debuggable estaba codificado en el archivo AssemblyInfo.cs de mi proyecto y, por lo tanto, no (sobre) escrito por compilación. Funcionó después de eliminar la línea que especifica el atributo Debuggable.