Fichiers PDB dans les dossiers bin \ debug de Visual Studio

Question

J'ai une solution VS (2008) composée de plusieurs projets, pas tous dans le même espace de noms. Lorsque je crée la solution, toutes les dll utilisées par le projet de niveau supérieur TopProject sont copiées dans le dossier TopProject \ bin \ debug . Toutefois, les fichiers .pdb correspondants ne sont copiés que pour certains des autres projets. C’est un problème, par exemple lors de l’utilisation de NDepend .

Comment VS détermine-t-il les fichiers .pdb à copier dans les dossiers bin \ debug de niveau supérieur? Comment puis-je faire en sorte que VS copie les autres également?

Modifier:

Les références sont les suivantes: toutes les dll sont copiées dans un emplacement central, sans leurs pdbs. TopProject seulement a des références à ces dll copiées; les dll elles-mêmes, cependant, savent évidemment où se trouvent leurs pdbs, et (la plupart d’entre elles) sont copiées correctement dans le dossier de débogage.

Answer 1

De MSDN :

  

Un fichier de base de données de programmes (PDB) contient   débogage et état du projet   information qui permet incrémentale   liaison d'une configuration Debug de   votre programme. Un fichier PDB est créé   lorsque vous compilez un programme C / C ++ avec   / ZI ou / Zi ou un visuel   Programme Basic / C # / JScript .NET avec   / debug.

Il semble donc que le "problème" " Ici (faute d'un meilleur mot), certaines de vos DLL sont générées en mode débogage (et donc émettent des PDB), et certaines sont en cours de création (n'émettant donc pas de PDB). Si tel est le cas, il devrait être facile de le réparer - allez dans chaque projet et mettez à jour ses paramètres de construction. Ce serait le scénario par défaut si vous n'avez pas encore peaufiné les options de la ligne de commande.

Cependant, cela deviendra plus difficile si ce n'est pas le cas. Peut-être que vous êtes tous en version ou en mode débogage. Vous devez maintenant examiner les options de compilation en ligne de commande (spécifiées dans les propriétés du projet) pour chaque projet. Mettez-les à jour avec / debug en conséquence si vous voulez le débogueur, ou supprimez-le si vous ne le voulez pas.

Modifier en réponse à modifier

Oui, les DLL "savoir" qu'ils ont des PDB et des chemins d'accès, mais cela ne veut pas dire grand chose. Copier uniquement les DLL dans un répertoire donné, comme d'autres l'ont mentionné, ne résoudra pas le problème. Vous avez également besoin des PDB.

La copie de fichiers individuels dans Windows, à l'exception de certains fichiers de type "bundle" (je ne connais pas le terme Microsoft, mais "les packages HTML complets" sont le concept) ne copie pas les fichiers associés. Les DLL ne sont pas assemblées dans le "lot". manière, donc les copier laisse leur PDB derrière.

Je dirais que la seule réponse que vous aurez à faire est de mettre à jour votre processus d’acheminement des DLL vers ces emplacements centraux et d’inclure les PDB ... J'aimerais bien pouvoir me tromper à cet égard!

Answer 2

Comme d'autres posts l'ont dit, vous pouvez avoir un problème de compilation / corruption.

Mais, comme l'a dit Will, si les fichiers pdb sont créés, mais ne se présentent pas à l'emplacement souhaité, créez une étape de post-génération. Voici l'étape de post-construction que je définis pour chaque projet de ma solution. Il s'assure que tous les fichiers de sortie sont copiés dans un répertoire commun.

Si votre fichier proj se trouve dans \ SolutionDir \ ProjDir, la première ligne de l'étape de post-génération copie les fichiers de sortie dans \ Solution \ Bin \ Release ou \ Solution \ Bin \ Debug. La deuxième ligne copie le fichier pdb s'il s'agit d'une construction Debug. Je ne copie pas le fichier pdb pour les versions Release.

Ainsi, \ SolutionDir \ Bin contient maintenant tous vos fichiers de sortie au même endroit.

xcopy /r /y $(TargetPath) $(ProjectDir)..\$(OutDir)
if $(ConfigurationName) == Debug xcopy /r /y $(TargetDir)$(TargetName).pdb $(ProjectDir)..\$(OutDir)

Answer 3

Tout d’abord, ne supposez jamais rien. Nettoyez la solution, reconstruisez-la en mode débogage et vérifiez si tous les fichiers pdb sont créés. Sinon, c’est votre problème.

S'ils sont créés et qu'ils ne sont pas tous copiés, vous pouvez contourner ce problème en créant un événement de post-construction qui copie manuellement les fichiers pdb aux emplacements souhaités. Ceci est bien sûr une solution de contournement, bien sûr.

La seule autre chose à laquelle je puisse penser est que votre fichier de solution est corrompu. Vous pouvez ouvrir votre fichier .sln en tant que fichier XML et en examiner le contenu. Vérifiez la configuration des projets qui agissent comme prévu et comparez-les à ceux qui ne le sont pas. Si vous ne voyez rien, vous devez répéter cela au niveau du projet. Comparez les fichiers de projet .csproj (ou autre) qui fonctionnent et les fichiers qui ne fonctionnent pas.

Modifier en réponse à modifier :

Si vous copiez simplement des fichiers manuellement, copiez-les également manuellement. Les DLL ne devraient pas "savoir". n'importe quoi sur pdbs, je crois. Il suffit de les coller dans le répertoire de destination et d'aller prendre un café. Détendez-vous.

Answer 4

Lorsque vous nettoyez la solution, vérifiez qu’elle est réellement nettoyée. J'ai vu VS laisser des fichiers traîner dans les répertoires bin \ debug même après le nettoyage. Supprimez le répertoire bin \ debug de tous vos projets et reconstruisez-le.