Visual Studio met en garde sur les copies de fichiers avec différents contenus
Lorsque je vais déboguer mon projet C++ dans Visual Studio, une petite boîte de dialogue d'avertissement apparaît qui me dit:
A copy of datum.h was found in
c:/users/brad/desktop/source/binary/datum.h, but the current
source code is different from the version built into
c:/users/brad/desktop/source/binary/datum.h.
J'ai du mal à comprendre ce que c'est même essayer de me dire, sans parler de la façon de le réparer. Au début, je pensais que je pouvais me plaindre d’avoir dupliqué par mégarde un fichier dans le répertoire que j’avais vérifié et que je n’avais rien trouvé de tel, ce qui me laisse perplexe. J'ai également essayé d'exclure le fichier de la solution et de l'ajouter à nouveau, ce qui n'a pas résolu le problème non plus.
L’avertissement ne semble pas réellement entraver le développement de mon projet, mais je suppose que les avertissements existent pour une raison, donc si quelqu'un sait ce qui ne va pas, tout conseil serait grandement apprécié. À ma connaissance, je n'ai rien changé pour que le message apparaisse, il est apparu une fois lorsque je suis allé déboguer la solution et continue d'apparaître depuis.
De plus, plusieurs copies du même avertissement ont commencé à apparaître, concernant d'autres fichiers d'en-tête de ma solution (je n'ai encore reçu aucun fichier .cpp, mais cela pourrait être une coïncidence, car cela ne dure que depuis environ 20 minutes).
Essayez de supprimer les points d'arrêt du fichier en question . Cela a fonctionné pour moi lorsqu'il s'est produit avec Visual Studio 2013 pour un fichier d'en-tête dans la version de débogage . Source: problème de synchronisation du fichier en mode publication - code source actuel version construite
Notes complémentaires: Nettoyer/Reconstruire fonctionne également, mais cela est douloureux pour un code régulièrement modifié. L'activation du point d'arrêt après le démarrage du débogueur retarde simplement le message.
Je l'ai résolu:
- Fermez la fenêtre du fichier .h dans Visual Studio s'il est ouvert.
- Fermez Visual Studio.
- COUPEZ le fichier .h à partir de son emplacement normal et collez-le dans un dossier temporaire inconnu de VS.
- Redémarrez VS et compilez. Il va se plaindre du fichier .h manquant. Bon - Faites le bâtard prier pour ça!
- Collez le fichier .h à son emplacement d'origine.
- Compiler. VS acceptera avec gratitude le fichier manquant. (Putain je déteste Microsoft!)
Le problème est que le débogueur pense que la somme de contrôle du fichier source est différente de celle que le compilateur a calculée et insérée. Le débogueur refusera ensuite d'appliquer des points d'arrêt dans les fichiers qui ne correspondent pas, afin de vous empêcher de voir les données qu'il ne peut pas garantir comme correctes.
Cela se produit même après une reconstruction complète. Ceci est avec VS 2015. Mon hypothèse est peut-être que le débogueur et le compilateur sont en désaccord sur la manière de hacher les nouvelles lignes ou quelque chose comme ça? Le correctif consiste à désactiver "obliger les fichiers source à correspondre exactement à la version d'origine" dans Debug -> Options -> Débogage -> Général
La raison peut être des dépendances d'en-tête circulaires. datum.h peut inclure another_header.h (directement ou indirectement), ce qui inclut datum.h.
Pourriez-vous, par hasard, déboguer un autre exécutable (pas celui qui a été construit?). Il s'agit d'un problème courant dans les scénarios où Visual Studio crée les fichiers binaires dans un répertoire, mais ceux-ci sont ensuite copiés dans un autre répertoire à des fins de débogage. Je vous suggérerais de comparer le chemin cible sous les paramètres de débogage et le répertoire de sortie sous les paramètres généraux de Visual Studio.
Cela expliquerait le problème, puisque vous déboguez une ancienne version du binaire (pas celle construite actuellement) et donc l'avertissement, car Visual Studio ne peut pas trouver la version des fichiers source pour cette version du binaire.
Je vois que la vraie raison de cette question est pas répondu. Donc, pour quelqu'un qui cherche toujours, le voici ... La raison la plus courante de ce problème est que les fichiers source utilisés pour créer les fichiers obj existants sont différents de ceux existants. En d’autres termes, le projet particulier n’a pas été construit après de nouvelles modifications de la source. La solution à ce problème consiste à reconstruire le projet après modification. Cela m'est arrivé dans une situation où j'avais modifié mes fichiers de projets de bibliothèque statiques, puis, sans construire ce projet, j'ai démarré mon projet d'application utilisant ce projet de bibliothèque statique.
Cela a fonctionné pour moi (à partir de mars 2019):
- Cliquez sur le menu déroulant "Construire" en haut à gauche de la fenêtre de Visual Studio.
- Sélectionnez 'Rebuild Solution'
cela a fonctionné pour moi:
- projet propre
- déboguer/supprimer tous les points d'arrêt :)
cela a fonctionné pour moi:
- fermer VS
- supprimer le fichier
*.vcxproj.filters - redémarrer VS
le problème devrait être parti.