El punto de interrupción no será golpeado actualmente. No se han cargado símbolos para este documento en una aplicación de Silverlight

Ok, lo que tengo:

Visual Studio 2010 RC, W7 x64, inició un nuevo tipo de proyecto de aplicación Silverlight. Alojamiento de la aplicación Silverlight en un proyecto de aplicación web ASP.NET. Silverlight Version 3.0. Se agregó una clase LinqToSQL, un servicio WCF, una aplicación Winform Tester (proyecto en la solución) y algunas clases (también como proyectos en la solución).

Ayer, de repente recibí el ‘El punto de quiebre no será golpeado actualmente. No se han cargado símbolos para este documento. ‘ mensaje para que aparezca en el IDE, pero solo afecta a la aplicación web; puedo depurar la aplicación Silverlight y Winform.

Lo que intenté / hice para deshacerme del mensaje:

  • Restablecer la configuración de Visual Studio
  • eliminó todos los archivos en cada \ Carpeta temporal de archivos ASP.NET (hay uno para cada 32 bits / 64 bits y para Framework 2.0 y 4.0)
  • intenté depurar usando el servidor web integrado de Visual Studio; normalmente utilizo IIS, en el resultado del proyecto de la solución eliminé todas las carpetas obj y bin en cada carpeta de proyecto
  • creó una nueva solución y agregó todos los proyectos a esta nueva solución
  • eliminado el archivo suo de la solución
  • creó una nueva aplicación web ASP.NET para probar si es un problema de instalación VS => Puedo depurar este nuevo proyecto / solución
  • reinició la máquina varias veces
  • reparó la instalación de vs.net
  • hice un IISReset
  • eliminó la aplicación web de IIS
  • utilizó el botón Crear directorio virtual en Propiedades del proyecto de la aplicación web para crear una nueva aplicación web en IIS
  • cambió la Versión de Marco de cada proyecto de 3.5 a 4.0
  • Abrí la Solución en mi segunda máquina => mismo comportamiento
  • rastreó Microsoft Connect por errores / problemas similares
  • PASADO 7 HORAS.

Entonces, esto sucede la segunda vez en mi vida. La última vez que lo resolví borré la Carpeta Temporal de Archivos ASP.NET, pero esta vez necesito tu ayuda.

Haga clic derecho en la solución -> Propiedades

Consulte Propiedades comunes -> Proyecto de inicio

Seleccione varios proyectos de inicio

seleccione Iniciar acción en los proyectos que necesita depurar.

Tuve el mismo problema y después de buscar en Google encontré dos soluciones típicas para esto:

  1. Asegúrese de que el depurador de Silverlight esté activado en el proyecto .Web. Abra las propiedades del proyecto y seleccione el depurador de Silverlight en la pestaña “Web”.

  2. Reinicie Visual Studio y elimine todas las carpetas bin y obj.

Pero ninguno de estos funcionó para mí . Luego, alguien mencionó un hilo para intentar usar IE como navegador. ¡Esto hizo que la depuración y los puntos de interrupción funcionaran nuevamente!

Editar:

Más tarde, he luchado con IE9 no funciona, porque se adhiere al proceso equivocado. En lugar de adjuntar manualmente al proceso de IE correcto cada vez, encontré un buen truco :

  • Haga clic con el botón derecho en una de las páginas generadas en el proyecto .Web (.html o .aspx)
  • Haga clic en “Buscar con …”
  • Establezca IE como navegador predeterminado (solo afectará la elección del navegador de Visual Studio)

Ahora, Visual Studio lanzará IE al ejecutar el proyecto .Web y se conectará al proceso correcto. Deberias hacer eso.

Cada vez que he tenido este error en particular, se ha comprobado que la carpeta desde la que está cargando Visual Studio es diferente de la carpeta desde la que se ejecuta la aplicación web.

Es decir, el servidor de aplicaciones ejecuta la aplicación desde

C:\dev\MyApplication\bin 

pero Visual Studio está depurando desde

 C:\dev\MyOtherApplication\bin (or something along those lines, anyway). 

Nota: por diversas razones, hago mi depuración con IIS como el host de la aplicación en lugar del pequeño artefacto independiente que la mayoría de la gente usa. ¡Esto podría influenciar la utilidad de mi respuesta!

Actualización :

Para IIS, el directorio del servidor de aplicaciones (es decir, C:\dev\MyApplication ) es el directorio físico configurado para la aplicación web; esto se puede controlar cambiando la configuración básica de la aplicación.

Para Visual Studio, el directorio de depuración (es decir, C:\dev\MyOtherApplication anterior) es el directorio en el que se encuentran los archivos svc , generalmente el mismo directorio que el archivo de proyecto csproj .

El problema para mí resultó ser que la checkbox Propiedades-> Construir-> Optimizar código se había activado en la configuración de depuración. Lo apagó, reconstruyó y la depuración funcionó normalmente.

La razón de lo que enfrentó es que los PDB (“PDB significa Program Database, un formato de archivo propietario (desarrollado por Microsoft) para almacenar información de depuración sobre un progtwig) no están actualizados, esto puede deberse a algunas razones :

1- Como dijo Bevan, ¡puedes estar depurando otra aplicación!

2- Estás depurando otra versión de la misma aplicación. Por ejemplo, adjuntó una aplicación creada previamente con la versión actual del código para la depuración sin (re) construirla.

Limpiar o reconstruir la solución resuelve estos problemas para mí.

Para asegurarse de que el problema no sea el suyo, intente depurar la misma aplicación con VS 2008 (me temo que puede ser un error en VS 2010, ¡sigue siendo beta!).

Tuve el mismo problema, estaba depurando mi proyecto, y tuve que hacer clic derecho en el proyecto y seleccionar “nueva instancia de depuración”. Solo necesitaba hacer esto una vez, luego de eso funcionó de forma normal.

Este error aparece de vez en cuando para mí y siempre puedo rastrearlo de nuevo a la configuración del proyecto para el ensamblado en cuestión. No tiene que “esperar” hasta que su código no respete un punto de corte o hasta que configure el punto de corte, para saber qué ensamblajes tienen símbolos cargados.

Cuando ejecuta un proyecto en modo de depuración aparecerá una lista en la ventana de Salida cuyos ensamblajes tienen símbolos cargados como se muestra a continuación (Es posible que necesite abrir la imagen en una nueva pestaña): T

Ventana de salida

Entonces, en este caso, BASD.Core.Data.dll NO tiene símbolos cargados. Entonces, puede comparar la configuración del proyecto para este ensamblaje con la de otro ensamblaje que logró cargar símbolos, con el fin de determinar por qué algunos lo hacen y algunos no cargan símbolos.

“Para mí”, sin embargo, “cada” vez que esto sucede es porque no se está creando la información de depuración. Entonces abro Project Properties> Build> Advanced en un proyecto (C #).

Por lo tanto, para Basd.Core.Data.dll arriba, es decir, sin símbolos, las configuraciones avanzadas de comstackción fueron:

pdboff

Mientras que para Bash.Core.Configuration.dll, es decir, un conjunto en el que podía establecer y alcanzar un punto de interrupción, la configuración era:

pdbon

Así que estoy sacando información de depuración en el último proyecto y no en el primero, de ahí mi capacidad para alcanzar el punto de quiebre en Basd.Core.Configuration.dll

También tenga en cuenta que no es suficiente simplemente tener un archivo .pdb en la carpeta bin de un proyecto para un archivo .dll determinado, ya que podría estar desactualizado y, por lo tanto, Visual Studio no lo recogió como un archivo de símbolos válido para .dll estás tratando de pasar.

También tenga en cuenta que cambiar las configuraciones de comstackción puede cambiar la configuración de la información de comstackción y de dónde se extraen los símbolos.

(Me doy cuenta en este caso que estoy en modo Release, pero el método aún se aplica)

Ir a Propiedades del proyecto -> Construir -> Avanzado …

En la sección “Salida”, seleccione “completo” en el menú desplegable Información de depuración

Asegúrese de ejecutar su progtwig en modo DEBUG y no en modo RELEASE.

Acabo de resolver este problema según Implementación de aplicaciones de Silverlight . (Esta respuesta es un duplicado de algunos otros, pero intentaré explicarlo más a fondo).

El problema es muy probable que su aplicación Silverlight no se esté implementando correctamente en su aplicación web en la comstackción / inicio. Este es un problema de referencia: es fácil de entender, pero no es obvio la primera vez que lo encuentra.

Al igual que cualquier otra referencia de proyecto, la salida del proyecto al que se hace referencia debe copiarse en la carpeta bin del proyecto de referencia para depurar. Para las bibliotecas de clases, esto sucede cuando hace clic derecho y selecciona ‘Agregar referencia …’. Para Silverlight, debe agregar una referencia a través de Propiedades del proyecto.

  • Haga clic derecho en su proyecto y seleccione ‘Propiedades’
  • Seleccione la pestaña ‘Aplicaciones de Silverlight’ a la izquierda
  • Presiona el botón ‘Agregar …’ y selecciona tu proyecto Silverlight en el cuadro de diálogo

Esto agrega una referencia a la aplicación Silverlight desde su aplicación web de alojamiento y asegura que el archivo xap se copiará a la aplicación web en la comstackción o implementación. Eso significa que la aplicación Silverlight actual y sus archivos de depuración se encuentran dentro de la aplicación que se está depurando, y podrá recorrer el código.

Si está depurando un proyecto web, asegúrese de que el atributo debug = “true” se haya establecido en su archivo web.config:

   

Tuve el mismo problema en Windows 7 y probé todo : archivos DLL limpiados, lista de módulos investigados, desactivado “Just My Code”, y así sucesivamente.

El problema se resolvió después de ejecutar Visual Studio “como administrador”. Honestamente. ¿Por qué Microsoft no podía simplemente advertirme que no se está ejecutando “como administrador”? Me ahorraría algunas horas de trabajo.

Para mí, el problema era que tenía habilitado “Optimizar código” en la pestaña Generar de la configuración de mi proyecto.

Tenía el mismo problema

Por alguna razón, uno de los archivos DLL se registró en el GAC, por lo tanto, siempre tuvo una versión diferente que el código.

Una vez que lo quité del GAC, se solucionó el problema

Depurar -> Adjuntar para procesar ->
elija Depurar estos tipos de código: opción ->
seleccione Managed v3.5, v3.0, v2.0 o Managed v4.5, v4.0 enter image description here

Para aquellos que están leyendo que están usando Visual Studio 2008, no Visual Studio 2010 y están obteniendo este error. Las respuestas anteriores no me ayudaron en esta situación, así que estoy compartiendo mi experiencia.

Si está depurando una aplicación web de IIS en Visual Studio 2008 adjuntando al proceso w3wp.exe en lugar de utilizar el servidor de desarrollo ASP.NET para la depuración (comience con la depuración), este podría ser su problema:

Es posible que Visual Studio siga haciendo referencia a un archivo de símbolos (archivo utilizado durante la depuración) de su archivo DLL de un proceso de IIS que está desactualizado. Y ese archivo de símbolos ha sido recreado por una recomstackción de código fuente de .NET, pero el proceso de IIS sigue haciendo referencia al archivo de símbolos anterior.

Arreglar:

Simplemente detenga la depuración en Visual Studio, reinicie la aplicación web y vuelva a conectarse al proceso. Luego, los puntos de interrupción deberían pasar de amarillo (cuando vea este error) a rojo otra vez.

========================

Más cosas para probar (situación nueva encontrada hoy):

Haga cada viñeta en el enlace de abajo UNA VEZ, pero repita mis pasos a continuación con cada uno que pruebe.

http://carnotaurus.philipcarney.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same

1.) Detenga la depuración (presione el ícono del cuadrado rojo) en Visual Studio
2.) Solución limpia
3.) Construir solución
4.) [INSERTAR INSTRUCCIÓN BULLET AQUÍ]
5.) Herramientas> Adjuntar al proceso (o comenzar con la depuración)
6.) Inicie el progtwig al que se está conectando y ejecútelo para que su código reciba un golpe.

6 explicado:

Si se conecta a nunit.exe, abra NUnit y ejecute una prueba para que su punto de interrupción sea golpeado

Si se conecta a w3wp.exe (sitio IIS), abra su sitio en el navegador y vaya a la página que llegará a su punto de interrupción

EDITAR:

Hoy noté que si intentas depurar en un proyecto que no está configurado como proyecto de inicio, se mostrará esto. Cuando se conecta a su proceso w3wp.exe, piensa que está depurando en el proyecto que se establece como el proyecto de inicio. Para resolverlo, simplemente haga clic con el botón derecho en el proyecto de la aplicación web y seleccione “Establecer como proyecto de inicio”. Luego intente volver a unirse a su proceso.

El escenario es el siguiente: un proyecto en particular es su proyecto de inicio (por ejemplo, tiene el método Principal). Ese proyecto hace referencia a otros proyectos en su solución. Los puntos de quiebre en los otros proyectos no están siendo golpeados.

Solución rápida: cuando construya su solución, busque en la ruta de salida de comstackción (generalmente bin \ Debug) para el proyecto de inicio. Mire los archivos DLL y PDB para los proyectos a los que hace referencia. Asegúrese de que su última fecha de modificación sea la última vez que creó su solución. Si no lo están, cópielos de la ruta de salida de comstackción para cada proyecto en los proyectos de inicio comstackción de la ruta de salida. Por ejemplo:

El proyecto A tiene Main. Hace referencia al Proyecto B. Sus puntos de corte no se ven afectados en el Proyecto B. Copie el archivo DLL y PDB de la ruta de salida de comstackción del Proyecto B a la ruta de salida de Comstackción del Proyecto A. Luego ejecuta tu solución. El punto de quiebre ahora será golpeado.

Ahora necesita averiguar por qué el Proyecto A no está copiando sobre el archivo DLL y PDB del Proyecto B. Las respuestas aquí cubren la mayoría de los escenarios. Un escenario que no se ha solucionado es asegurarse de que sus proyectos y soluciones estén vinculados a TFS correctamente. Tenía algunos proyectos vinculados y algunos no vinculados correctamente. Eso causó el problema para mí. Una vez que arreglé eso, el problema desapareció y ya no tuve que copiar los archivos DLL y PDB.

Las soluciones para el mismo problema en mi caso fue la siguiente combinación de pasos:

  1. Solución -> Propiedades Seleccione varios proyectos de inicio seleccione Acción de inicio en los proyectos que necesita depurar.
  2. Se eliminó el servicio de las referencias de servicio y se limpió la solución.
  3. Reconstruir el proyecto de servicio
  4. Se agregó a las referencias de servicio
  5. Limpie la solución y reconstruya.

Para solucionar este problema en Web.config solo tenía que agregar debug="true"

    

Lo que me ayudó a encontrar esta solución fue mirar las ventanas de Módulos durante la depuración y vi que para las DLL de ASP.NET cargadas, tenía: El archivo binario no se creó con la información de depuración.

Tuve el mismo problema pero en VS2013 para una aplicación web. Para mí, la respuesta fue actualizar la configuración de comstackción para la solución:

  1. Haga clic derecho en la Solución y elija Propiedades
  2. Seleccione la configuración de depuración
  3. Seleccione “Configuración” en “Propiedades de configuración” en el trébedes
  4. Compruebe en el cuadro “Generar” para cada proyecto que desea depurar

Una vez que hice esto, todos mis puntos de interrupción comenzaron a funcionar.

De acuerdo, aquí vamos:

(En una “aplicación Silverlight”: compruebe primero que Silverlight está marcado en “web” en las “propiedades” de su proyecto servidor – Si eso no lo resolvió, intente esto debajo)

En la primera vez, ejecute esto primero: devenv.exe / ResetSettings y 1: en el menú superior, haga clic en la etiqueta de depuración 2: haga clic en opciones y configuración 3: en “depuración” y en “general” busque “habilitar .net framework source stepping” 4: Marque la casilla. 5: Y ahora todos los símbolos serán descargados y reconfigurados 🙂

Si vuelve a ocurrir después de lo anterior, simplemente borre la carpeta donde están los símbolos:

1: En el menú superior, haga clic en la etiqueta de depuración 2: haga clic en Opciones y configuración 3: en “depuración” y debajo de “símbolos”, busque el botón “caché de símbolos vacía” y haga clic en él.

Abra la url de la aplicación web desde el navegador y luego en el IDE VS.Net use Herramientas -> Adjuntar a proceso

luego adjuntar a aspnet_wp.exe.

El depurador comenzará a funcionar

Tuve que desinstalar manualmente todas las instancias del .dll del registro y todas las instancias del archivo .dll desde mi unidad local. Desinstalé / reinstalé mi aplicación y ahora estoy llegando a los puntos de interrupción. Perdió medio día haciendo esto :(.

Traté de renombrar el archivo .pdb en la carpeta obj\debug e hice una solución limpia y reconstruí.
Creó un nuevo archivo .pdb y pude .pdb a los puntos de interrupción correctamente.

Tuve el mismo problema: perdí mucho tiempo intentando que la depuración funcionara en Visual Studio.

Terminó siendo Nuget. Tenía 3 versiones de Newtonsoft.Json (en 7 proyectos de C #). La solución se comstackría pero no se pudo depurar.

Solucioné el problema ejecutando lo siguiente en la consola del administrador de paquetes de Nuget:

PM> Paquete de actualización Newtonsoft.Json

Para mi aplicación WPF, eliminé la carpeta de la aplicación, “Obtuve lo más nuevo” del control de código fuente nuevamente y reconstruí. Todos los puntos de interrupción funcionan bien ahora.

Intente configurar Silverlight Application Project como un proyecto de inicio: haga clic con el botón secundario en project -> ‘Establecer como proyecto de inicio. Luego presione F5 y vea si puede atrapar puntos de interrupción …

Intente eliminar los datos de navegación / temperatura en su navegador cada vez que realice cambios en la aplicación Silverlight

Otra anécdota que podría ser útil-

Encontré este problema cuando uno de mis proyectos utilizaba referencias de archivos de una carpeta de salida de lanzamiento. Cuando los resultados de comstackción se colocaron en una carpeta de Mercancías, estos dlls de Versión sobrescribían los dlls de Debug.

La solución fue asegurarme de que en el archivo csproj, mi HintPath de referencia era

..\..\Core\Goods\$(Configuration)\MyFramework.dll

y no

..\..\Core\Goods\Release\MyFramework.dll

Tuve este problema cuando en un cliente donde, para cada solución de aplicación, copiaban la mayoría de los ensamblajes compartidos en una carpeta de ” Referencias ” y luego los agregaban a la solución como ” Elementos de solucióny como un ” Proyecto ” dentro de la solución.

Aún no estoy seguro de por qué, pero algunos de ellos fueron depurables, otros no, aunque en las configuraciones de Referencias para los ensamblajes se especificaron las rutas completas correctas.

Este comportamiento impredecible alomst me volvió loco 🙂

Lo resolví quitando todos los ensamblajes de la carpeta ” Referencias ” para los que había proyectos con código fuente y manteniendo un buen seguimiento de la información de la versión para ensamblajes compartidos.

Tenía un problema similar, excepto que mi problema era tonto: tenía 2 instancias del servidor web incorporado que se ejecutaba en 2 puertos diferentes Y tenía mi proyecto -> propiedades -> web -> “URL de inicio” apuntando a un puerto fijo, pero la aplicación web no se estaba ejecutando bajo ese puerto. Así que mi navegador estaba siendo redirigido a la “URL de inicio” que se refería a 1539 pero la instancia de código / depuración se estaba ejecutando bajo el puerto 50803.

Cambié el servidor web incorporado para que se ejecutara bajo un puerto fijo y ajusté mi “URL de inicio” para usar ese puerto también. proyecto -> propiedades -> web -> sección “Servidores” -> “Usar Visual Studio Development Server” -> puerto específico