“El punto de interrupción no será golpeado actualmente. El código fuente es diferente de la versión original. “¿Qué significa esto?

Al depurar en Visual Studio, a veces agrego un punto de interrupción pero es hueco y VS dice: “El punto de interrupción no se verá afectado. El código fuente es diferente de la versión original”. Obviamente esto me impide poder depurar.

¿Qué demonios significa el mensaje? ¿Qué versión original? Si acabo de abrir la solución y no realicé ningún cambio en el código, ¿cómo puede haber una ‘versión original’?

Como dice, el “código fuente es diferente de la versión original”.

Haga clic derecho en la carpeta del proyecto dentro del explorador de soluciones y elija Clean . ¡Crea una nueva versión del proyecto y el punto de interrupción funcionará nuevamente!

Si ha desmarcado el proyecto DLL en la configuración de comstackción de depuración , ¡su nuevo código nunca se comstackrá !

Vaya a Build --> Configuration Manager ... (en VS2010) y verifique si el proyecto con el código que está tratando de depurar está marcado para la configuración de comstackción actual.

Para mí fue mientras trabajaba en un proyecto WebSite. Después de limpiar estas carpetas temporales recuperé los errores de comstackción correctos:

  • C:\Documents and Settings\%username%\AppData\Local\Temp\Temporary ASP.NET Files
  • C:\windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files

Finalmente resolví el problema cuando descubrí que un archivo de clase que había movido intencionalmente a una subcarpeta, de alguna manera reapareció en la carpeta raíz. VS estaba usando eso mientras yo estaba editando el otro.

¿Alguna vez hiciste esto?

¿Te gustaría continuar y ejecutar la última versión exitosa?

Si marcó la casilla y presionó “Sí”, se ejecutará la última versión exitosa aunque su proyecto no se haya comstackdo. Esto significa que cada vez que establezca un punto de interrupción, obtendrá ese error.

Intenta cambiar este valor:

  • Herramientas
    • Opciones
      • Proyectos y soluciones
        • Construir y ejecutar
          • En ejecución, cuando se producen errores de comstackción o despliegue: no iniciar

Ir

  • Herramientas
    • Opciones
      • Depuración
        • General

Desmarque Exigir que los archivos fuente coincidan exactamente con la versión original

Seleccione Depurar en configuraciones de solución , en lugar de liberar

captura de pantalla del menú

Cerrar Visual Studio y volver a abrir la solución puede solucionar el problema, es decir, es un error dentro del propio IDE (estoy ejecutando VS2010).

Si tiene más de una instancia de Visual Studio en ejecución, solo necesita cerrar la instancia que ejecuta la solución con el problema.

Preste atención a la ventana “Salida” en VS. Le dirá qué assemblys se cargan y cuándo. Puede ver que se está cargando una versión anterior de su ensamblaje en algún lugar de la carpeta.

Por ejemplo, si tiene varios ensamblados y actualmente está intentando dividir uno de los ensamblajes de soporte, el CLR manejará la resolución del ensamblado, que puede cargar otro archivo de ensamblaje distinto del que ha mencionado en el proyecto.

Una nueva forma de obtener este problema ha aparecido desde Visual Studio 2017 15.3.1 hasta 15.3.5. Si está utilizando EditorConfig , la opción charset=utf8 causa estos síntomas. El equipo VS ha reproducido esto y dice que están trabajando en ello .

Entonces, una solución es comentar su línea charset=utf8 en el archivo .editorconfig.

Editar: Esto se debe corregir a partir de VS 15.5.

Esto sucede a menudo también si está utilizando un archivo de referencias a binarios (en lugar de referencias de proyecto a código en su proyecto), y el binario comstackdo al que hace referencia no está sincronizado con el código fuente correspondiente en su máquina. Esto puede ocurrir porque descargó una nueva versión del binario del control de origen sin el nuevo código fuente que lo acompaña, o tiene algunas versiones del binario en su máquina y hace referencia a una copia anterior, etc. Si esto es cierto el problema, es una buena razón para usar referencias de proyectos tanto como sea práctico.

Hay un entorno casi imperceptible que me solucionó este problema. Si hay un archivo fuente particular en el que el punto de interrupción no está llegando, se puede enumerar en

  • Explorador de la solución
    • haga clic derecho en la solución
      • Propiedades
        • Propiedades comunes
          • Archivos de origen de depuración
            • “No busques estos archivos fuente”.

Por alguna razón desconocida para mí, VS 2013 decidió colocar allí un archivo fuente y, posteriormente, ya no pude acceder al punto de interrupción en ese archivo. Este puede ser el culpable de que “el código fuente es diferente de la versión original”.

Esto puede suceder cuando la hora del sistema cambia durante la depuración o entre las sesiones de depuración, ya sea de forma programática, manual o mediante un progtwig externo.

Para mí, ninguno de los elementos resolvió el problema. Acabo de agregar una nueva línea de código dentro de esa función, algo así como:

 int a=0; 

Al agregar eso, creo que activé Visual Studio para agregar esta función a la versión original

Puede obtener este mensaje cuando está utilizando un activador y el conjunto al que ha configurado el punto de interrupción no se ha cargado aún.

El punto de interrupción se resolverá una vez que el activador cargue el ensamblaje (suponiendo que los símbolos de ensamblaje y depuración estén actualizados). Un buen lugar para mirar es la ventana de módulos en el menú de depuración. Allí debe buscar el ensamblaje al que pertenece su archivo también. Primero verifique que el ensamblaje esté cargado. Entonces, ¿de dónde está cargado? Entonces, es el archivo de símbolos cargado. De nuevo, ¿de dónde se carga el archivo de símbolos? Por último, compruebe las versiones de ambos.

Me encontré con esto también. Las condiciones que causaron mi problema:

  • Estoy ejecutando una instancia completa de IIS7 localmente
  • Estoy versionando mi software en proyectos separados

Lo había causado al abrir una versión anterior (se le solicitó a VS que preguntara si quería apuntar a esta instancia en la depuración de IIS, respondí “Sí”) y luego abrí la versión actual (respondiendo de nuevo al indicador IIS con un “Sí”) ), luego intenta depurar en la versión anterior.

Para resolverlo, simplemente cerré y volví a abrir la versión anterior y la prevista, una vez más asegurándola como la fuente de depuración.

Esto también ocurre cuando se depura un proyecto de C ++ que carga un módulo que se ha implementado con algún lenguaje de CRL (C ++ administrado, C #, etc.). En esta situación, el mensaje de error es engañoso.

La solución es colocar la propiedad de configuración de compatibilidad de Common Language Runtime (CLR) en el proyecto de inicio y recomstackr eso.

El problema es que su información de depuración no está sincronizada con su ensamblado. La solución es simple:

  1. Ve a tu carpeta bin
  2. Eliminar los archivos .pdb
  3. Reconstruir

Debe hacer el truco!

(Lo extraño es que una reconstrucción sin tirar los archivos .pdb no siempre funciona. Puedo ver la fecha de modificación siendo actualizada, pero aún en algún lugar de la cadena (depurador VS2013, IIS, caché de ensamblaje) este cambio no se detecta )

Para mí, la solución estaba oculta en la Advanced Build Settings de Advanced Build Settings de las propiedades del proyecto: enter image description here

Por una razón desconocida, se configuró en none : establecerlo en su full provocó que se golpearan los puntos de interrupción.

Para llegar a este cuadro de diálogo, abra las propiedades del proyecto, luego vaya a Build , luego seleccione el botón Advanced... en la parte inferior de la página.

ir:

Herramientas> Opciones> Depuración> General> desmarcadaRequerir que los archivos fuente coincidan exactamente con la versión original

En mi caso, me estaba conectando a un proceso en ejecución en VS 2012. Al realizar la conexión, tiene la opción de depurar en varios modos (nativo, script, silverlight, managed 2.0, managed 4.0, etc.). Por defecto, el depurador selecciona el modo automáticamente. Sin embargo, Automatic no siempre toma la decisión correcta. Si su proceso contiene múltiples tipos de código, asegúrese de que el depurador esté utilizando el correcto.

En mi caso, estaba desarrollando una aplicación para Windows CE, que probaba contra un emulador. El problema era que el ejecutable no se desplegó en el emulador, por lo que el .pdb (en el entorno de desarrollo) no estaba sincronizado con el .exe (en el emulador), porque el nuevo .exe nunca se copió en el emulador. Tuve que eliminar el .exe en el emulador para forzar una nueva implementación. Entonces funcionó.

Pruebe a deshabilitar y volver a establecer el punto de interrupción mientras se ejecuta en modo de depuración en lugar de hacerlo antes de iniciar el modo de depuración.

Lo que funcionó para mí fue cambiar la plataforma de solución de x86 a cualquier CPU. Después de cambiar a Cualquiera, configuré una dirección de detención, ejecuté el sitio web, abrí la página, hice clic en el botón y se detuvo. Cerré el sitio, volví a cambiar a x86 y realicé la misma secuencia con éxito.

En Windows 7, Visual Studio Express 2010, si activó la opción Usar modo de compatibilidad para Windows XP SP3 , este error puede ocurrir.

Desactivé la opción y funcionó perfecto de nuevo. Haga clic derecho en el acceso directo a VS o al ejecutable, seleccione propiedades y luego compatibilidad .

Primero lo intenté desde la línea de comando;

eliminar archivos temporales de la línea de comando funcionó.

C: \ Windows \ Microsoft.NET \ Framework64 \ v4.0.30319 \ Archivos temporales ASP.NET> raíz de rd / s

Cuando desactivo la opción “Habilitar solo mi código” en Herramientas -> Opciones -> Depuración -> General

El problema se resolvió para mí. Es una aplicación WCF, estaba intentando depurar una página de ashx. http://blogs.msdn.com/b/zainnab/archive/2010/10/25/understanding-just-my-code.aspx

Si tiene más de un proyecto en su solución , asegúrese de que el proyecto correcto esté configurado como StartUp Project . Para establecer un proyecto en particular como el Proyecto de inicio de su solución, haga clic con el botón derecho en el proyecto, seleccione Set As StartUp Project como proyecto de inicio.

Después de establecer correctamente mi Proyecto de Inicio, el hilo alcanzó el punto de corte deseado.

Experimenté esto en una versión de 32 bits en vs2017.

Exactamente ninguna de las soluciones funcionó para mí. Reanudé, borré los archivos IDE, limpié la solución incorporada, saqué de git repo y reconstruí la solución en vano.

Estaba generando una dependencia de 64 bits de Nuget y, tan pronto como utilicé el ensamblado, las fonts ya no se integraban en el ejecutable final y, en su lugar, se construían las fonts de IDE en caché.

Eliminé la configuración nuget, eliminé el ensamblado al que se hace referencia, descargué el código fuente, compilé log4net manualmente, lo firmé, lo agregué a una carpeta en mi proyecto, agregué una referencia al mismo y pude depurar de nuevo.

Esto fue un dolor, espero que aparezca en la lista de respuestas para que todos lo vean.

Editar: No se produjo ningún error durante la comstackción a pesar de tener activada la opción “solicitar error de comstackción” en la configuración de IDE.

Si su proceso depurado contiene múltiples appdomains y el ensamblado se carga en ambos, y uno de ellos está cargando una copia antigua (generalmente algo cargado dinámicamente como un complemento), el punto de interrupción puede aparecer sólido, pero el hilo que debería llegar al punto de interrupción está en el appdomain con el antiguo ensamblado, y nunca golpea. Puede ver qué ensamblajes están cargados y su ruta en la ventana del módulo.

Verifique si tiene más de un archivo con ese nombre en la solución.

Tuve esto en un proyecto que tomé de otra persona. La lista de puntos de interrupción estaba llena de números de línea en Controller.cs, algunos activos y otros no. Encontré esta pregunta e intenté algunas opciones, pero cuando hice doble clic en los puntos de ruptura, me llevaron a diferentes proyectos dentro de la solución. Debido a que los archivos se llamaron igual, parecen ser los mismos, pero no lo son. La respuesta es, por supuesto, ignorar la advertencia, ya que se activarán si puedes cargar ese otro archivo.

Resultó estar en Visual Studio 2017 después de agregar archivos existentes al proyecto. Esto funcionó para mí:

  1. cerrar la solución,
  2. vaya a SolutionFolder\.vs\SolutionName\v15\sqlite3 y elimine storage.ide
  3. abre la solución nuevamente