Visual Studio: le projet n'est pas à jour "car" AlwaysCreate "a été spécifié"?
J'ai migré une solution de VS2008 à VS2010 (SP1).
Maintenant, l'un de mes projets ne trouve jamais la paix d'être à jour. Chaque build a la sortie suivante:
1>------ Build started: Project: PROJ_NAME, Configuration: Release Win32 ------
1>Build started 19/05/2011 7:59:27 AM.
1>InitializeBuildStatus:
1> Creating "Release\PROJ_NAME.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>ClCompile:
1> All outputs are up-to-date.
1> All outputs are up-to-date.
1>Lib:
1> All outputs are up-to-date.
1> PROJ_NAME.vcxproj -> C:\projFolder.PROJ_NAME.lib
1>FinalizeBuildStatus:
1> Deleting file "Release\PROJ_NAME.unsuccessfulbuild".
1> Touching "Release\PROJ_NAME.lastbuildstate".
1>
1>Build succeeded.
1>
1>Time Elapsed 00:00:00.09
========== Build: 1 succeeded, 0 failed, 5 up-to-date, 0 skipped ==========
Des idées?
J'ai eu un problème similaire lorsque l'un des fichiers d'inclusion répertoriés dans le projet n'existait pas. J'avais supprimé le fichier, mais j'avais oublié de le supprimer du projet.
Le vérificateur de dépendance pense alors que le projet n'est pas à jour, mais le constructeur ne trouve rien à construire.
J'ai eu deux projets contenant le même fichier. Lorsque le second projet a été créé, il a compilé le fichier à nouveau, en modifiant l'heure de prise de contact. Définissez ensuite l'indicateur 'AlwaysCreate' pour le premier projet.
Je l'ai découvert en activant "CPS" dans mon fichier "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config", comme dans l'extrait de code XML ci-dessous. Lorsque cette fonction est activée, vous pouvez utiliser l'outil DebugView pour obtenir les messages de VS2010 qui indiquent POURQUOI il reconstruit votre projet. Pourquoi ces messages ne figurent pas dans le journal de construction me dépasse, mais de toute façon, c'est le cas.
Ajoute ça:
<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>
Jusqu'ici:
<?xml version ="1.0"?>
<configuration>
<configSections>
<section name="msbuildToolsets" type="Microsoft.Build.BuildEngine.ToolsetConfigurationSection, Microsoft.Build.Engine, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</configSections>
<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0.30319" />
Selon this thread sur MSDN:
Dans mon cas, dans VS10, cela était dû au fait que des fichiers manquants (mais non conformes, donc aucune erreur supplémentaire à identifier) étaient présents dans les dossiers du projet.
Une vérification rapide de l’ouverture de tous les fichiers du projet dans l’éditeur a résolu ce problème.
Vous devez également vérifier les fichiers autres que .h. Dans mon projet, Readme.txt a été manqué.
J'ai déplacé une solution vers un nouveau dossier et chaque fois que je construisais une nouvelle version ou que j'essayais de déboguer, le système voulait prétendre que tous les projets qui composaient la solution étaient périmés, alors qu'ils venaient de les générer.
J'ai cherché dans tous les fichiers .vcxproj, utilisé DebugView avec CPS = 4 (voir la réponse de @ Bzzt ci-dessus) et découvert qu'il recherchait les fichiers d'en-tête dans leur ancien emplacement. Puisque la solution a été déplacée, pas copiée, ces fichiers n'existaient pas.
Ce qui a finalement résolu le problème pour moi, c’est de nettoyer la solution et d’en reconstruire un. Après cela, "AlwaysCreate" ne lui causait plus le "build" de tous les sous-projets. Vous devez nettoyer chaque configuration (débogage et libération) séparément, mais une fois qu'elle a été reconstruite à partir de l'état de nettoyage, tout va bien.
Dans mon cas, il ne construisait aucun bâtiment, mais MSBuild ou tout ce qui avait décidé que les choses n'étaient pas à jour utilisait un chemin de fichier en cache qui n'existait plus. Le nettoyage et la reconstruction ont remplacé ce cache, puis il a été construit comme prévu.
Pour les versions msbuild.exe en ligne de commande, vous pouvez utiliser/verbosity: détailler et rechercher le résultat
- "sera compilé en tant que" pour trouver des compilations
- "Compilation de la source requise" pour trouver des liens
Remarque: La sortie peut être transmise au fichier à l’aide de msbuild.exe/verbosity: detailed> output.txt
par exemple.
code.cpp will be compiled as C:\path\to\header.h was modified at 18/02/2016 15:58:31.
Outputs for C:\path\to\code.cpp:
Dans Visual Studio 2010, j'ai éliminé les reconstructions parasites d'une solution à projets multiples en laissant la compilation multiprocesseur (/ MP) non définie (dommage!). Auparavant, je l'avais activé. Trouvez le drapeau ici: Propriétés communes> C/C++> Général> Compilation multiprocesseur. De plus, j'ai remarqué que j'étais capable d'éliminer les reconstructions parasites de projets individuels en reconstruisant chaque projet individuellement; ensuite, une compilation de chacun a montré que chacun était à jour.
J'ai le même problème.
Cause fondamentale: version de construction incorrecte de VS (32 bits et 64 bits)
Solution: passer en mode débogage/libération de 32 bits à 64 bits ou inversement
Vous pouvez également constater que cela se produit après une mise à jour de Windows, voir ceci: Les projets à jour compilés à nouveau en raison de l'horodatage TZRE.DLL sont à venir après une mise à jour de Windows
La solution consiste à attendre jusqu'à ce moment-là et le problème disparaîtra comme par magie . Je viens d'avoir le même problème, mon fichier TZRES.DLL est le 17/07/2018 19:54, il est maintenant 17/07/2018 15h15
Pour que cela fonctionne, j'ai simplement renommé mon répertoire de sortie existant, afin de recréer tous les fichiers intermédiaires (après avoir essayé toutes les réponses acceptées ci-dessus).
J'ai eu du succès par le passé à utiliser DebugView dans VS2010 pour trouver des fichiers à supprimer, mais aujourd'hui cette approche ne fonctionnait pas. Je n'ai trouvé AUCUNE référence aux fichiers d'en-tête manquants, trouvés à l'aide de DebugView, dans aucun de mes fichiers de code ou de projet XML. J'ai également récupéré les fichiers obsolètes de TFS pour essayer avec eux présents et absents sur ma machine.
J'ai ensuite utilisé GREP pour effectuer une recherche dans tout le répertoire de la solution. Les seuls résultats obtenus étaient des fichiers binaires: les anciens fichiers de code * .obj, les fichiers de projet * .pdb et vc100.idb. Je ne sais pas comment ces fichiers sont modifiés/remplacés lors de la création ou de la reconstruction, je ne suis donc pas sûr qu'une référence précédente dans l'un de ces fichiers était responsable de l'affirmation que les anciens fichiers d'en-tête étaient manquants.
J'espère que cela aide quelqu'un sur la route, et merci pour l'info ci-dessus qui m'a permis de commencer!