Punto de interrupción no pudo enlazar – Visual Studio 2015

Acabo de actualizar de Visual Studio 2013 a 2015 y ahora estoy teniendo problemas con los puntos de interrupción.

Es un éxito o una falla donde los puntos de interrupción realmente funcionarán y si configuro uno mientras estoy depurando recibo el error:

El punto de interrupción no se pudo unir.

Cualquier ayuda sería apreciada. Estoy a punto de darme por vencido en 2015 y regresar.

Tuve el mismo problema pero una solución diferente. Tenga en cuenta que actualicé a VS 2015 Actualización 1 y el problema todavía está allí.

En la edición anterior de VS, la depuración inicial activaba automáticamente una comstackción en modo de depuración. Pero con VS2015 no lo hace.

Entonces, si su última comstackción estaba en modo de lanzamiento, y prueba la depuración, el punto de interrupción no funcionará.

Primero debe comstackr manualmente el modo de depuración y luego comenzar la depuración.

Yo tuve el mismo problema.

Lo resolví deshabilitando la opción “Optimizar código” en la pestaña Construir propiedades del proyecto.

Esto puede parecer trivial, pero después de muchos problemas con los mismos temas que mencionas, descubrí que mi comstackción estaba configurada para “liberar” en lugar de “depurar” cuando probé a depurar … reconstruyendo la solución para “depurar” “lo arreglé, y pude establecer puntos de interrupción de forma normal

Tuve un problema similar con los puntos de interrupción que no se podían enlazar, así como con ciertas variables locales que no se evaluaban en la ventana de Localidades. Lo que finalmente se solucionó fue habilitar la opción “Suprimir la optimización de JIT en la carga del módulo (solo gestionada)” en la pestaña Opciones-> Depurar-> General. Una vez que configuré, pude enlazar sin problemas.

Tuve este problema Ejecuté una sesión de creación de perfiles de rendimiento que modificó el archivo Web.config con la configuración del monitor de rendimiento. Esto rompió mi capacidad de detenerme en los puntos críticos. Cuando volví al Web.config original (eliminé la configuración de Performance Profiler), los puntos de interrupción comenzaron a funcionar nuevamente.

Tuve el mismo problema ayer. Usé la función “Solución limpia” y me ayudó.

Ejecuto el rendimiento en mi solución y eso se agregó a mi web.config

  

el assemblyPostProcessorType es el problema, lo eliminé y eso resolvió mi problema

la solución es desactivar la optimización del diseño.

Project Properties> Build> Advanced Compile Options> Enable Optimizations

No cambié la configuración ‘optimizar’, pero en base a otras respuestas aquí,

  1. Establecer Solution Explorer para mostrar todos los archivos para el proyecto
  2. Eliminado el bin oculto y carpetas de depuración
  3. Realizado un ‘Limpio’ en el proyecto
  4. Realizado ‘Reconstruir’ en el proyecto

Hasta ahora esto me lo ha arreglado. Parece que actualizar a VS2015 La Actualización 2 ha corrompido algunas cosas en mi sistema.

Encontré hoy los errores de punto de corte vinculante. Y he resuelto mi problema haciendo abajo.

Si todas sus configuraciones de depuración no son correctas, no puede solucionar el problema haciendo lo siguiente.

  1. Proyecto limpio
  2. Si la ruta de salida es diferente de la carpeta bin, reemplácela en la carpeta bin (esta es la regla más importante)
  3. Reconstruir

Quizás esta solución ayude a alguien.

Los puntos de interrupción VS no pueden enlazarse en métodos asíncronos.

Tenía un agente de App Dynamics instalado que causó esto. Quítelo y estará listo para partir.

Tuve el mismo problema, pero no me había dado cuenta de que “Debug” había cambiado a “Release” en la barra de herramientas de depuración (generalmente directamente debajo del menú). Así que lo configuré en “Depurar” funcionó.

La nueva Actualización para la Actualización 3 de Microsoft Visual Studio 2015 (KB3165756) me ha solucionado el problema del punto de interrupción cuando trato de inspeccionar las variables locales en el código C # incrustado en los archivos cshtml en las aplicaciones ASP.NET Core.

PASO 1, descartar lo obvio:

  • Comstackr en modo de depuración.
  • Intente limpiar la solución antes de configurar el punto de interrupción.
  • Vaya a la carpeta Depurar y elimine el archivo [Su aplicación] .pdb.
  • Luego haz una comstackción o reconstruye tu aplicación.
  • Vaya a la carpeta de depuración y confirme que tiene un nuevo archivo .pdb [Su aplicación].
  • Luego intenta establecer tu punto de quiebre.

PASO 2 Para proyectos C ++:

Verifique las siguientes propiedades del proyecto:

  • C ++ / General / Debug Information Format: Base de datos del progtwig.
  • C ++ / Optimización: Deshabilitado.
  • Generación de código / C ++ / biblioteca en tiempo de ejecución: Depuración multiproceso.
  • Enlazador / Depuración / Generar información de depuración: Sí.
  • Linker / Debugging / Generate database: $ (TargetDir) $ (TargetName) .pdb.
  • Enlazador / Archivo de manifiesto / Generar manifiesto: No.
  • Enlazador / Archivo de manifiesto / Permitir aislamiento: No.
  • Enlazador / IDL incrustado / Ignorar IDL incrustado: Sí.
  • Haz el paso 1 otra vez

    Puedes intentar agregar __debugbreak (). Esta statement debe ir en su archivo de origen donde desea romper.

PASO 2 Para proyectos de C #:

  • En las propiedades de los proyectos, se debe deshabilitar el código Build / General / Optimize.
  • En la configuración IDE Depuración / Opciones y configuración / Depuración / General Suprimir la optimización JIT en la carga del módulo (solo administrado): Habilitado
  • Haz el paso 1 otra vez

Intenta abrir tu solución en otras máquinas. Si puede vincular un punto de interrupción en una máquina diferente, esto puede significar que existe un problema con su VS o su sistema operativo.

PASO 3, asegúrese de que su VS esté actualizado:

Se han recibido informes de problemas como este en VS2013 RTM, así como en VS2015 Update 1 y Update2.

En VS, vaya a Herramientas / Extensiones y actualizaciones / Actualizaciones / Actualizaciones de productos y vea qué versión está ejecutando. Si se necesita una actualización, aparecerá allí.

PASO 4, asegúrese de que su sistema operativo esté actualizado:

Por último, si está ejecutando un sistema operativo Win 10, se ha informado de un error con respecto a este problema que existía en la comstackción 14251. Esto se resolvió en la comstackción 14257 (y superior).

Acabo de toparme con un problema similar y ninguna de las respuestas aquí aborda el problema que estaba enfrentando. Sin embargo, a diferencia de la pregunta, nunca recibo ningún mensaje que diga que hubo una falla en el enlace. El punto de ruptura nunca golpea. Espero que esto sea útil para alguien en el futuro golpeándose la cabeza contra la pared con WCF.

TL / DR:
En el mensaje SOAP, había un registro con datos incorrectos que causaban que no se golpeara el punto de interrupción.

Historia completa:

Tengo un servicio WCF basado en WSDL de otro equipo. No es mi definición, no tengo control sobre ella … Recibo mensajes de este otro equipo a través de este servicio. En mi caso, recibo mensajes, puedo registrar el mensaje en la tabla de registro de mensajes en la base de datos (que sucede antes de llamar a mi método de servicio), aparentemente se llama al método de servicio (quizás no) y el servidor responde con a 202 aceptado. La comunicación funciona, excepto que no se guardan datos en la base de datos durante la llamada al método.

Como el servicio devuelve una respuesta exitosa, descarté los problemas relacionados con http y el transporte.

Así que encendí VS2015 para depurar el servicio. El mensaje en cuestión es grande, pero dentro de los límites de lo que esperaría. Puse un punto de interrupción en la primera línea del método de servicio y envié el mensaje grande, pero el punto de interrupción nunca llegó. Probé un mensaje más pequeño que sabía que funcionaba en la misma instancia de ejecución y el punto de interrupción fue golpeado muy bien. Entonces todo en la configuración parecía estar bien. Pensé que tal vez había algo en el tamaño del mensaje.

Intenté todo lo que pude encontrar, asegurándome de estar en una configuración de depuración, limpiar y reconstruir, adjuntar manualmente el depurador al proceso w3wp (que VS ya estaba), usar Debugger.Break() lugar de un punto de interrupción, configurar varios proyectos de inicio , descargando mi proyecto de prueba para que el proyecto de servicio fuera el único, actualizando .NET, reiniciando VS2015, reiniciando, cambiando de Local IIS a IIS Express y viceversa, recreando el servicio con el último WSDL garantizado. Nada importaba El punto de inflexión nunca fue golpeado.

Terminé teniendo que eliminar registros en el mensaje grande uno por uno hasta que encontré un solo registro que tenía datos incorrectos. En mi caso, era un registro que no tenía valor para 2 campos DateTime. Cuando creé un mensaje que tenía solo este registro y lo envié, el punto de interrupción no se golpeó. Cuando proporcioné valores para esos 2 campos DateTime y envié el mismo mensaje (fijo) en el punto de interrupción disparado como se esperaba.

Tenía todas y cada una de las excepciones CLR habilitadas, no se activaron más que los archivos .pbd faltantes, lo que no me importó. WCF felizmente envió la solicitud con un mal registro. No digo que WCF no debería haberlo enviado basándose en los contratos, solo que el mal registro provocó que no se golpeara el punto de interrupción.

Tuve que modificar el archivo web.config para habilitar la depuración. Cambia esto:

  

a:

  

Agité un pollo de goma sobre mi máquina de desarrollo, dibujé un contorno de tiza de una estrella a su alrededor y funcionó. Antes de reírse, esto no es menos absurdo que las otras soluciones no ofrecidas para este error. Lo simple no va a hacer que esto desaparezca con ninguno de los pasos cortos o largos en ninguna de las soluciones que se ofrecen aquí. Creo que abandonar Visual Studio 2015 es la única forma práctica de evitarlo.

Limpie toda la solución antes de probar cualquiera de las otras soluciones. Después de probar casi todo lo demás en las respuestas anteriores, y reiniciar Visual Studio varias veces, ¡solo limpiar la solución hizo el truco!

Revisé las respuestas anteriores y la respuesta de @ Will resolvió el problema principal que estaba teniendo, la otra fue capaz de editar y continuar, pero echando un vistazo más de cerca al archivo AssemblyInfo.cs descubrí algunas características de depuración cuando estaban deshabilitadas.

Luego terminé eliminando los viejos atributos de depuración y añadiendo lo siguiente que tomé de otro proyecto

 #if DEBUG [assembly: System.Diagnostics.Debuggable(System.Diagnostics.DebuggableAttribute.DebuggingModes.DisableOptimizations | System.Diagnostics.DebuggableAttribute.DebuggingModes.EnableEditAndContinue | System.Diagnostics.DebuggableAttribute.DebuggingModes.IgnoreSymbolStoreSequencePoints | System.Diagnostics.DebuggableAttribute.DebuggingModes.Default)] #endif 

Sin embargo, siento que esta no es la mejor manera de hacerlo.