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. Et maintenant, 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 que F5 soit frappé, le message “Le projet est obsolète. Voulez-vous le construire?” apparaît. C’est très ennuyeux car le fichier DLL est très bas et oblige presque tous les projets de la solution à se reconstruire.

Mes parameters 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 force une reconstruction ou pense qu’un projet est à jour?

D’autres idées pour lesquelles Visual Studio 2010 se comporte comme ça?

Pour Visual Studio / Express 2010 uniquement. Voir d’autres réponses (faciles) pour VS2012, VS2013, etc.

Pour rechercher 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 simplement indiquer la cause de la reconstruction:

  1. Ouvrez le fichier devenv.exe.config (trouvé 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 .
  2. Ajoutez ce qui suit après la ligne :

          
  3. Redémarrez Visual Studio
  4. Ouvrez DbgView et assurez-vous qu’il capture la sortie de débogage
  5. Essayez de déboguer (cliquez sur F5 dans Visual Studio)
  6. Recherchez dans le journal de débogage les lignes du formulaire:

    Informations sur devenv.exe: 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 cherché pour not up to date ) Ce seront les références qui feront que le projet sera perpétuellement “obsolète”.

Pour corriger cela, supprimez toutes les références aux fichiers manquants de votre projet ou mettez à jour les références pour indiquer leurs emplacements réels.

Remarque: Si vous utilisez 2012 ou une version ultérieure, l’extrait de code doit être:

      

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 OutilsOptionsProjets et solutionsCréer et exécuter → * La sortie de construction du projet MSBuild “de Minimal à Diagnostic .

Ensuite, dans la sortie de compilation, j’ai trouvé les mêmes lignes en recherchant “non à jour”:

Le projet ‘blabla’ n’est pas à jour. L’élément de projet ‘c: \ foo \ bar.xml’ a l’atsortingbut ‘Copy to Output Directory’ défini sur ‘Copy always’.

Cela m’est arrivé aujourd’hui. J’ai pu identifier la cause: le projet comprenait un fichier d’en-tête qui n’existait plus sur le disque.

La suppression du fichier du projet a résolu le problème.

Nous avons également rencontré ce problème et avons 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 “include file view” 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 et tout va bien.

Une question valable est la suivante: comment Visual Studio peut-il même créer s’il ne sait pas où se trouvent les fichiers inclus?

Nous pensons que le fichier .vcproj a un chemin d’access relatif au fichier incriminé quelque part qu’il ne montre pas dans l’interface graphique de Visual Studio, ce qui explique pourquoi le projet sera réellement généré même si la vue arborescente des inclus est incorrecte.

La réponse acceptée m’a aidé à trouver le moyen de résoudre ce problème pour le projet dévasté avec lequel je devais travailler. Cependant, j’ai dû faire face à un très grand nombre d’en-têtes d’inclusion. Avec la sortie de débogage prolixe, la suppression de l’une a provoqué le blocage de l’EDI pendant 30 secondes lors de la sortie de la diffusion de débogage, ce qui a rendu le processus très lent.

J’ai été impatient et j’ai écrit un script Python rapide et sale pour vérifier les fichiers de projet (Visual Studio 2010) et sortir tous les fichiers manquants en même temps, avec les filtres dans lesquels ils se trouvent. Gist ici: https://gist.github.com/antiuniverse/3825678 (ou cette fourche qui prend en charge les chemins relatifs )

Exemple:

 D:\...> check_inc.py sdk/src/game/client/swarm_sdk_client.vcxproj [Header Files]: fx_cs_blood.h (cssortingke\fx_cs_blood.h) hud_radar.h (cssortingke\hud_radar.h) [Game Shared Header Files]: basecsgrenade_projectile.h (..\shared\cssortingke\basecsgrenade_projectile.h) fx_cs_shared.h (..\shared\cssortingke\fx_cs_shared.h) weapon_flashbang.h (..\shared\cssortingke\weapon_flashbang.h) weapon_hegrenade.h (..\shared\cssortingke\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 fichier cpp et certains fichiers d’en-tête de la solution (et du disque) mais j’ai toujours rencontré le problème.

Quoi qu’il en soit, chaque fichier utilisé par le compilateur se trouve dans un fichier * .tlog dans 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.

Editez manuellement ce fichier .tlog ou nettoyez votre projet et reconstruisez.

J’ai eu un problème similaire, mais dans mon cas il n’y avait aucun fichier manquant, il y avait une erreur dans la façon dont le fichier de sortie de pdb était défini: j’ai oublié le suffixe .pdb (j’ai découvert avec le tour de débogage).

Pour résoudre le problème, j’ai modifié dans le fichier vxproj la ligne suivante:

 MyName 

à

 MyName.pdb 

J’ai eu ce problème dans VS2013 (mise à jour 5) et il peut y avoir deux raisons à cela, les deux que vous pouvez trouver en activant la sortie “détaillée” sous “Outils” -> “Projets et solutions” -> “Créer et exécuter” .

  1. "Forcing recomstack 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 «Aucun» et «Linker» -> «Non»:) . Si vous avez laissé “C / C ++” -> “Program Database File Name” à la valeur par défaut (qui est “$ (IntDir) vc $ (PlatformToolsetVersion) .pdb”), VS ne trouvera pas le fichier à cause d’un bogue ( https : //connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds ).
    Pour le réparer, effacez simplement le nom du fichier à “” (champ vide).

  2. "Forcing rebuild of all source files due to a change in the command line since the last build."
    Cela semble être un bogue VS connu aussi ( https://connect.microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due-to-a-change-in- the-command-line-since-the-last-build ) et semble être corrigé dans les nouvelles versions (mais pas dans VS2013). Je ne connaissais aucune solution de contournement, mais si vous le faites, postez-la ici.

Je ne sais pas si quelqu’un d’autre a ce même problème, mais les propriétés de mon projet ont "Configuration Properties" -> C/C++ -> "Debug Information Format" défini sur “Aucun” et quand je suis revenu au “par défaut” Program Database (/ Zi) “, qui a empêché le projet de se recomstackr à chaque fois.

Une autre solution simple référencée par Visual Studio Forum .

Modification de la configuration: menu OutilsOptionsProjets et solutionsParamètres du projet VC ++Mode Explorateur de solutions pour afficher 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 rencontré ce problème aujourd’hui, mais c’était un peu différent. J’avais un projet DLL CUDA dans ma solution. Comstackr dans une solution propre était correct, mais sinon il a échoué et le compilateur a toujours traité le projet DLL CUDA comme non à jour.

J’ai essayé la solution depuis ce post .

Mais il n’y a pas de fichier en-tête manquant dans ma solution. Ensuite, j’ai découvert la raison dans mon cas.

J’ai changé le répertoire intermédiaire du projet avant, bien que cela n’ait pas causé de problèmes. Et maintenant, quand j’ai changé le répertoire intermédiaire du projet DLL CUDA en $ (Configuration) \, tout fonctionne à nouveau correctement.

J’imagine qu’il y a un problème mineur entre la personnalisation de génération CUDA et l’annuaire intermédiaire autre que celui par défaut.

J’ai eu un problème similaire et j’ai suivi les instructions ci-dessus (la réponse acceptée) pour localiser les fichiers manquants, mais pas sans me rayer 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 requirejs par le projet pour la construction (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 vraiment nécessaires.

Voici mon histoire:

  1. Sous Windows 7, le fichier se trouve dans %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\% . Il existe deux fichiers similaires: devenv.exe.config.config et devenv.exe.config . Vous voulez changer plus tard un.

  2. Sous Windows 7, vous n’êtes pas autorisé à modifier ce fichier dans les fichiers de programme. Il suffit de le copier ailleurs (sur le bureau), de le modifier et de le recopier dans l’emplacement des fichiers du programme.

  3. J’essayais de comprendre comment connecter DebugView à l’EDI pour voir les fichiers manquants. Eh bien, vous n’avez rien à faire. Il suffit de l’exécuter pour capturer tous les messages. Assurez-vous que l’option de menu Capture Events est sélectionnée dans le menu Capture , lequel doit être sélectionné par défaut.

  4. DebugView n’affichera PAS tous les fichiers manquants en même temps (du moins, ce n’était pas le cas pour moi)! DebugView s’exécuterait et exécuterait le projet dans Visual Studio 2010. Il affichera le message project out of date du project out of date , sélectionnez Oui pour générer et DebugView affichera le premier fichier manquant ou provoquant la reconstruction. Ouvrez le fichier de projet (pas le fichier de solution) dans le Bloc-notes et recherchez ce fichier et supprimez-le. Il est préférable de fermer votre projet et de le rouvrir tout en effectuant cette suppression. Répétez ce processus jusqu’à ce que DebugView ne montre plus aucun fichier manquant.

  5. Il est utile de ne pas mettre à jour le filtre de messages à partir du bouton de la barre d’outils DebugView ou de l’option ModifierFiltrer / Mettre en surbrillance . De cette façon, les seuls messages affichés sont ceux qui ne contiennent pas de chaîne «à jour».

J’ai eu beaucoup de fichiers qui étaient des références inutiles et les supprimer tous corrigé le problème en suivant les étapes ci-dessus.

Deuxième façon de trouver tous les fichiers manquants à la fois

Il existe un second moyen de trouver ces fichiers en une seule fois, mais cela implique (a) le contrôle des sources et (b) leur intégration à Visual Studio 2010. En utilisant Visual Studio 2010 , ajoutez votre projet à l’emplacement ou à l’emplacement factice souhaité contrôle. Il essaiera d’append tous les fichiers, y compris ceux qui n’existent pas sur le disque, mais référencés dans le fichier du projet. Accédez à votre logiciel de contrôle de source, tel que Perforce , et marquez ces fichiers qui n’existent pas sur le disque dans un schéma de couleurs différent. Perforce les montre avec un verrou noir sur eux. Ce sont vos références manquantes. Vous avez maintenant une liste de tous, et vous pouvez tous les supprimer de votre fichier de projet en utilisant le Bloc-notes et votre projet ne se plaindra pas d’être obsolète .

Visual Studio 2013 – “Forcer la recompilation de tous les fichiers sources 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” → “Créer et exécuter”.

J’ai eu plusieurs projets, tous en C ++, j’ai mis l’option pour les parameters de projet: (C / C ++ → Format de débogage) à la firebase database de programme (/ Zi) pour le projet problématique. Cependant, cela n’a pas empêché le problème pour ce projet. Le problème venait de l’un des autres projets C ++ de la solution.

Je mets tous les projets C ++ sur “Program Database (/ Zi)”. Cela a résolu le problème.

Encore une fois, le projet signalant le problème n’était pas le problème. Essayez de définir tous les projets sur “Program Database (/ Zi)” pour résoudre le problème.

Pour moi, c’était la présence d’un fichier d’en-tête non existant sur “Header Files” à l’intérieur du projet. Après avoir supprimé cette entrée (clic droit> Exclure du projet) la première fois recompilée, alors directement

========== Construire: 0 réussi, 0 échoué, 5 mis à jour, 0 sauté ==========

et aucune tentative de reconstruction sans modification n’a été effectuée. Je pense qu’il s’agit d’un check-before-build implémenté par VS2010 (pas sûr si documenté, pourrait être) qui déclenche le flag “AlwaysCreate”.

Si vous utilisez la commande MSBuild en ligne de commande (pas l’IDE de Visual Studio), par exemple si vous ciblez AppVeyor ou si vous préférez simplement la ligne de commande, vous pouvez append cette option à votre ligne de commande MSBuild:

 /fileLoggerParameters:LogFile=MyLog.log;Append;Verbosity=diagnostic;Encoding=UTF-8 

Comme documenté ici (avertissement: verbosité MSDN habituelle). Lorsque la génération se termine, la recherche de la chaîne will be comstackd dans le fichier journal créé lors de la génération, MyLog.log .

J’utilise Visual Studio 2013 Professional avec la mise à jour 4, mais je n’ai trouvé aucune solution avec les autres suggestions. Cependant, 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 object de classe (Projet -> Ajouter une classe)
  • Renommé le fichier via l’Explorateur de solutions et cliqué sur Oui lorsqu’on lui a demandé si je voulais renommer automatiquement toutes les références pour qu’elles correspondent.

Voici ce que j’ai fait pour résoudre le problème –

  • Aller à la page d’accueil de Team Explorer
  • Cliquez sur Explorateur de contrôle de source
  • Accédez au dossier contenant tous les fichiers de classe / projet
  • J’ai trouvé le nom de fichier ORIGINAL dans la liste et l’ai supprimé par un clic droit
  • Construire

Si c’est le cas pour vous, soyez simplement sûr que vous supprimez le fichier fantôme plutôt que celui que vous souhaitez conserver dans le projet.

J’ai eu ce problème et j’ai trouvé ceci:

http://curlybrace.blogspot.com/2005/11/visual-c-project-continually-out-of.html

Projet Visual C ++ continuellement obsolète ( winwlm.h macwin32.h rpcerr.h macname1.h manquant)

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 qu’aucune erreur n’avait été signalée lors de la dernière version.

L’ouverture du fichier BuildLog.htm pour le projet correspondant a montré une liste d’erreurs PRJ0041 pour ces fichiers, dont aucun 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.h au lieu de resource.h dans 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 #ifdef préprocesseur, il va déchirer et essayer de trouver les fichiers inclus qu’il devrait ignorer. Windows.h contient beaucoup de ces blocs. Inclure afxres.h à la place a corrigé les avertissements PRJ0041 et éliminé la boîte de dialog d’erreur “Le projet est obsolète”.

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 à comstackr les fichiers IDL sur chaque version, même sans modification des fichiers IDL.

La solution 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 à m’arracher les cheveux. La sortie de compilation n’était pas cohérente; différents projets ne seraient “pas à jour” pour différentes raisons d’une construction à l’autre. J’ai finalement trouvé que le coupable était DropBox (3.0.4). Je jonctionne mon dossier source de … \ DropBox dans mon dossier de projets (je ne suis pas sûr que ce soit la raison), mais DropBox “touche” d’une manière ou d’une autre les fichiers lors d’ une construction. Pause de la synchronisation et tout est constamment mis à jour.

Il existe plusieurs raisons potentielles et, comme indiqué, vous devez d’abord les diagnostiquer en définissant la verbosité de MSBuild sur «Diagnostic». La plupart du temps, la raison énoncée serait explicite et vous pourriez 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 soit désactiver le tunneling NTFS, soit dupliquer votre dossier de sortie vers un nouvel emplacement. Ici c’est en plus de mots.

Pour moi, le problème est survenu dans un projet WPF dont la propriété ‘Build Action’ était définie sur ‘Resource’ sur certains fichiers et sur ‘Copy si newer’ dans le répertoire ‘Copy to Output Directory’. La solution semblait être de remplacer la propriété ‘Copy to Output Directory’ par ‘Do not copy’.

msbuild ne sait 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 que les réponses suggèrent comment faire en sorte que msbuild réponde à toutes les raisons pour lesquelles il continue à tout construire!

Si vous modifiez les arguments de la commande de débogage pour le projet, cela déclenchera également le message nécessitant une reconstruction 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, le message devrait disparaître.

Cela m’est arrivé à plusieurs resockets, puis je suis partie avant que je puisse comprendre pourquoi. Dans mon cas c’était:

Mauvais temps système dans la configuration à double démarrage!

Il s’avère que mon double démarrage avec Ubuntu était la cause principale! J’ai été trop paresseux pour réparer Ubuntu pour arrêter de jouer avec mon horloge matérielle. Lorsque je me connecte à Ubuntu, le temps passe de 5 heures.

Par malchance, j’ai construit le projet une fois, avec le mauvais temps système, puis corrigé l’heure. En conséquence, tous les fichiers de génération avaient des horodatages incorrects et VS pensait qu’ils étaient tous obsolètes et reconstruiraient le projet.

La plupart des systèmes de construction utilisent des horodatages de données pour déterminer le moment où les reconstructions doivent se produire – l’horodatage de tous les fichiers de sortie est vérifié par rapport à la dernière heure de modification des dépendances – si l’une des dépendances est plus récente, la cible est reconstruite.

Cela peut poser des problèmes si l’une des dépendances obtient un horodatage de données invalide, car il est difficile pour l’horodatage d’une sortie de construire de dépasser l’horodatage d’un fichier soi-disant créé ultérieurement: P

J’ai rencontré un problème similaire avec Visual Studio 2005 et ma solution consistait en cinq projets dans la dépendance suivante (créée en premier):

 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 trouvais que le projet Video_Codec voulait une version complète, même après un nettoyage complet, puis la reconstruction de la solution.

J’ai résolu ce pdb 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 également activé le RTTI.

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 quelque part un fichier cpp incorrect était utilisé pour les en-têtes précompilés (donc j’avais deux fichiers cpp qui créaient les en-têtes précompilés). Maintenant, pourquoi Visual Studio a-t-il changé les drapeaux sur le mauvais cpp pour créer des en-têtes précompilés sans ma demande? Je n’en ai aucune idée, mais cela s’est produit … peut-être un plugin ou quelque chose ???

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 le projet entier.

Eh bien, maintenant, il revient au comportement normal.

Les projets .NET sont toujours recompilés indépendamment. Cela consiste en partie à maintenir l’EDI à jour (comme IntelliSense). Je me souviens d’avoir posé cette question sur un forum Microsoft il y a des années, et c’est la réponse qui m’a été donnée.