c# - una - la aplicacion se encuentra en modo de interrupcion visual studio 2017

Los puntos de ruptura VS2012 no reciben ningún golpe

Question

Tengo una clase que se ve así:

public class MyService
{
private MyService(){}
public static string GetStuff()
{
var stuffDid = new MyService();
return stuffDid.DoStuff();
}
private string DoStuff()
{
//do stuff
}
//other private helpers
}

Obviamente, dejé mucho, pero ese es el caparazón general.

Ahora, tengo una prueba de unidad:

[Test]
public void MyTest()
{
var results = MyService.GetStuff();
}

Establecí puntos de interrupción en mi prueba unitaria, y puedo ver que los results tienen datos. Sin embargo, configuré puntos de interrupción literalmente en todo MyService y no se golpea nada a menos que los coloque con una llave. Lo cual no puedo entender ya que los results tienen datos, mis declaraciones de return en MyService deberían recibir un golpe, ¿no?

¿Me estoy perdiendo de algo? ¿Olvidé por completo las reglas más básicas de algo? ¿Cómo es que nada en MyService es golpeado? Y si lo paso manualmente con F11 , simplemente da vueltas y ni siquiera pasa a través de cada línea como era de esperar. Además, cuando paso de forma manual, tiendo a pulsar cierto código después de que debería haberlo activado originalmente. Y cualquier instrucción de switch parece predeterminar a cualquiera que sea la primera opción, incluso si el valor que se está intercambiando debe ingresar CLARAMENTE en un case diferente.

Incluso he intentado hacer public constructor de MyService y eliminar todos static métodos static , y todavía no funciona.

Editar: Mis pruebas y el código ''Core'' están en la misma solución, pero diferentes proyectos ( Test y Core , respectivamente). Otras pruebas no tienen un problema al alcanzar puntos de Core en Core , solo esto en una prueba en particular (la única prueba que está probando MyService .

Editar 2:

He borrado mis archivos PDB y la solución limpiada. Aún nada.

Answer 1

1. Limpia la solución y reconstruye y también realiza el proyecto de inicio.

2. ¿Puede echar un vistazo rápido al BUILD> Configuration Manager, solo para asegurarse de cuáles son las propiedades de configuración configuradas? Si se trata de desarrollo, es posible que deba ajustar las Propiedades del proyecto -> haga clic en configuración avanzada -> cambie la información de depuración a ''completa'' en [pestaña de salida].

3. también puedes seguir el paso dos incluso si no es el modo de desarrollo

Answer 2

¿Tal vez su proyecto de Test está haciendo referencia a un binario Core más antiguo, en lugar del proyecto Core (código fuente)?

Intente volver a agregar la referencia en su proyecto de Prueba:

Vaya a su proyecto de Test y elimine la referencia al proyecto Core .

Ahora seleccione la carpeta Referencias y haga clic con el botón derecho y seleccione la opción del menú para agregar una nueva referencia. Cuando esté en el cuadro de diálogo Administrador de referencias, asegúrese de seleccionar Solution y luego Projects a la izquierda. Luego, en el medio del cuadro de diálogo Administrador de referencia, seleccione (marque) el proyecto Core .

Intenta depurar de nuevo y ve si eso ayuda.

Answer 3

Algunas cosas más para probar:

• Compruebe si los símbolos cargados coinciden con el ejecutable depurado:
  Abra un símbolo del sistema de VS y cd al directorio donde reside el ejecutable que depura. A continuación, dumpbin /PDBPATH:VERBOSE MyServiceExecutable.exe un dumpbin /PDBPATH:VERBOSE MyServiceExecutable.exe y escanee el resultado de "Incompatibilidad de edad de PDB" (Ref: http://msdn.microsoft.com/en-us/library/44wx0fef.aspx )

• No estoy seguro acerca de VS 2012, pero las versiones anteriores de VS tenían un error donde se mostraría el archivo fuente incorrecto, siempre que tenga dos archivos fuente en su proyecto que tengan el mismo nombre, incluso cuando estén ubicados en carpetas diferentes. Entonces, si su proyecto contiene otro archivo fuente con el mismo nombre, vea si el cambio de nombre de uno de ellos ayuda. ( Actualización: parece que VS 2012 también se ve afectado ).

Answer 4

Algunas ideas.

1. Asegúrate de que sea una compilación de depuración y no de lanzamiento
2. Desactive las optimizaciones en las propiedades de su proyecto si están activadas
3. Intente insertar Debugger.Break() en su código en lugar de un punto de interrupción en VS
4. Asegúrese de que los puntos de interrupción estén habilitados (barra de herramientas Depurar-> Windows-> Puntos de corte), y el símbolo de punto de interrupción debe ser sólido
5. Ejecute su aplicación. Ventana Load Debug-> Window-> Modules. Verifique su conjunto para ver si hay símbolos cargados. Puede dar un mensaje de estado relevante si no.

¿Has estado ajustando la fecha en tu computadora para nada? Esto realmente puede arruinar un proceso de construcción. Si es así, borre todas las carpetas obj / bin de forma manual y vuelva a compilar.

Answer 5

Debes hacer DoStuff estático.

private static string DoStuff()
{
//do stuff
}

Answer 6

En Pruebas unitarias, no estaba llegando a puntos de interrupción, y me di cuenta de que estaba ejecutando la prueba y no depurando la prueba. En la parte superior del Explorador de prueba están las opciones "Ejecutar todo", "Error de ejecución", "Ejecutado", etc. Cuando ejecuta una prueba, los puntos de corte no se golpean. Para depurar una prueba, en el Explorador de pruebas, haga clic derecho en la prueba o grupo de pruebas y seleccione Depurar pruebas seleccionadas.

Answer 7

Este es bastante oscuro:

Asegúrese de que no tiene dos directorios virtuales con diferentes grupos de aplicaciones que apuntan a la misma ubicación física en su disco duro. Durante el desarrollo, esto es algo que a veces puede suceder para probar, o por error.

No estoy 100% claro en los aspectos técnicos, pero tenía dos AppPools y dos directorios virtuales y ningún punto de interrupción fue golpeado porque supongo que la ruta física se mapeó de alguna manera en IIS / Visual Studio para el otro apppool y no el que realmente era ejecutando

Answer 8

Esto suena como que los archivos pdb no se actualizan en su entorno limitado de pruebas.

1) Asegúrese de estar en modo de depuración.

2) ¿Puedes probar e incluir un elemento de implementación para los archivos pdb explícitamente?

• Usted dijo que puede adjuntar un punto de depuración en su proyecto de prueba.
• Una vez que haya tocado el punto de depuración en su proyecto de prueba, verifique que los archivos pdb con la última marca de tiempo estén presentes en la carpeta de salida de su sandbox.

3) Si 1 y 2 fallan, he encontrado que a veces el estudio visual requiere un reinicio :)

Answer 9

Me encontré con un problema similar. Resultó que para mí fue una mala migración de VS2010 a VS2012 con el archivo *.testrunconfig . Eliminé el anterior y configuré uno nuevo para resolver el problema.

Answer 10

Para depurar paso a paso, debe hacer dos cosas. Primero debe establecer el punto de interrupción, luego debe conectar el depurador al proceso que ejecuta su código. Si está ejecutando IIS Express y tiene una máquina de 64 bits, entonces necesita adjuntar iisexpress.exe que ejecuta su código. Si presiona CTRL + ALT + P, irá a la ventana adjuntar al proceso. Después de adjuntar, el punto de ruptura debe ser golpeado si el código coincide.

Answer 11

Podría intentar agregar un Thread.Sleep(5000) en el método GetStuff y usar Adjuntar al proceso

Visual Studio> Herramientas> Adjuntar para procesar y ver si se golpean los puntos de corte debajo de esa línea.

Answer 12

Podría ser porque solo estás depurando 1 proyecto, no tanto Test como Core

Puede configurar VS para depurar varios proyectos a la vez, puede hacer esto haciendo right-click your solution > Properties > Common Properties > StartUp Project

Aquí puede establecer "Proyectos de inicio múltiple"

Simplemente configure Core y Test para comenzar. Esto puede resolver su problema.

Answer 13

Primero intente reconstruir su proyecto haciendo clic con el botón derecho del mouse sobre el proyecto> Reconstruir Si eso no funciona, intente limpiar el proyecto (haga clic con el botón derecho del mouse en el proyecto> limpiar)

Si eso no funcionó, comprueba esto:

Right mouse click your project
select [Properties]
select the [Build] tab
make sure [Define DEBUG constant] and [Define TRACE constant] are checked
Click the [Advanced] button at the bottom of the Build tabpage
Make sure that [Debug Info:] is set to [full]
Click [OK] and rebuild the project ;-)

¡Espero que eso te funcione! (el paso 6 genera los archivos .pdb, estos son los símbolos de depuración)

Answer 14

Recientemente tuve el mismo problema y estaba golpeando mi cabeza contra la pared.

La respuesta resultó ser bastante tonta: de alguna manera mi proyecto de prueba se desincronizó con el proyecto principal de la biblioteca. Estaba construyendo las versiones de depuración de la prueba y la biblioteca, pero el proyecto de prueba copió la biblioteca de la carpeta bin/Release . Reculté la referencia del proyecto y todo se solucionó.

PD. Incluso fue más criazier: el depurador entró en una función de biblioteca, pero de alguna manera omitió una línea en el medio.

Answer 15

Resulta que esto estaba relacionado con la cobertura del código.

Apagarlo solucionó el problema.

Puede averiguar cómo deshabilitar la cobertura del código siguiendo el siguiente enlace

Deshabilitar cobertura de código

Answer 16

Sé por experiencia que Visual Studio no tiene un método claro de depuración de servicios, especialmente servicios de Windows. Intente agregar un código a GetStuff para imprimir en un archivo de texto, de esta manera al menos usted sabe que el código está siendo golpeado. Cuando creo servicios a menudo recurro a este método para probar.

Answer 17

Si está en modo de lanzamiento, cámbielo a modo de depuración.

Answer 18

Silly me the Test Project no estaba listo para ser construido:

Answer 19

Solo asegúrate de construir tu ensamblaje con los símbolos del depurador.

Esta opción debe llenarse con "completo":

Haga clic derecho en su proyecto que contiene su archivo de código con los puntos de quiebre que no reciben ningún golpe. Elija "Propiedades".

Después de que se hayan abierto las propiedades del proyecto, elija la pestaña "Crear". Tenga cuidado con el "Avanzado ..." - Botón en la parte inferior de la página de pestañas. (Dentro del "Grupo de salida")

Haga clic en este botón y seleccione "completo" para la propiedad "Depurar información". Esta debería ser una razón para que los puntos de interrupción no sean golpeados. Visual Studio usa los símbolos guardados en los archivos pdb para encontrar la posición exacta del punto de ruptura. Si estos archivos no se crean, no se golpean puntos de interrupción. Tal vez haya desactivado la creación de estos archivos para ordenar la estructura de su archivo de proyecto. Esta fue una situación en la que reconocí que necesito estos archivos.

Answer 20

Su código indica un "servicio", que podría estar ejecutándose como un proceso separado. Si ese es el caso, puede tener su ensamblaje cargado, por lo que los puntos de interrupción serían círculos rojos sólidos, pero otra copia del ensamblaje, que se ejecuta en un proceso separado, en realidad está manejando las solicitudes.

• verifique el Administrador de tareas para posibles delincuentes (procesos que pueden estar alojando su servicio). Mátalos mientras se depura para confirmar que las llamadas fallan.
• Intenta usar Debugger.Break ();
• Cree un archivo de registro de depuración, al cargar el resultado al registro, el proceso de entrada y los nombres de ensamblado. Asegúrese de que su registro sea un archivo diferente cada vez para evitar problemas de acceso asíncrono.

Answer 21

Tengo el mismo problema. Quizás mi solución te ayude a resolver tu problema. Solo en "Adjuntar al proceso" para la opción "Adjuntar a", seleccione el valor "Avtomatic: código nativo". Atentamente.

Answer 22

Tengo un escenario muy específico que resultó en el problema aparente de "Punto de inflexión no se golpeó".

Como ninguna otra respuesta aquí lo mencionó, agregaré el mío en la posibilidad de que ayude a alguien que tenga el mismo problema.

La solución, en mi caso, fue una tontería, y con tanto LINQ como utilizo, debería haberlo resuelto antes. Cuando se ejecuta un método que devuelve un IEnumerable, donde las declaraciones de retorno que figuran dentro son en realidad declaraciones de yield return , entonces ese método no se ejecutará cuando lo llame.

En realidad, se ejecutará cuando llame a otro método desde ese objeto IEnumerable, como ToList() o Count() . Solo entonces se ejecutará el método y se alcanzará el punto de interrupción.

Answer 23

Tuve que pasar esto en 1 proyecto de 25, todos en la misma solución. Los otros proyectos respetaron puntos de corte pero este no. Eliminé el proyecto de la solución (eliminar, no descargar), lo que rompió todas las referencias y luego lo volvió a agregar a la solución y funcionó.

Si eso no funciona, puede volver a crear el proyecto problemático y agregar ese nuevo proyecto a la solución.

La mejor explicación que tengo de por qué esto funcionó aparte de la pura suerte es que migramos proyectos de una versión de VS a otra muchas, muchas veces a lo largo de los años y tal vez una de esas migraciones causó este problema.

Answer 24

VS se comporta exactamente de la manera que describió (sin alcanzar los puntos de interrupción, presionando el código que no espera alcanzar al pasar) cuando usa el archivo .pdb que se generó usando el código fuente de alguna manera diferente del código que se usa al depurar . No puedo garantizar que este sea su caso, pero he observado ese comportamiento muchas veces cuando tuve que entrar en el código que se suministró como una biblioteca pregenerada que se generó contra un código anterior / diferente con los mismos nombres de archivo / símbolos.