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

Acabo de actualizar de 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 realmente funcionarán 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.

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.

Yo tuve el mismo problema.

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

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

Tuve un problema similar con los puntos de interrupción que no se vinculan, así como 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 vincularse sin problemas.

Tuve este problema Ejecuté una sesión de creación de perfiles de rendimiento que modificó el Web.configarchivo con la configuración del monitor de rendimiento:

<appSettings>
   <add key="Microsoft.VisualStudio.Enterprise.AspNetHelper.VsInstrLocation" value="C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Team Tools\Performance Tools\vsinstr.exe"/>
</appSettings>


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


<runtime>
   <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
         <assemblyIdentity name="Microsoft.VisualStudio.Enterprise.AspNetHelper" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
         <codeBase version="16.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/Microsoft.VisualStudio.Enterprise.AspNetHelper.DLL"/>
      </dependentAssembly>
      <dependentAssembly>
         <assemblyIdentity name="VsWebSite.Interop" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
         <codeBase version="8.0.0.0" href="file:///D:/Program%20Files%20(x86)/Microsoft%20Visual%20Studio/Shared/Common/VSPerfCollectionTools/vs2019/VsWebSite.Interop.DLL"/>
      </dependentAssembly>
   </assemblyBinding>
</runtime>

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 el mismo problema ayer. Utilicé la función "Solución limpia" y me ayudó.

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

Project Properties> Build> Advanced Compile Options> Enable Optimizations

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"/> 

este assemblyPostProcessorTypees el problema, lo eliminé y eso resolvió mi problema

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

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

1. Configure el Explorador de soluciones para mostrar todos los archivos para el proyecto
2. Eliminado el bin oculto y las carpetas de depuración
3. Realizó una 'Limpieza' en el proyecto
4. 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.

Sé que esta es una publicación antigua, pero en caso de que todos los otros trucos anteriores no funcionen para usted, asegúrese de que la imagen que está tratando de depurar esté actualizada. Por alguna razón, después de publicar y transferir un proyecto .NET Core a mi Raspberry Pi 'descomprimir' en el RPi no estaba copiando y sobrescribiendo algunas DLL en el directorio de trabajo. Cuando adjunté el depurador pensando que todo estaba bien, algunos puntos de interrupción estaban siendo alcanzados, otros no y otros me daban el error "no se puede vincular". Una vez que resolví el problema de descompresión, volvieron todos mis puntos de interrupción y símbolos. Espero que esto ayude.

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.

1. Proyecto limpio
2. Si la ruta de salida es diferente de la carpeta bin, reemplácela por 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 de VS no pueden vincularse con métodos asíncronos.

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

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 Microsoft Visual Studio 2015 Update 3 (KB3165756) ha solucionado el problema del punto de interrupción para mí cuando estoy tratando de inspeccionar las variables locales en el código C # incrustado en archivos cshtml en aplicaciones ASP.NET Core.

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, se informó un error relacionado con este problema que existía en la compilación 14251. Esto se resolvió en la compilación 14257 (y superior).

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 quiebre nunca llega. Esperemos 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 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 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 (lo que ocurre 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 en 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 función de los contratos, solo que el mal registro hizo que no se alcanzara el punto de ruptura.

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"/>

a:

<compilation debug="true"/>

Limpie toda la solución 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ó!

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.

Si bien esta es una versión mucho más tardía (VS2017), tuve este problema con los proyectos de C #. Intenté limpiar, reconstruir, reiniciar Visual Studio, 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.

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

En caso de que esté publicando la comprobación de su aplicación web Configurationconfigurada en Debug(de forma predeterminada, la configuración de depuración está configurada de modo que el código no esté optimizado y la tabla de símbolos esté completamente creada).

Revisé las respuestas anteriores y la respuesta de @ Will solucionó el problema principal que tenía, el otro pudo editar y continuar, pero al mirar 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.