web-dev-qa-db-fra.com

Résolution du problème de reconstruction AlwaysCreate dans Visual Studio 2010

J'ai un projet C++ que je porte actuellement de VS2008 à VS2010. Lorsque je crée le projet, Visual Studio 2010 indique que la création a abouti, mais si j'appuie sur F5 pour démarrer le débogueur, on me dit que le projet n'est pas à jour. Si j'ignore cet avertissement, je peux continuer le débogage, mais si j'appuie sur ok, tout le projet (plusieurs centaines de fichiers source) est reconstruit à partir de zéro. La sortie contient les éléments suivants:

1>------ Build started: Project: SCCW-VC2010, Configuration: Debug Win32 ------
1>Build started 15/11/2010 14:47:40.
1>InitializeBuildStatus:
1>  Creating "Debug\SCCW-VC2010.unsuccessfulbuild" because "AlwaysCreate" was specified.
1>Midl:
1>  All outputs are up-to-date.
1>ClCompile:
1>  tinedit.cpp
1>  _WIN32_WINNT not defined. Defaulting to _WIN32_WINNT_MAXVER (see WinSDKVer.h)
1>  Automatically linking with sfl504d.lib
1>  Automatically linking with ot1104d.lib
1>c:\program files\rogue wave\stingray studio 10.4\include\toolkit\sectndlg.h(134): warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
1>          c:\program files\Microsoft visual studio 10.0\vc\include\string.h(105) : see declaration of 'strcpy'
1>  Automatically linking with og1204d.lib
1>  Automatically linking with RWUXThemeD10.lib
1>  profile.cpp
1>  ZOffsetDialog.cpp

Une demi-heure plus tard, une fois la construction terminée, le débogueur démarre. Je suppose que le message 

Création de "Debug\SCCW-VC2010.unsuccessfulbuild" car "AlwaysCreate" a été spécifié.

fait partie du problème, mais je ne peux pas le lier à un projet. J'ai trouvé de l'aide sur google , mais rien n'a fonctionné jusqu'à présent. Quelqu'un d'autre a eu ce problème et connaissez une solution?

Edit: Comme suggéré par Jalf dans les commentaires ci-dessous, j'ai créé un nouveau projet, importé tous mes fichiers dans ce projet et le nouveau projet rencontre les mêmes problèmes. Plus précisément, j'ai copié sur tous les groupes suivants;

<ClCompile Include="..\MyDir\MyFile.cpp"/>
<ClInclude Include="..\MyDir\MyFile.h" />
<None Include="res\MyFile.ico" />  (and all similar resources)
<Library Include="..\MyDir\MyFile.lib" />

Edit2: Après avoir parcouru tous les en-têtes, j’en ai finalement trouvé 3 qui n’existaient pas. Le fait de les supprimer et de tout reconstruire sur le projet d'origine semble avoir résolu le problème. Certains des articles de blog qui mentionnent ce problème y font référence à un bogue et deux jours de temps perdu plus tard, j'ai tendance à être d'accord. Merci pour les réponses et les commentaires fournis.

Edit3: Et un jour plus tard, le problème est de retour! Toute modification dans un fichier du projet entraîne à nouveau une reconstruction complète. Selon la réponse de John Dibling, le projet inclut certaines bibliothèques statiques, y compris Stingray. Je laisse tomber VS2010 et je reviens à VS2008, car j'ai des délais. Pour des informations connexes, voir les liens suivants:

VS2010 pense toujours que le projet est obsolète mais rien n'a changé

http://social.msdn.Microsoft.com/Forums/en-US/vcgeneral/thread/38c08137-3bb0-4143-b97f-72d077646318

http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx

Final Edit La version de VS2010 SP1 a résolu ce problème. Les versions sont maintenant rapides et efficaces.

c++visual-studio-2010build
18
SmacL

J'ai eu ce problème plusieurs fois et c'était toujours frustrant. Je vais vous dire quel était le problème dans mon cas, mais je dois d'abord vous demander:

  • Avez-vous fait une reconstruction complète avant d'essayer de lancer la première fois ou juste une reconstruction?
  • Une fois que vous avez tout reconstruit, vous demande-t-il encore de reconstruire si vous n’avez apporté aucun changement?

Le problème dans mon cas était un peu complexe. J'avais des règles de construction personnalisées qui copient les fichiers binaires de Stingray de leur répertoire source (où ils habitaient) dans un répertoire de mon arbre de génération. Les fichiers binaires ont été marqués comme une dépendance, de sorte qu'ils ont été copiés avant chaque construction au cas où ils seraient modifiés.

La dépendance vérifiée a examiné l'horodatage de ces fichiers pour voir quand ils ont été modifiés. Si le blah.lib avait une date de modification de décembre dernier dans son répertoire source, il aurait alors la même date de modification. La dépendance vérifiée notera que "hé ce fichier est assez vieux, nous devons le reconstruire", et ensuite il me demanderait si je voulais faire une reconstruction complète.

Pendant un certain temps, je me suis contenté de dire "Non", mais j'ai finalement résolu le problème en modifiant la règle de construction personnalisée afin d'écrire un nouveau fichier texte après sa copie. Cela rendrait le nouveau fichier texte la dépendance, et non le fichier blah.lib, et rendrait le compilateur heureux.

8
John Dibling

  1. Voir dans la fenêtre de sortie quel fichier est reconstruit

  2. Allez dans le menu Tools-> Options, puis naviguez jusqu'au Project and Solutions-> Build and Run. Changez l'option MSBuild Project build output verbosity en:

    Diagnostic

  3. Construire, j'ai un long journal

  4. Rechercher le fichier (parmi 1) dans le journal, lire le diagnostic. Vous pouvez trouver, par exemple, le nom de l’en-tête dont la date est future ou absent.

12
xen

J'ai eu le même problème sur les deux projets convertis et à partir de zéro. J'ai eu un indice d'une page MS sur les fichiers manquants. J'ai vérifié mon projet et trouvé qu'il faisait référence à un fichier qui n'existait pas. Remplacé par le fichier correct, et le problème a disparu.

5
GTAE86

Je sais que c’est un très très vieux billet, mais pour le bénéfice de tous ceux qui ont encore ce problème, j’ai décidé de poster mes commentaires. Parce que "AlwaysCreate" était spécifié et n’avait aucun rapport avec la reconstruction du projet.

C’est l’inverse. Si vous ou Visual Studio décidez de tout reconstruire, cela provoque la création du fichier "* .unsuccessfulbuild".

Un autre problème (généralement l'en-tête qui n'existe pas) entraînera une reconstruction, ce qui conduira à l'affichage car "AlwaysCreate" a été spécifié.

"AlwaysCreate" fait partie des paramètres de l'environnement de génération de Visual Studio et du fichier XML Microsoft.CppBuild.targets. Il contient la ligne suivante: Touchez AlwaysCreate = "true" Files = "$ (LastBuildUnsuccessful)" /

Si ce paramètre est défini sur true, le fichier " .unsuccessfulbuild" sera toujours créé, que la construction soit réussie ou non. Si la valeur est false, ". Unsuccessfulbuild n'est pas créé. Si la valeur est true, le fichier * .unsuccessfulbuild est créé comme étant vide pendant la durée du processus de construction, puis supprimé si la construction réussit. Je ne suis pas sûr de la raison pour laquelle ce fichier a été créé: même si la construction contient des erreurs, le fichier est vide mais pas supprimé comme dans le cas d’une construction réussie.

L’existence de ce fichier a peut-être une signification connue uniquement de l’environnement de compilation de VS. Si vous souhaitez jouer avec ce réglage, supprimez la touche tactile de .

3
JohnCz

Les MSDN docs impliquent que cette propriété est spécifique aux projets de déploiement. 

findstr /si AlwaysCreate sur votre fichier de projet VS20 devrait vous montrer le ou les coupables si vous ne pouvez pas le localiser dans l'interface graphique.

2
Steve Townsend

S'il n'y a pas de raisons "légitimes" à la reconstruction constante (par exemple, des références à des fichiers d'en-tête manquants), essayez de supprimer le fichier .sdf de la solution (lorsque la solution est fermée, bien sûr) et de la reconstruire. Cela a juste fonctionné pour moi.

0
ulatekh

Le lien est dans l'un des commentaires ici, mais il est facile de le rater. Je republie donc les étapes de base depuis ce lien: Article MSDN

En fait, j'ai trouvé ce lien par moi-même, et ce n'est que plus tard que j'ai réalisé que cela avait déjà été mentionné ici.

1. Since it can be difficult to recover from a damaged devenv.exe.config file, consider copying the file to devenv.exe.config.original before modifying it so you have a backup copy you can revert to if things go awry.
2. Open your VisualStudioInstallFolder\Common7\IDE\devenv.exe.config file.  Note this will be in %ProgramFiles(x86)% on 64-bit Windows.
3. Open a text editor with admin privileges.
4. Add this snippet to your devenv.exe.config file just below the <configSections /> block:
    For Visual Studio 2012 and below...
    <system.diagnostics>
    <switches><add name="CPS" value="4" /></switches>
    </system.diagnostics>
    For Visual Studio 2013
    <system.diagnostics>
    <switches><add name="CPS" value="Verbose" /></switches>
    </system.diagnostics>
5. Save the text file.

J'utilise Visual Studio 2010 + SP1 et les deux extraits XML semblent fonctionner.

Vous avez maintenant besoin d’un outil capable d’afficher les fenêtres DebugOutput comme DebugView . 

1. Start DebugView 
2. Rebuild
3. Build
4. In DebugView window search for the string ‘missing’ or 'not up to date', better still to save the DebugView log entries and open it in notepad and then search.
0
Devolus

Nous avons décidé de revenir sur cette question avec la version finale du SP1. J'ai recréé un nouveau projet à partir de zéro, qui est sorti à 81k par rapport au projet plus ancien amélioré de 1,4 Mo qui transportait toutes sortes de déchets avec elle. Au départ, j'ai rencontré le même problème, mais j'ai réussi à le résoudre comme suit.

  • Modification des en-têtes pré-compilés en Créer (/ Yc)  
  • Compilé un fichier source 
  • Modification des en-têtes pré-compilés en Use (/ Yu)  
  • Fait une reconstruction complète

Le problème suivant que j’ai remarqué était que tout ajout de ressources entraînait une recompilation de tous les fichiers contenant notamment resource.h. Ce problème a été résolu à l’aide des conseils du fil de connexion Microsoft et l’ajout manuel des lignes suivantes à mon projet;

<ItemGroup>
    <ClNoDependencies Include="Resource.h" />
</ItemGroup>
0
SmacL

Dans mon cas, cela a semblé aider à construire le (s) projet (s) de déploiement. Je les ai mis de ne pas construire quand je frappe F7 mais manuellement. Certaines personnes suggèrent de créer une nouvelle solution + projets, mais ce n'est pas une très bonne option lorsque les projets comportent de nombreuses modifications manuelles et des règles de construction personnalisées.

0
Kari