Visual Studio 2010 pense toujours que le projet est obsolète, mais rien n'a changé
J'ai un problème très similaire à celui décrit ici .
J'ai également mis à niveau une solution mixte de projets C++/CLI et C # de Visual Studio 2008 vers Visual Studio 2010. À présent, dans Visual Studio 2010, un projet C++/CLI est toujours obsolète.
Même si elle a été compilée et liée juste avant et F5 est touché, la boîte de message "Le projet est obsolète. Voulez-vous le construire?" apparaît. Ceci est très gênant car le fichier DLL est de niveau très bas et force la reconstruction de presque tous les projets de la solution.
Mes paramètres pdb sont définis sur la valeur par défaut ( solution suggérée pour ce problème ).
Est-il possible d’obtenir la raison pour laquelle Visual Studio 2010 impose une reconstruction ou pense qu'un projet est à jour?
Avez-vous d'autres idées pour lesquelles Visual Studio 2010 se comporte comme ça?
Pour Visual Studio/Express 2010 uniquement. Voir d'autres réponses (plus faciles) pour VS2012, VS2013, etc.
Pour trouver le ou les fichiers manquants , utilisez les informations de l'article Activer la journalisation du système de projet C++ pour activer la journalisation du débogage dans Visual Studio et laissez-le dites simplement quelle est la cause de la reconstruction:
- Ouvrez le fichier
devenv.exe.config(qui se trouve dans%ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\ou dans%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\). Pour les versions Express, le fichier de configuration est nomméV*Express.exe.config. Ajoutez ce qui suit après la ligne
</configSections>:<system.diagnostics> <switches> <add name="CPS" value="4" /> </switches> </system.diagnostics>- Redémarrer Visual Studio
- Ouvrez DbgView et assurez-vous qu'il capture le résultat du débogage
- Essayez de déboguer (appuyez sur F5 dans Visual Studio)
Recherchez dans le journal de débogage toutes les lignes du formulaire:
devenv.exe Informations: 0: Le projet 'Bla\Bla\Dummy.vcxproj' n'est pas à jour car l'entrée de génération 'Bla\Bla\SomeFile.h' est manquante.
(Je viens d'appuyer sur Ctrl + F et j'ai recherché
not up to date]. Ce seront les références qui rendront le projet perpétuellement "obsolète".
Pour corriger cela, supprimez toutes les références aux fichiers manquants de votre projet ou mettez-les à jour pour indiquer leur emplacement réel.
Remarque: Si vous utilisez 2012 ou une version ultérieure, l'extrait de code devrait être:
<system.diagnostics>
<switches>
<add name="CPS" value="Verbose" />
</switches>
</system.diagnostics>
Dans Visual Studio 2012, j'ai pu obtenir le même résultat plus facilement que dans la solution acceptée.
J'ai changé l'option dans le menu Outils → Options → Projets et solutions → Construire et exécuter → * Construction du projet MSBuild verbosité en sortie "de Minimal à Diagnostic.
Ensuite, dans la sortie de la construction, j'ai trouvé les mêmes lignes en recherchant "pas à jour":
Le projet 'blabla' n'est pas à jour. L'élément de projet 'c:\foo\bar.xml' a l'attribut 'Copier dans le répertoire de sortie' défini sur 'Copier toujours'.
Cela m'est arrivé aujourd'hui. J'ai pu localiser la cause: le projet incluait un fichier d'en-tête qui n'existait plus sur le disque.
Supprimer le fichier du projet a résolu le problème.
Nous avons également rencontré ce problème et découvert comment le résoudre.
Le problème était comme indiqué ci-dessus "Le fichier n'existe plus sur le disque."
Ce n'est pas tout à fait correct. Le fichier existe sur le disque, mais le fichier .VCPROJ fait référence au fichier ailleurs.
Vous pouvez "découvrir" cela en allant dans la "vue du fichier d'inclusion" et en cliquant sur chaque fichier d'inclusion jusqu'à ce que vous trouviez celui que Visual Studio ne peut pas trouver. Vous ajoutez ensuite ce fichier (en tant qu’élément existant) et supprimez la référence introuvable. Tout est OK.
Une question valide est: comment Visual Studio peut-il même créer s'il ne sait pas où se trouvent les fichiers d'inclusion?
Nous pensons que le fichier .vcproj contient un chemin relatif vers le fichier incriminé, quelque part qu'il n'apparaît pas dans l'interface graphique de Visual Studio, ce qui explique pourquoi le projet sera créé, même si l'arborescence de l'inclusion est incorrecte.
La réponse acceptée m'aidait à trouver le moyen de résoudre ce problème pour le projet compliqué avec lequel je devais commencer. Cependant, j'ai dû faire face à un très grand nombre d'en-têtes d'inclusion. Avec la sortie de débogage détaillée, en supprimer une a provoqué le gel du IDE pendant 30 secondes lors de la sortie du débogage de débogage, ce qui a rendu le processus très lent.
Je me suis impatienté et ai écrit un script rapide Python pour vérifier les fichiers de projet (Visual Studio 2010) pour moi et générer tous les fichiers manquants en même temps, ainsi que les filtres dans lesquels ils se trouvent. Vous pouvez le trouver sous forme de Gist ici: https://Gist.github.com/antiuniverse/3825678 (ou this fourche qui supporte les chemins relatifs )
Exemple:
D:\...> check_inc.py sdk/src/game/client/swarm_sdk_client.vcxproj
[Header Files]:
fx_cs_blood.h (cstrike\fx_cs_blood.h)
hud_radar.h (cstrike\hud_radar.h)
[Game Shared Header Files]:
basecsgrenade_projectile.h (..\shared\cstrike\basecsgrenade_projectile.h)
fx_cs_shared.h (..\shared\cstrike\fx_cs_shared.h)
weapon_flashbang.h (..\shared\cstrike\weapon_flashbang.h)
weapon_hegrenade.h (..\shared\cstrike\weapon_hegrenade.h)
weapon_ifmsteadycam.h (..\shared\weapon_ifmsteadycam.h)
[Source Files\Swarm\GameUI - Embedded\Base GameUI\Headers]:
basepaenl.h (swarm\gameui\basepaenl.h)
...
Code source:
#!/c/Python32/python.exe
import sys
import os
import os.path
import xml.etree.ElementTree as ET
ns = '{http://schemas.Microsoft.com/developer/msbuild/2003}'
#Works with relative path also
projectFileName = sys.argv[1]
if not os.path.isabs(projectFileName):
projectFileName = os.path.join(os.getcwd(), projectFileName)
filterTree = ET.parse(projectFileName+".filters")
filterRoot = filterTree.getroot()
filterDict = dict()
missingDict = dict()
for inc in filterRoot.iter(ns+'ClInclude'):
incFileRel = inc.get('Include')
incFilter = inc.find(ns+'Filter')
if incFileRel != None and incFilter != None:
filterDict[incFileRel] = incFilter.text
if incFilter.text not in missingDict:
missingDict[incFilter.text] = []
projTree = ET.parse(projectFileName)
projRoot = projTree.getroot()
for inc in projRoot.iter(ns+'ClInclude'):
incFileRel = inc.get('Include')
if incFileRel != None:
incFile = os.path.abspath(os.path.join(os.path.dirname(projectFileName), incFileRel))
if not os.path.exists(incFile):
missingDict[filterDict[incFileRel]].append(incFileRel)
for (missingGroup, missingList) in missingDict.items():
if len(missingList) > 0:
print("["+missingGroup+"]:")
for missing in missingList:
print(" " + os.path.basename(missing) + " (" + missing + ")")
J'ai supprimé un cpp et certains fichiers d'en-tête de la solution (et du disque), mais le problème persiste.
Le problème est que chaque fichier utilisé par le compilateur est placé dans un fichier * .tlog de votre répertoire temporaire. Lorsque vous supprimez un fichier, ce fichier * .tlog n'est pas mis à jour. C'est le fichier utilisé par les versions incrémentielles pour vérifier si votre projet est à jour.
Modifiez ce fichier .tlog manuellement ou nettoyez votre projet et reconstruisez-le.
J'ai eu ce problème dans VS2013 (mise à jour 5) et il peut y avoir deux raisons à cela. Vous pouvez trouver les deux en activant la sortie de génération "détaillée" sous "Outils" -> "Projets et solutions" -> "Construire et exécuter". .
"Forcing recompile of all source files due to missing PDB "..."
Cela se produit lorsque vous désactivez la sortie des informations de débogage dans les options du compilateur (sous Paramètres du projet: "C/C++" -> "Format des informations de débogage" sur "Aucune" et "Éditeur de liens" -> "Générer les informations de débogage" sur "Non": ). Si vous avez laissé "C/C++" -> "Nom du fichier de base de données du programme" par défaut ("$ (IntDir) vc $ (PlatformToolsetVersion) .pdb"), VS ne trouvera pas le fichier en raison d'un bogue (- https://connect.Microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds ).
Pour résoudre ce problème, effacez simplement le nom du fichier en "" (champ vide)."Forcing rebuild of all source files due to a change in the command line since the last build."
Cela semble également être un bogue connu du VS ( https://connect.Microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due- -à-changer-dans-la-ligne-de-commande-depuis-la-dernière-construction ) et semble être corrigé dans les versions les plus récentes (mais pas VS2013). Je ne connaissais aucune solution de contournement, mais si vous le faites certainement, postez-le ici.
J'ai eu un problème similaire, mais dans mon cas, il ne manquait aucun fichier, il y avait une erreur dans la définition du fichier de sortie pdb: j'ai oublié le suffixe .pdb (j'ai découvert le truc de journalisation de débogage).
Pour résoudre le problème, j'ai modifié la ligne suivante dans le fichier vxproj:
<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>
à
<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>
Je ne sais pas si quelqu'un d'autre a le même problème, mais les propriétés de mon projet avaient "Configuration Properties" -> C/C++ -> "Debug Information Format" défini sur "Aucune", et lorsque je l'ai rétabli sur la valeur par défaut "Programme de base de données (/ Zi)", cela arrêtait la projet de recompiler à chaque fois.
Visual Studio 2013 - "Forcer la recompilation de tous les fichiers source en raison de l'absence de PDB". J'ai activé la sortie de construction détaillée pour localiser le problème: j'ai activé la sortie de construction "détaillée" sous "Outils" → "Projets et solutions" → "Construire et exécuter".
J'avais plusieurs projets, tous en C++, j'ai défini l'option pour les paramètres suivants du projet: (C/C++ → Format des informations de débogage) sur Base de données de programme (/ Zi) pour le projet en question. Cependant, cela n'a pas arrêté le problème pour ce projet. Le problème provenait d'un des autres projets C++ de la solution.
Je règle tous projets C++ sur "Base de données de programmes (/ Zi)". Cela a résolu le problème.
Encore une fois, le projet signalant le problème n'était pas le projet à problème. Essayez de régler tous les projets sur "Base de données de programmes (/ Zi)" pour résoudre le problème.
Une autre solution simple référencée par Forum Visual Studio .
Modification de la configuration: menu Outils → Options → Projets et solutions → Paramètres de projet VC++ → Mode Explorateur de solutions à Affiche tous les fichiers .
Ensuite, vous pouvez voir tous les fichiers dans l'Explorateur de solutions.
Recherchez les fichiers marqués par l'icône jaune et supprimez-les du projet.
C'est bon.
J'ai eu un problème similaire et ai suivi les instructions ci-dessus (la réponse acceptée) pour localiser les fichiers manquants, mais pas sans me gratter la tête. Voici mon résumé de ce que j'ai fait. Pour être précis, ce ne sont pas des fichiers manquants car ils ne sont pas nécessaires à la construction du projet (du moins dans mon cas), mais ce sont des références à des fichiers qui n'existent pas sur le disque et qui ne sont pas réellement nécessaires.
Voici mon histoire:
Sous Windows 7, le fichier se trouve dans
%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%. Il existe deux fichiers similairesdevenv.exe.config.configetdevenv.exe.config. Vous voulez changer plus tard.Sous Windows 7, vous n'êtes pas autorisé à modifier ce fichier dans des fichiers de programme. Copiez-le simplement ailleurs (sur le bureau), changez-le et recopiez-le à l'emplacement des fichiers du programme.
J'essayais de comprendre comment se connecter DebugView au IDE pour voir les fichiers manquants. Eh bien, vous n'avez rien à faire. Il suffit de l'exécuter et il capturera tous les messages. Assurez-vous que l'option de menu
Capture Eventsest sélectionnée dans le menuCapturequi, par défaut, doit être sélectionné.DebugView n'affichera PAS tous les fichiers manquants en même temps (du moins, ce n'est pas le cas pour moi)! DebugView serait en cours d’exécution et exécuterait le projet dans Visual Studio 2010. Il affichera le message
project out of date, sélectionnez Oui pour le générer et DebugView affichera le signe premier fichier manquant ou entraînant la reconstruction. Ouvrez le fichier de projet (pas le fichier solution) dans le Bloc-notes, recherchez-le et supprimez-le. Vous feriez mieux de fermer votre projet et de le rouvrir à nouveau en effectuant cette suppression. Répétez cette procédure jusqu'à ce que DebugView ne montre plus aucun fichier manquant.Il est utile de définir le filtre de message sur non à jour à partir du bouton de la barre d’outils DebugView ou Modifier → Filtrer/Surligner l'option . De cette façon, les seuls messages qu’il affiche sont ceux qui contiennent une chaîne "not update".
J'ai eu beaucoup de fichiers qui étaient des références inutiles et les supprimer tous ont résolu le problème en suivant les étapes ci-dessus.
Deuxième moyen de trouver tous les fichiers manquants à la fois
Il existe un deuxième moyen de rechercher ces fichiers en une fois, mais cela implique (a) le contrôle de source et (b) son intégration à Visual Studio 2010. Utilisation de Visual Studio 2010 , ajoutez votre projet à un emplacement souhaité ou à un emplacement factice dans le contrôle de source. Il essaiera d’ajouter tous les fichiers, y compris ceux qui n’existent pas sur le disque, mais qui sont référencés dans le fichier de projet. Allez dans votre logiciel de contrôle de code source comme Perforce , et il devrait marquer ces fichiers qui n'existent pas sur le disque dans un jeu de couleurs différent. Perforce les montre avec un verrou noir sur eux. Ce sont vos références manquantes. Maintenant, vous avez la liste de tous et vous pouvez tous les supprimer de votre fichier de projet en utilisant Notepad et votre projet ne se plaindra pas d'être obsolète .
J'ai rencontré ce problème aujourd'hui, mais c'était un peu différent. J'ai eu un projet CUDA DLL dans ma solution. Compiler dans une solution propre était correct, mais sinon, cela échouait et le compilateur traitait toujours le projet CUDA DLL comme non à jour.
J'ai essayé la solution de ce post .
Mais il n'y a pas de fichier d'en-tête manquant dans ma solution. Puis j'ai découvert la raison dans mon cas.
J'ai déjà modifié le répertoire intermédiaire du projet, bien que cela ne pose pas de problème. Et maintenant, lorsque j'ai remplacé le répertoire intermédiaire du projet CUDA DLL par le dossier $ (Configuration) \, tout fonctionne à nouveau correctement.
Je suppose qu’il existe un problème mineur entre la personnalisation de la construction CUDA et l’annuaire intermédiaire autre que celui par défaut.
Si vous utilisez la commande MSBuild en ligne de commande (et non l'IDE Visual Studio), par exemple si vous ciblez AppVeyor ou si vous préférez simplement la ligne de commande, vous pouvez ajouter cette option à votre ligne de commande MSBuild:
/fileLoggerParameters:LogFile=MyLog.log;Append;Verbosity=diagnostic;Encoding=UTF-8
Comme documenté ici (avertissement: verbosité usuelle de MSDN). Une fois la construction terminée, recherchez la chaîne will be compiled dans le fichier journal créé lors de la construction, MyLog.log.
Pour moi, c'était la présence d'un fichier d'en-tête non existant sur "Fichiers d'en-tête" à l'intérieur du projet. Après avoir supprimé cette entrée (clic droit> Exclure du projet) recompilée pour la première fois, puis directement
========== Build: 0 a réussi, 0 a échoué, 5 à jour, 0 ignoré ==========
et aucune tentative de reconstruction sans modification n'a été faite. Je pense que c'est un check-before-build implémenté par VS2010 (pas sûr si documenté, pourrait l'être) qui déclenche l'indicateur "AlwaysCreate".
J'utilise Visual Studio 2013 Professional avec Update 4, mais aucune solution n'a été trouvée, mais j'ai réussi à résoudre le problème pour mon projet Team.
Voici ce que j'ai fait pour causer le problème -
- Création d'un nouvel objet de classe (Projet -> Ajouter une classe)
- Renommez le fichier via l'Explorateur de solutions et cliquez sur Oui lorsque le système m'a demandé si je souhaitais renommer automatiquement toutes les références afin qu'elles correspondent.
Voici ce que j'ai fait pour résoudre le problème -
- Aller à la page principale de Team Explorer
- Cliquez sur Explorateur de contrôle de source
- Explorez le dossier contenant tous les fichiers de classe/projet.
- Trouver le nom de fichier ORIGINAL dans la liste et le supprimer par un clic droit
- Construire
Si tel est le cas, veillez simplement à supprimer le fichier fantôme plutôt que le fichier réel que vous souhaitez conserver dans le projet.
Dans mon cas, l'un des projets contient plusieurs fichiers IDL. Le compilateur MIDL génère un fichier de données DLL appelé "dlldata.c" pour chacun d'eux, quel que soit le nom du fichier IDL. Cela a obligé Visual Studio à compiler les fichiers IDL à chaque génération, même sans modification des fichiers IDL.
La solution de contournement consiste à configurer un fichier de sortie unique pour chaque fichier IDL (le compilateur MIDL génère toujours un tel fichier, même si le commutateur/dlldata est omis):
- Cliquez avec le bouton droit sur le fichier IDL
- Sélectionnez Propriétés - MIDL - Sortie
- Entrez un nom de fichier unique pour la propriété DllData File
J'ai passé de nombreuses heures à arracher mes cheveux pour ça. La sortie de la construction n'était pas cohérente. différents projets seraient "non à jour" pour différentes raisons d'une construction à l'autre. J'ai finalement trouvé que le coupable était DropBox (3.0.4). Je jonction mon dossier source de ...\DropBox dans mon dossier de projets (je ne suis pas sûr que ce soit la raison), mais DropBox "touche" en quelque sorte les fichiers pendant une construction. La synchronisation est en pause et tout est constamment mis à jour.
Pour moi, le problème est survenu dans un projet WPF dans lequel la propriété "Action de compilation" de certains fichiers était définie sur "Ressource" et celle de "Copier dans le répertoire de sortie" sur "Copier si plus récent". La solution semblait consister à remplacer la propriété "Copier dans le répertoire de sortie" par "Ne pas copier".
msbuild sait ne pas copier les fichiers 'Resource' dans la sortie - mais déclenche quand même une construction s'ils ne sont pas là. Peut-être que cela pourrait être considéré comme un bug?
Il est extrêmement utile de trouver ici les réponses qui suggèrent comment faire en sorte que msbuild connaisse pourquoi il continue de tout construire!
J'ai eu ce problème et trouvé ceci:
http://curlybrace.blogspot.com/2005/11/visual-c-project-continually-out-of.html
Projet Visual C++ constamment obsolète (
winwlm.h macwin32.h rpcerr.h macname1.hmanquant)Problème:
Dans Visual C++ .Net 2003, l'un de mes projets prétendait toujours être obsolète, même si rien n'avait changé et aucune erreur n'avait été signalée lors de la dernière génération.
En ouvrant le fichier BuildLog.htm du projet correspondant, une liste d’erreurs PRJ0041 apparaissait pour ces fichiers. Aucune d’entre elles n’apparaît sur mon système: winwlm.h macwin32.h rpcerr.h macname1.h
Chaque erreur ressemble à ceci:
MyApplication : warning PRJ0041 : Cannot find missing dependency 'macwin32.h' for file 'MyApplication.rc'.Votre projet peut toujours être généré, mais peut continuer à apparaître obsolète jusqu'à ce que ce fichier soit trouvé.
Solution:
Incluez
afxres.hau lieu deresource.hdans le fichier .rc du projet.Le fichier .rc du projet contenait "#include resource.h". Étant donné que le compilateur de ressources n'honore pas les blocs du préprocesseur
#ifdef, il déchirera et tentera de trouver les fichiers inclus qu'il devrait ignorer. Windows.h contient beaucoup de ces blocs. Incluant afxres.h à la place, nous avons corrigé les avertissements PRJ0041 et éliminé la boîte de dialogue d'erreur "Le projet est obsolète".
Il existe de nombreuses raisons potentielles et, comme indiqué plus haut, vous devez d'abord les diagnostiquer en définissant la verbosité de MSBuild sur "Diagnostic". La plupart du temps, la raison invoquée serait explicite et vous pourrez agir immédiatement, MAIS occasionnellement, MSBuild affirmerait à tort que certains fichiers sont modifiés et doivent être copiés.
Si tel est le cas, vous devez désactiver le tunneling NTFS ou dupliquer votre dossier de sortie vers un nouvel emplacement. Le voici en plus de mots.
Si vous modifiez les arguments de la commande de débogage pour le projet, cela déclenchera également la reconstruction du message du projet. Même si la cible elle-même n'est pas affectée par les arguments de débogage, les propriétés du projet ont été modifiées. Si vous reconstruisez cependant, le message devrait disparaître.
J'avais un projet VC++ qui compilait toujours tous les fichiers et qui avait déjà été mis à niveau de VS2005 à VS2010 (par d'autres personnes). J'ai trouvé que tous les fichiers cpp du projet, à l'exception de StdAfx.cpp, étaient configurés pour créer (/ Yc) l'en-tête précompilé. J'ai changé cela pour que seul StdAfx.cpp soit configuré pour créer l'en-tête précompilé et que le reste soit défini sur Utiliser (/ Yu) l'en-tête précompilé, ce qui a résolu le problème pour moi.
Un autre sur Visual Studio 2015 SP3, mais j'ai rencontré un problème similaire sur Visual Studio 2013 il y a quelques années.
Mon problème était que de façon ou d'autre un mauvais fichier cpp était utilisé pour les en-têtes précompilés (donc j'avais deux fichiers cpp qui ont créé les en-têtes précompilés). Maintenant, pourquoi Visual Studio a-t-il modifié les drapeaux sur le mauvais cpp pour "créer des en-têtes précompilés" sans ma demande? Je n'ai aucune idée, mais c'est arrivé ... peut-être un plugin ou quelque chose comme ça ???
Quoi qu'il en soit, le mauvais fichier cpp inclut le fichier version.h qui est modifié à chaque génération. Donc, Visual Studio reconstruit tous les en-têtes et à cause de cela l'ensemble du projet.
Eh bien, maintenant, le comportement est revenu à la normale.
Cela m'est arrivé à plusieurs reprises et puis est parti, avant que je puisse comprendre pourquoi. Dans mon cas c'était:
Heure système incorrecte dans la configuration à double démarrage!
Il s'avère que mon double démarrage avec Ubuntu en était la cause !! J'ai été trop paresseux pour obliger Ubuntu à cesser de jouer avec mon horloge matérielle. Lorsque je me connecte à Ubuntu, l'heure avance de 5 heures.
Par malchance, j'ai construit le projet une fois, avec le mauvais temps système, puis corrigé le temps. En conséquence, tous les fichiers de construction avaient des horodatages incorrects et VS penserait qu'ils sont tous périmés et reconstruirait le projet.
La plupart des systèmes de construction utilisent des horodatages de données pour déterminer le moment où les reconstructions doivent avoir lieu. L'horodatage de tous les fichiers de sortie est comparé à la dernière modification des dépendances. Si l'une des dépendances est plus récente, la cible est reconstruite.
Cela peut poser problème si l'une des dépendances obtient en quelque sorte un horodatage de données invalide, car il est difficile pour l'horodatage d'une sortie de construction de dépasser l'horodatage d'un fichier censément créé à l'avenir: P
J'ai eu un problème similaire avec Visual Studio 2005 et ma solution consistait en cinq projets dans la dépendance suivante (d'abord construite en haut):
Video_Codec depends on nothing
Generic_Graphics depends on Video_Codec
SpecificAPI_Graphics depends on Generic_Graphics
Engine depends on Specific_Graphics
Application depends on Engine.
Je découvrais que le projet Video_Codec souhaitait une génération complète même après un nettoyage complet puis une reconstruction de la solution.
J'ai résolu ce problème en veillant à ce que le fichier de sortie pdb du C/C++ et de l'éditeur de liens corresponde à l'emplacement utilisé par les autres projets en cours. J'ai aussi activé RTTI.