visual-studio - temas - visual studio 2017 themes

Los puntos de interrupción de Visual Studio se rompen en el archivo de origen incorrecto(o en varios archivos simultáneamente) si varios archivos tienen el mismo nombre (11)

En un proyecto de equipo en el que estoy trabajando, establecer un punto de interrupción en un archivo (digamos IdeasController.cs ) conducirá a un comportamiento de depurador errático si hay otro archivo con el mismo nombre en la solución. He reproducido el problema en varias estaciones de trabajo de los desarrolladores.

Ejemplo

Establecí un punto de interrupción en IdeasController.cs en nuestra API web:

Existe otro archivo llamado IdeasController.cs en nuestro proyecto web separado MVC 4. En la captura de pantalla siguiente, el depurador muestra el código fuente Api->IdeasController , pero el resaltado de línea coincide con la estructura del código de Web->IdeasController . El punto de interrupción está duplicado, con uno de ellos en el medio de un bloque de comentarios.

La ventana Breakpoint muestra el punto de interrupción en ambos archivos simultáneamente:

En algunas estaciones de trabajo, el depurador pasa por las líneas correctas (independientemente de la línea resaltada); en otros pasa alegremente por las líneas irrelevantes (incluidos los comentarios y el espacio en blanco). Supongo que esto depende de qué archivo fuente elija mostrar.

Lo que he intentado

He rastreado Internet. Este tipo de problema parece ocurrir cuando hay una falta de coincidencia entre el archivo de depuración ( *.pdb ), el archivo de origen y el código compilado. Hay muchas causas posibles: nombres de archivos duplicados (que pueden confundir el depurador ^[5] ), archivos de compilación de proyectos obsoletos, caché de solución no válida o configuración de compilación incorrecta.

Estas son las soluciones que he encontrado y probado:

Comprobé mi configuración de compilación.
1. Se aseguró de que el proyecto no esté construido en modo de lanzamiento.
2. Nos aseguramos de que no tengamos habilitada la optimización de código .
3. Se aseguró de que el módulo de depuración del proyecto se haya cargado correctamente. (Comencé a depurar el proyecto y revisé Debug > Windows > Modules . Ambos ensamblados están listados, no optimizados, y tienen el estado de símbolo de "Símbolos cargados").
Restablezca los metadatos de depuración y el caché de Visual Studio.
1. Cerré Visual Studio y borré el archivo de caché de solución ( *.suo ). ^[1]
2. Se eliminó el resultado de compilación de cada proyecto (las carpetas bin y obj ). (Para referencia futura: abra la carpeta de la solución en Windows Explorer y escriba esto en el cuadro de búsqueda: " type:folder AND (name:=bin OR name:=obj) ".
3. Se eliminó la carpeta del caché de ensamblaje ( C:/Documents and Settings/<user>/Local Settings/Application Data/dl3 ). ^{[2] [3]}

Ninguno de estos tuvo ningún efecto. Puedo cambiar el nombre de uno de los archivos (sin cambiar el nombre de la clase) para solucionar temporalmente el problema, pero eso está lejos de ser ideal.

Dónde estoy ahora

Página 14 de mi última búsqueda de Google. Las sugerencias serían muy apreciadas. :)

Acabo de hacer una copia de seguridad, borré el archivo y luego volví a agregarlo al proyecto, que resolvió el problema. Solo quiero que lo haya hecho antes de pasar por la lista mencionada anteriormente :)

Aunque cambiar el nombre de uno de los archivos funcionará, encontré que la solución más simple es desactivar temporalmente la carga automática de símbolos para el "otro" conjunto.

Inicie el depurador y continúe hasta llegar al punto de interrupción erróneo.
Encuentre dónde depurador realmente estableció el punto de interrupción usando la ventana Pila de llamadas :
1. Haga clic derecho en la fila con la flecha amarilla y habilite Mostrar nombres de módulo . (La fila también debe tener el símbolo rojo de punto de interrupción).
2. El nombre del ensamblado ahora es visible en esa fila.
Encuentre ese ensamblaje en la ventana Módulos ( Depurar> Windows> Módulos ).
Haga clic con el botón derecho en el ensamblaje y desactive Cargar automáticamente .
Detener el depurador.
Comience a depurar de nuevo.

Al hacer esto, impide que el depurador de Visual Studio correlacione el punto de interrupción con el ensamblaje incorrecto. Luego cargará primero los símbolos del otro ensamblaje [presumiblemente] correcto, por lo tanto, mapeará el punto de ruptura al ensamblaje correcto.

¿Por qué pasó esto?

Esto parece ocurrir cuando dos archivos de símbolos diferentes (archivos PDB), para dos ensamblajes diferentes, hacen referencia a un archivo fuente con el mismo nombre. Aunque los archivos de origen son completamente diferentes, el depurador de Visual Studio parece confundirse.

Por ejemplo, imagine que hay dos archivos diferentes con el nombre IdeasController.cs . El primero se compila en el ensamblado Api.dll y el segundo se compila en el ensamblado Web.dll .

Cuando el depurador carga símbolos, Api.pdb cargará Api.pdb o Web.pdb . Digamos que carga Api.pdb primero. Entonces, incluso si establece un punto de interrupción en Web/IdeasController.cs , encontrará una coincidencia para IdeasController.cs en Api.pdb . A continuación, asigna el código de Web/IdeasController.cs a Api.dll . Esto no se correlacionará correctamente, por supuesto, y entonces verá todo tipo de problemas extraños mientras depura.

Elimine todos los archivos .pdb del proyecto donde el punto de interrupción está golpeando incorrectamente. Esto resolverá el problema.

Estaba abordando este problema en Visual Studio 2015.

Tenía una subcarpeta con un archivo DLL que quería guardar como Versión1. Parece incluso después de eliminar la referencia a esa DLL, y luego agregar una referencia a otro estudio de proyecto sacó la referencia existente y fue al archivo fuente incorrecto. Quité esa DLL en la subcarpeta, entonces Studio obtuvo la fuente correcta.

Encontré un enlace útil en [MSDN que muestra cómo borrar los archivos fuente asociados anteriores en el estudio en este enlace] [1].

Resumen:

En el Explorador de soluciones, haga clic con el botón derecho en el nombre de la solución (por ejemplo: Solución ''Aplicación de prueba'') y seleccione Propiedades. Aparecerá el cuadro de diálogo Páginas de propiedades de la solución.
En Propiedades comunes, seleccione Archivos de origen de depuración
En la búsqueda de estas rutas para los archivos de código fuente (Visual Studio .NET 2003) / Directorios que contienen el código fuente (Visual Studio 2005), agregue, elimine y / o reordene los directorios como desee
Haga clic en el botón Aceptar

Estoy tan contento de haber encontrado esta publicación, ¡pensé que era el único y me estaba volviendo loco! Estoy teniendo el mismo problema en VS2012 con VB.Net y he intentado todo lo que mencionó el OP.

El nombre único de los archivos parece ser la única solución al 100% que he encontrado. Desactivar todos los puntos de interrupción hasta que la aplicación se haya cargado y volver a habilitar los puntos de interrupción que necesita funciona la mayoría del tiempo. Los puntos de interrupción en las funciones de Lambda aún pueden darle problemas.

Lo que funcionó para mí (VS2017) fue deshabilitar esta opción en Tools --> Options... --> Debugging --> General : " Requerir que los archivos de fuentes coincidan exactamente con la versión original ", que está habilitado por defecto pero lo tuve encendido.

Sin embargo, eso no fue suficiente, también tuve que eliminar manualmente las carpetas obj e bin para todos los proyectos en solución.

Me pasó a mí (en VS 2008 ) tener dos puntos de corte para niños con la misma dirección de memoria y el mismo archivo asociado . Esos puntos de interrupción se generaron en un momento determinado durante la ejecución del proceso.

Noté que tenía archivos .dll duplicados en las carpetas de mi proyecto y resolví eliminar el archivo .dll duplicado , mientras que solo mantenía un .dll por nombre en la estructura de la carpeta de depuración. (Como ejemplo en mi caso, tenía /bin/Example.dll y /bin/Plug-in/Example.dll ambos presentes en mi estructura de carpetas de depuración).

Si no existen mejores alternativas, puede poner el punto de interrupción en el código:

System.Diagnostics.Debugger.Break();

Solo no olvides quitarlo después ...

Simplemente tuve exactamente el mismo problema. Lo que me solucionó fue eliminar los archivos .suo que pertenecen a la solución que contenía el proyecto / archivo fuente afectado.

También borré mi memoria simbólica local, pero no creo que tenga nada que ver con eso.

(Mi solución contiene varios proyectos, un archivo (DataAdapter.cs) en un proyecto se vio afectado por esto (VisualStudio puso mis puntos de interrupción en el pdb que pertenece a System.Data.DataAdapter). Abrí el archivo .csproj directamente y pude corregirlo correctamente. establecer el punto de inflexión.)

También puede intentar Limpiar y Reconstruir (no Construir) todos los proyectos.

Tuve el mismo problema hoy. Pude rastrearlo hasta el hecho de que había olvidado establecer el destino de la plataforma en x86 durante la depuración. Lamentablemente, los demás (x64 / Any CPU) pueden ser problemáticos durante la depuración. Al menos a VS 2008 no le gustan. Supongo que esta es una razón más para mantenerse alejado.

Alguna especulación ... Creo que el depurador (mientras se ejecuta una aplicación de 64 bits) de alguna manera "roba" puntos de corte lejos de un archivo en ciertos casos. Para mí fue porque primero se cargó otro ensamblado que tenía el mismo nombre de archivo. Pude evitar el problema, incluso en el modo de 64 bits, si primero cargué manualmente el ensamblaje con mis puntos de interrupción: Assembly.Load ("MyAssemblyWithBreakpoints");

Espero que esto (mi primera contribución de ) ayude.