Projet Visual Studio obsolète
J'essayais de faire fonctionner Visual C++, mais je reçois cette erreur lors de la construction de chaque projet: "Ce projet est obsolète" "Voulez-vous le construire?" Il ne parvient pas à construire à chaque fois.
Lorsque je reconstruis, la construction échoue toujours, bien que dans l'enregistreur, je ne remarque aucun message d'erreur, ce qui me fait penser que sa journalisation n'est pas correcte (j'utilise un programme tiers pour consigner).
J'ai suivi certaines des instructions ici: http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx et la journalisation activée .
Je reçois cette erreur: projet pas à jour parce que "insérer le nom du fichier ici" .lastbuildstate est manquant. Notez que dans Visual Studio, rien n’est enregistré. Je n'ai rien trouvé à ce sujet dans Google. J'ai peut-être mal activé la journalisation, mais j'estime qu'il s'agit d'une erreur.
Que sont les fichiers "tlog"?
Les fichiers "tlog" sont créés par le processus "Tracker.exe" qui s'exécute pendant la construction et enregistre des informations sur la construction.
Ces informations sont utilisées et mises à jour la prochaine fois que vous démarrez une génération pour aider à détecter les fichiers "obsolètes" et ainsi permettre au système de construction de ne construire que les bits qui doivent être reconstruits (au lieu de tout reconstruire à nouveau).
Qu'est-ce qui cause le problème "obsolète"?
Le problème peut être dû à des informations incorrectes ou obsolètes dans les fichiers *.tlog.
Il y a 3 façons principales qui peuvent arriver:
1) Vous avez construit un projet sur votre disque dur, puis déplacé le répertoire vers un autre emplacement ... les fichiers "tlog" ont enregistré les chemins de l'ancien emplacement, mais comme vous les avez déplacés, ils ne sont plus là. Obtenez "obsolète".
2) Votre "projet" contient des références à des fichiers (généralement des fichiers d'en-tête), qui n'existent pas à l'emplacement spécifié. Cela peut se produire si vous supprimez un fichier de votre système de contrôle de code source sans le supprimer de votre projet ou si vous faites référence aux fichiers d'en-tête d'une bibliothèque pouvant être "installés"/présents à un autre emplacement. Les développeurs supposent souvent que les fichiers se trouvent au même endroit sur toutes les machines, mais pas toujours!
3) Vous avez procédé à une "refactorisation" de votre projet et déplacé des fichiers vers différents sous-répertoires, voire les avez renommés - de sorte que les chemins/noms des fichiers enregistrés dans le "tlog" ne correspondent pas à ce qui existe sur votre disque, c'est-à-dire obsolète. .
Quel est le moyen de le réparer?
Faire un "Clean + Build" ou "Rebuild" ne le résout pas toujours ... car ces opérations ne suppriment pas les fichiers "tlog". Alors:
supprimez tous les fichiers "tlog" que vous pouvez trouver dans les répertoires de votre solution/projet et reconstruisez-les.
assurez-vous que votre projet ne fait pas référence à des fichiers inexistants
Comment puis-je déterminer quels fichiers sont inexistants?
Si vous voulez savoir/savoir exactement quels fichiers Visual Studio estime obsolètes, vous pouvez activer certaines informations de diagnostic dans Visual Studio .... et regarder les messages dans DebugView ... indiquant le chemin d'accès complet du fichier. fichiers qu’il sonde.
Dans devenv.exe.config vous mettez:
<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>
Plus de détails
Disons que vous avez créé une solution et un ensemble de projets dans un répertoire particulier, par exemple. S:\MYPROJECTS, et vous le compilez et l’exécutez/le corrigez, etc.
Vous décidez ensuite de déplacer l'intégralité de ce répertoire vers un autre emplacement de votre lecteur ou de reformater vos projets, par exemple. changer leurs noms de répertoire, etc.
Désormais, lorsque vous effectuez un "Démarrer le débogage/F5", Visual Studio effectue la vérification dépendante et pense que vous avez des "fichiers obsolètes".
Même si vous effectuez une "solution propre" ou une "solution de reconstruction", vous recevez toujours le message "Fichiers obsolètes".
Vois ici:
Le problème est dû aux fichiers ".tlog" consultés lors des vérifications de dépendance ... lorsque vous déplacez les solutions/projets (avec des fichiers intermédiaires générés), ils créent une confusion dans le générateur Visual Studio.
La solution consiste à supprimer tous les fichiers .tlog ..... ils seront ensuite générés à nouveau lors de la compilation ... et à partir de ce moment, vous n'aurez plus de "fichiers périmés". message .... à moins qu’ils ne soient vraiment obsolètes.
Vous devez laisser Visual Studio vous expliquer pourquoi il doit être reconstruit. Visual Studio 2015 intègre un support pour cela:
- Outils (menu)
- Les options
- Projet et solution
- Construire et exécuter
Modifiez la verbosité de sortie du projet MSBuild en Detailed ou Diagnostics.
Dans mon cas, cela imprimait un message comme ceci:
1>------ Up-To-Date check: Project: xyz, Configuration: xyz ------
1>Project not up to date because build input 'C:\ws\Missing.h' is missing.
... et en supprimant cet en-tête du projet a résolu le problème.
Pour obtenir ces informations dans les anciennes versions de Visual Studio, vous devez utiliser DebugView et modifier devenv.exe.config (voir la réponse de Colin Smith: https://stackoverflow.com/a/21759835/1941779 ). Notez que cette solution ne fonctionne pas pour Visual Studio 2015.
Moi aussi, j'ai continué à avoir l'erreur "Le projet obsolète", même s'il n'y avait pas de changement. Je l'ai tracé dans un fichier d'en-tête répertorié dans l'Explorateur de solutions qui n'était plus utilisé et qui avait été supprimé du répertoire du projet. En le supprimant de la liste SE, le message d'erreur superflu a été corrigé.
J'ai eu ce problème aussi . Dans mon cas, la raison en était les références aux fichiers (généralement les fichiers d'en-tête), qui n'existent pas à l'emplacement spécifié.
Je me suis heurté à ce problème et, en utilisant l’astuce de diagnostic évoquée par colinsmith, je suis parvenu à remonter au fait que mon fichier .vcxproj faisait référence à un fichier qui n’existait nulle part (il avait été supprimé il y a longtemps). , mais jamais supprimé du fichier de projet).
Juste pour la postérité, je commençais à avoir ce problème, puis je réalisai que l'horloge de mon ordinateur avait sauté environ 48 heures plus tard. Après que je l'ai remis à l'heure actuelle, l'avertissement est parti.