c# - puntos - punto de interrupcion visual studio 2012

Punto de interrupción no se pudo vincular-Visual Studio 2015 (23)

Cambiar el modo de lanzamiento a Depurar, en mi caso, esto solucionó mi problema.

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

Es un acierto o una falla donde los puntos de quiebre funcionarán realmente y si configuro uno durante la depuración me sale el error:

El punto de interrupción no pudo vincularse.

Cualquier ayuda sería apreciada. Estoy a punto de abandonar el 2015 y volver.

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. Simplemente no va a hacer que esto desaparezca con ninguno de los pasos cortos o largos en cualquiera de las soluciones que se ofrecen aquí. Creo que abandonar Visual Studio 2015 es la única forma práctica de evitarlo.

Ejecuté el rendimiento en mi solución y eso agregó esto a mi web.config

<compilation debug="true" targetFramework="4.5" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=12.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

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

En mi caso, había un nuevo archivo web.config creado después de usar Profiler . Al restaurar web.config a la versión anterior, se resolvió este problema. Era una aplicación web VS2015 C #.

Encontré los errores de punto de enlace vinculante hoy. Y he resuelto mi problema haciendo a continuación.

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

Proyecto limpio
Si la ruta de salida es diferente de la carpeta bin, reemplácela por la carpeta bin (esta es la regla más importante)
Reconstruir

Quizás esta solución ayude a alguien.

Esto puede parecer trivial, pero después de muchas discusiones con los mismos problemas que mencionó, descubrí que mi compilación estaba configurada para "liberar" en lugar de "depurar" cuando intenté depurar ... reconstruir la solución para "depurar" "lo arreglé, y pude establecer puntos de interrupción como normales

Intenté todo lo sugerido aquí. Finalmente, configuré la "Página específica" en Propiedades del proyecto -> Web en mi URL de inicio local, página y parámetro de consulta. Hice una limpieza y reconstrucción en modo de depuración y llegó a mi punto de interrupción.

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

La solución es deshabilitar la optimización del diseño.

Project Properties> Build> Advanced Compile Options> Enable Optimizations

Los puntos de interrupción de VS no pueden vincularse con métodos asincrónicos.

Tenía un agente de App Dynamics instalado que causó esto. Elimina eso y listo.

Me encontré con un problema similar y ninguna de las respuestas aquí golpeó el problema que estaba enfrentando. Sin embargo, a diferencia de la pregunta, nunca recibo ningún mensaje que diga que hubo un error al vincular. El punto de interrupción nunca llega. Esperemos que esto sea útil para alguien en el futuro golpeándose la cabeza con WCF.

TL / DR:
En el mensaje SOAP había un registro con datos incorrectos que hacía 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 eso ... 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 (lo que sucede antes de que se llame a mi método de servicio), aparentemente se llama al método de servicio (tal vez 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é problemas relacionados con http y transporte.

Así que encendí VS2015 para depurar el servicio. El mensaje en cuestión es amplio pero está 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ó. Intenté 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 alcanzado. Así que 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, adjuntando manualmente el depurador al proceso w3wp (que VS ya estaba), usando Debugger.Break() lugar de un punto de interrupción, configurando múltiples proyectos de inicio , descargando mi proyecto de prueba para que el proyecto de servicio fuera el único, actualizando .NET, reiniciando VS2015, reiniciando, cambiando de IIS local a IIS Express y viceversa, recreando el servicio con el último WSDL garantizado. Nada importaba. El punto de quiebre nunca fue alcanzado.

Terminé teniendo que eliminar registros en el mensaje grande uno por uno hasta que encontré un único 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 fue alcanzado. 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 las excepciones CLR habilitadas, nada más que faltan archivos .pbd faltantes, lo que no me importaba. WCF felizmente envió la solicitud con un mal registro. No estoy diciendo que WCF no debería haberlo enviado en base a los contratos, solo que el mal registro causó que no se alcanzara el punto de ruptura.

No cambié la configuración de ''optimizar'', pero en base a otras respuestas aquí, yo

Configure el Explorador de soluciones para mostrar todos los archivos para el proyecto
Eliminado el bin oculto y las carpetas de depuración
Realizó una ''Limpieza'' en el proyecto
Realizó ''Reconstruir'' en el proyecto

Hasta ahora esto me lo ha solucionado. Parece que actualizar a VS2015 Update 2 ha molestado algunas cosas en mi sistema.

Si bien esta es una compilación mucho más tardía (VS2017) tuve este problema con los proyectos de C #. Intenté limpiar, reconstruir, reiniciar el estudio visual, etc.

Lo que solucionó fue cerrar Visual Studio y eliminar la carpeta .vs, que es una carpeta oculta ubicada en el directorio de la solución. Eliminar la carpeta .vs no debería causarle ningún problema, aunque deberá restablecer su proyecto de inicio.

Tuve el mismo problema ayer. Utilicé la función "Solución limpia" y me ayudó.

Tuve el mismo problema pero una solución diferente. Tenga en cuenta que actualicé a VS 2015 Update 1 y el problema sigue ahí.

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

Entonces, si su última compilación estaba en modo de lanzamiento, e intenta depurar, el punto de interrupción no funcionará.

Primero debe generar manualmente en modo de depuración, luego comenzar a depurar.

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ó.

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 parar en puntos de quiebre. Cuando volví a la configuración Web.config original (eliminé la configuración de Performance Profiler), los puntos de interrupción comenzaron a funcionar nuevamente.

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

<compilation debug="true" targetFramework="4.5.2" assemblyPostProcessorType="Microsoft.VisualStudio.Enterprise.Common.AspPerformanceInstrumenter, Microsoft.VisualStudio.Enterprise.AspNetHelper, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>

<compilation debug="true"/>

Tuve un problema similar con los puntos de interrupción que no se vinculan, así como con ciertas variables locales que no se evalúan en la ventana Locales. Lo que finalmente solucionó fue habilitar la opción "Suprimir la optimización JIT en la carga del módulo (solo administrado)" en la pestaña Opciones-> Depurar-> General. Una vez que lo configuré, fue capaz de unirse sin problemas.

Yo tuve el mismo problema.

Lo resolví deshabilitando la opción "Optimizar código" en la pestaña Crear de las propiedades del proyecto.

Limpie la solución completa antes de probar cualquiera de las otras soluciones. Después de probar casi todo lo que se dijo en las respuestas anteriores, y reiniciar Visual Studio varias veces, ¡simplemente limpiar la solución funcionó!

PASO 1, descarta lo obvio:

Compilar en modo de depuración.
Intente limpiar la solución antes de establecer el punto de interrupción.
Vaya a la carpeta Depurar y elimine el archivo [Su aplicación] .pdb.
Luego haga una compilación o reconstrucción de su aplicación.
Vaya a la carpeta Depurar y confirme que tiene un archivo .pdb [Su aplicación] completamente nuevo.
Luego intente establecer su punto de ruptura.

PASO 2 Para proyectos C ++:

Verifique las siguientes propiedades del proyecto:

C ++ / General / Formato de información de depuración: base de datos del programa.
C ++ / Optimización: deshabilitado.
C ++ / Generación de código / Biblioteca de tiempo de ejecución: Depuración de subprocesos múltiples.
Enlace / Depuración / Generar información de depuración: Sí.
Enlace / Depuración / Generar base de datos del programa: $ (TargetDir) $ (TargetName) .pdb.
Linker / Manifest File / Generate Manifest: No.
Enlace / Archivo de manifiesto / Permitir aislamiento: No.
Linker / Embedded IDL / Ignorar IDL incrustado: Sí.
Haz el paso 1 otra vez

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

PASO 2 Para proyectos de C #:

En las propiedades del proyecto, el código Build / General / Optimize debe estar deshabilitado.
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

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

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

Ha habido informes de problemas como este en el VS2013 RTM, así como en VS2015 Actualización 1 y Actualización2.

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 ejecuta un sistema operativo Win 10, hubo un error informado sobre este problema que existía en la compilación 14251. Esto se resolvió en la compilación 14257 (y superior).

answear las respuestas anteriores y la respuesta de @ Will solucionó el problema principal que tenía, el otro pudo editar y continuar, pero al observar más de cerca el archivo AssemblyInfo.cs descubrí algunas características de depuración donde estaba deshabilitado.

Luego terminé eliminando los viejos atributos de depuración y agregando 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.