Le fichier symbole ne se charge pas pour le débogage d'un projet personnalisé dans Visual Studio 2012
J'ai une grande solution dans Visual Studio 2012 qui consiste en des exécutables et des projets de bibliothèque de classes. Lors du débogage de l'application, les points d'arrêt d'un projet de bibliothèque de classes particulier ne sont pas atteints.
J'ai regardé la fenêtre Debug> Windows> Modules pour vérifier l'état des symboles de ce projet et le message "Impossible de trouver ou d'ouvrir le fichier PDB".
Il est également indiqué "Non" dans la colonne "Code utilisateur".
Je remarque que quelques autres projets personnalisés de la solution affichent "Non" dans cette colonne et que leurs symboles ne se chargent pas non plus. Quelque chose avec un "Oui" sous "Code utilisateur" semble avoir eu son pdb chargé aucun problème. Mais je ne suis pas sûr si cela est pertinent.
J'ai utilisé dumpbin/headers sur la dll et le chemin d'accès au fichier pdb est présent et correct.
Le module n'est définitivement pas dans la liste d'exclusion pour le chargement du symbole.
J'ai également essayé de cliquer avec le bouton droit de la souris sur l'entrée dans la fenêtre des modules, en sélectionnant "Charger les symboles" et en naviguant jusqu'au chemin indiqué dans l'en-tête dll. Lorsque je sélectionne la pdb, il est écrit "Un fichier de symbole correspondant n'a pas été trouvé dans ce dossier".
Je l’obtiens après avoir supprimé ces dossiers et fichiers, nettoyé la solution, refermé et reconstruit le tout. Le pdb a été définitivement construit en même temps que la DLL en question.
Le problème réside donc clairement dans la partie du message d'erreur "ne peut pas ouvrir la base de données".
J'ai essayé ceci sur 2 ordinateurs et les deux présentent le même comportement.
Quelqu'un peut-il offrir des suggestions sur l'endroit où aller à partir de là, et peut-être pourquoi le pdb construit correspondant à la DLL ne se chargera pas?
J'ai essayé quelques outils pour vérifier si le pdb et le dll correspondaient, et en utilisant chkmatch je pouvais voir que les GUID de la dll en cours d'exécution et le pdb du dossier obj ne correspondaient pas.
Il s'avère donc que, bien que les dll et les pdb du dossier obj du projet correspondent, la dll en train d'être copiée dans le dossier de destination de l'application par un événement post-génération était l'ancienne dll de la version précédente.
L'événement post-génération était en cours d'exécution avant que le projet en question ait été construit, ou du moins terminé, et copiait la dll existante à partir du bac, qui a ensuite été écrasée par la construction en cours.
J'ai résolu le problème en modifiant les dépendances du projet pour la solution et en veillant à ce que le projet avec l'événement post-build dépende du projet qui ne se charge pas, et maintenant le chargement de pdb lors du débogage.
J'ai simplement supprimé le dossier bin et obj du dossier de projet de démarrage et reconstruit la solution.
Pour moi, je viens de supprimer le projet de IIS et le crée à nouveau et cela fonctionne bien
Pour moi, il a été utile d’utiliser l’outil chkmatch, puis de fermer et d’ouvrir Visual Studio, de nettoyer et de reconstruire. Maintenant, mon pdb est également chargé. Vous pouvez vous en assurer, comme l'a souligné Nanhydrin, dans Debug -> Windows -> Modules - cette vue n'est accessible que pendant le débogage.
Dans mon cas, l'ancienne version de la DLL référencée se trouvait dans mon compte GAC. Effacé, et cela a fonctionné.
J'ai trouvé que le projet sur lequel je recevais le message était optimisé lors de sa construction.
Je suis allé dans les propriétés du projet, onglet Compile, Options de compilation avancées ... et décoché la case Enable Optimizations
Rappel: Mettez le projet en configuration "Debug" ... pour ceux qui, comme moi, oublient et se sentent idiots.
Supprimé le projet de la solution et l'a ajouté à la solution a fonctionné pour moi. :)
Dans mon cas, il y avait une coche sur Enable Just My Code dans Tools>>Options>>Debugging>>General.
Je l'ai décochée et cela a fonctionné.
Peu en retard à la fête ici - juste au cas où cela est utile.
Nous avons deux sites Web distincts (dans différentes solutions de Visual Studio). Lors du chargement initial de l’un des sites, nous appelions l’autre site qui renverrait une image.
Ces deux sites ont référencé une DLL commune, mais alors qu’ils travaillaient sur un site, ils ne s’étaient pas rendu compte que l’autre site avait été laissé dans une version 'Release' - après le chargement du site, le DLL) a été reconstruit, mais sans symboles.
Félicitations à Nanhydrin pour avoir mentionné la fenêtre de débogage des modules (très utile) et pour me mettre sur la bonne voie avec l’événement post-build.
Réponse d'un autre fil qui a fonctionné pour moi: https://stackoverflow.com/a/28476665/5969306
- Dans Visual Studio: Propriétés du projet -> Générer -> bouton Avancé -> Déboguer les informations de débogage et assurez-vous que la valeur n'est pas "none".
Je viens d'avoir ce problème et je pensais mettre mon correctif ici, car cela pourrait aider les autres (peut-être même moi-même à nouveau?!) Dans le futur ...
Assurez-vous que lorsque vous vous connectez au processus sur le serveur distant, le paramètre "Attacher à" est défini sur
Détermine automatiquement le type de code à déboguer
Pour ce faire, lorsque le qualificateur de serveur a été fourni et qu'une liste de processus est visible, cliquez sur le bouton "Sélectionner" en regard de l'entrée "Attacher à".
Ensuite, sélectionnez "Déterminer automatiquement le type de code à déboguer" et OK en dehors de l'écran, puis attachez.
Cela a résolu le problème pour moi, au moins.
J'ai eu une ligne comme celle-ci dans ma fenêtre de débogage:
Les symboles du module 'MyModule.dll' n'étaient pas chargés.
J'ai supprimé l'option 'Optimiser le code' dans Propriétés du projet -> Construire. Et l'erreur a disparu.
J'ai eu ce problème, j'ai essayé toutes les autres solutions (cela a pris 2 jours !! Je pleure ...! DEUX JOURS!), Mais j'ai finalement réalisé que mon fichier était enregistré dans GAC, je l'ai supprimé et le problème a été résolu.
A l'invite de commande, tapez la commande suivante:
gacutil –u <Assembly name>
Comment: supprimer un assemblage du cache de l'assembly global
Ce problème peut être dû à référence erronée des dlls utilisée dans le projet.
Supprimez obj et bin dossiers du projet en cours et build projet à nouveau.
- Vérifiez les options de cette réponse: https://stackoverflow.com/a/38377530/6911991
- Cliquez sur Advanced et vérifiez que Informations de débogage est défini sur FULL
![Advanced tab screenshot]()
- Vérifier Exécuter la configuration dans tous les projets de la solution.
Vérifiez les autorisations pour le dossier temporaire ASP.NET:
"c:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files"
L'utilisateur du pool d'applications doit disposer des droits sur les sous-dossiers contenant les fichiers ASP.NET, par exemple:
root\60039743\c28e12ee