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 s'il a été compilé et lié juste avant et F5est touché, la boîte de 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 paramètres pdb sont définis sur la valeur par défaut ( solution suggérée de 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 (plus faciles) pour VS2012, VS2013, etc.

Pour trouver le (s) fichier (s) manquant (s) , 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 vous dire simplement ce qui provoque la reconstruction:

1. Ouvrez le devenv.exe.configfichier (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 </configSections>ligne:

   <system.diagnostics>
     <switches>
       <add name="CPS" value="4" />
     </switches>
   </system.diagnostics>
   

3. Redémarrez Visual Studio
4. Ouvrez DbgView et assurez-vous qu'il capture la sortie de débogage
5. Essayez de déboguer (appuyez sur F5 dans Visual Studio)

6. Recherchez dans le journal de débogage toutes les lignes du formulaire:

   devenv.exe Information: 0: Le projet 'Bla \ Bla \ Dummy.vcxproj' n'est pas à jour car l'entrée de build 'Bla \ Bla \ SomeFile.h' est manquante.

   (Je viens d'appuyer sur Ctrl + F et j'ai recherché 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:

<system.diagnostics>
  <switches>
   <add name="CPS" value="Verbose" />
  </switches>
</system.diagnostics>

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 Outils → Options → Projets et solutions → Construire et exécuter → * Verbosité de sortie de la construction du projet MSBuild "de Minimal à Diagnostic .

Ensuite, dans la sortie de la construction, j'ai trouvé les mêmes lignes en recherchant "pas à jour":

Le projet «blabla» n'est pas à jour. L'élément de projet «c: \ foo \ bar.xml» a l'attribut «Copier dans le répertoire de sortie» défini sur «Copier toujours».

Cela m'est arrivé aujourd'hui. J'ai pu retrouver 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 accédant à la «vue des fichiers inclus» et en cliquant successivement sur chaque fichier inclus jusqu'à ce que vous trouviez celui que Visual Studio ne trouve pas. Vous ajoutez ensuite ce fichier (en tant qu'élément existant) et supprimez la référence qui ne peut pas être trouvée et tout est OK.

Une question valide est: comment Visual Studio peut-il même générer s'il ne sait pas où se trouvent les fichiers include?

Nous pensons que le fichier .vcproj a un chemin d'accès relatif au fichier incriminé quelque part qu'il ne s'affiche pas dans l'interface graphique de Visual Studio, et cela explique pourquoi le projet sera réellement construit même si l'arborescence des inclusions est incorrecte.

La réponse acceptée m'a aidé à trouver le moyen de résoudre ce problème pour le projet foutu avec lequel je devais commencer à travailler. Cependant, j'ai dû faire face à un très grand nombre d'en-têtes Bad include. Avec la sortie de débogage détaillée, la suppression de celle-ci a provoqué le blocage de l'IDE pendant 30 secondes lors de la sortie du débogage, ce qui a ralenti le processus.

Je suis devenu impatient et j'ai écrit un script Python rapide et sale pour vérifier les fichiers de projet (Visual Studio 2010) pour moi et sortir tous les fichiers manquants en même temps, ainsi que les filtres dans lesquels ils se trouvent. Vous pouvez le trouver en tant que Gist ici: https://gist.github.com/antiuniverse/3825678 (ou cette fourchette 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   (cstrike\fx_cs_blood.h)
  hud_radar.h   (cstrike\hud_radar.h)
[Game Shared Header Files]:
  basecsgrenade_projectile.h   (..\shared\cstrike\basecsgrenade_projectile.h)
  fx_cs_shared.h   (..\shared\cstrike\fx_cs_shared.h)
  weapon_flashbang.h   (..\shared\cstrike\weapon_flashbang.h)
  weapon_hegrenade.h   (..\shared\cstrike\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 cpp et quelques fichiers d'en-tête de la solution (et du disque) mais j'ai toujours eu le problème.

Le fait est que chaque fichier utilisé par le compilateur est stocké dans un fichier * .tlog de votre répertoire temporaire. Lorsque vous supprimez un fichier, ce fichier * .tlog n'est pas mis à jour. C'est le fichier utilisé par les builds incrémentiels pour vérifier si votre projet est à jour.

Modifiez ce fichier .tlog manuellement 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 définition du fichier de sortie pdb: j'ai oublié le suffixe .pdb (je l'ai découvert avec l'astuce de journalisation du débogage).

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

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

à

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>

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

1. "Forcing recompile 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 de votre compilateur (sous Paramètres du projet: «C / C ++» -> «Format des informations de débogage» sur «Aucun» et «Linker» -> «Générer des informations de débogage» sur «Non»:) . Si vous avez laissé «C / C ++» -> «Program Database File Name» par défaut (qui est «$ (IntDir) vc $ (PlatformToolsetVersion) .pdb»), VS ne trouvera pas le fichier en raison d'un bogue ( https : //connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds ).
   Pour le corriger, effacez simplement le nom du fichier sur "" (champ vide).

2. "Forcing rebuild of all source files due to a change in the command line since the last build."
   Cela semble également être un bogue VS connu ( 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 versions plus récentes (mais pas VS2013). Je ne connaissais aucune solution de contournement, mais si vous le faites, par tous les moyens, postez-le ici.

Je ne sais pas si quelqu'un d'autre a ce même problème, mais les propriétés de mon projet étaient "Configuration Properties" -> C/C++ -> "Debug Information Format"définies sur "Aucune", et lorsque je l'ai remis à la "Base de données de programme (/ Zi)" par défaut, cela a empêché le projet de recompiler à chaque fois .

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

Modification de la configuration: menu Outils → Options → Projets et solutions → Paramè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.

Visual Studio 2013 - "Forcer la recompilation de tous les fichiers source en raison de la PDB manquante". J'ai activé la sortie de génération détaillée pour localiser le problème: j'ai activé la sortie de génération «détaillée» sous «Outils» → «Projets et solutions» → «Créer et exécuter».

J'ai eu plusieurs projets, tous en C ++, j'ai défini l'option pour sous les paramètres du projet: (C / C ++ → Format des informations de débogage) sur Program Database (/ Zi) pour le projet à problème. Cependant, cela n'a pas arrêté le problème pour ce projet. Le problème provenait de l'un des autres projets C ++ de la solution.

Je mets tout 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 projet problématique. Essayez de définir tous les projets sur "Program Database (/ Zi)" pour résoudre le problème.

J'ai rencontré ce problème aujourd'hui, mais c'était un peu différent. J'avais un projet DLL CUDA dans ma solution. La compilation dans une solution propre était OK, mais sinon elle a échoué et le compilateur a toujours traité le projet DLL CUDA comme non à jour.

J'ai essayé la solution de ce post .

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

J'ai déjà changé le répertoire intermédiaire du projet, bien qu'il n'ait pas causé de problème. Et maintenant, lorsque j'ai changé le répertoire intermédiaire du projet CUDA DLL en $ (Configuration) \, tout fonctionne à nouveau correctement.

Je suppose qu'il y a un problème mineur entre la personnalisation de la construction CUDA et le répertoire intermédiaire non 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 gratter 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 requis par le projet pour construire (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 à %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%. Il existe deux fichiers similaires devenv.exe.config.configet devenv.exe.config. Vous voulez en changer un plus tard.

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

3. J'essayais de comprendre comment connecter DebugView à l'IDE pour voir les fichiers manquants. Eh bien, vous n'avez rien à faire. Il suffit de l'exécuter et il capturera tous les messages. Assurez-vous que l' Capture Eventsoption de menu est sélectionnée dans le Capturemenu qui, par défaut, doit être sélectionné.

4. DebugView n'affichera PAS tous les fichiers manquants à la fois (du moins, ce n'était pas le cas pour moi)! Vous auriez DebugView en cours d'exécution et ensuite exécuter le projet dans Visual Studio 2010. Il affichera le project out of datemessage, 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 vaut mieux fermer votre projet et le rouvrir à nouveau tout en faisant cette suppression. Répétez ce processus jusqu'à ce que DebugView ne montre plus aucun fichier manquant.

5. Il est utile de définir le filtre de messages pour qu'il ne soit pas à jour à partir du bouton de la barre d'outils DebugView ou de l' option Édition → Filtre / Surbrillance . De cette façon, les seuls messages qu'il affiche sont ceux qui contiennent une chaîne «pas à jour».

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

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

Il existe une deuxième façon de rechercher ces fichiers en une seule fois, mais cela implique (a) le contrôle de la source et (b) l'intégration de celui-ci avec Visual Studio 2010. À l'aide de Visual Studio 2010 , ajoutez votre projet à un emplacement souhaité ou à un emplacement factice dans la source contrôle. Il essaiera d'ajouter tous les fichiers, y compris ceux qui n'existent pas également sur le disque mais référencés dans le fichier de projet. Accédez à votre logiciel de contrôle de source comme Perforce , et il devrait marquer ces fichiers qui n'existent pas sur le disque dans un jeu de couleurs différent. Perforce les montre avec un verrou noir sur eux. Ce sont vos références manquantes. Vous en avez maintenant une liste et vous pouvez tous les supprimer de votre fichier de projet à l'aide du Bloc-notes et votre projet ne se plaindra pas d'être obsolète .

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

========== Build: 0 réussi, 0 échoué, 5 à jour, 0 ignoré ==========

et aucune tentative de reconstruction sans modification n'a été faite. Je pense que c'est une vérification avant construction implémentée par VS2010 (je ne sais pas si elle est documentée, pourrait l'être) qui déclenche le drapeau "AlwaysCreate".

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

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

Comme indiqué ici (avertissement: verbosité MSDN habituelle). Lorsque la construction est terminée, la recherche de la chaîne will be compileddans le fichier journal créé lors de la construction, MyLog.log.

J'utilise Visual Studio 2013 Professional avec la mise à jour 4 mais je n'ai trouvé de résolution avec aucune des autres suggestions, cependant, j'ai réussi à résoudre le problème pour mon projet d'équipe.

Voici ce que j'ai fait pour causer le problème -

• Création d'un nouvel objet de classe (Projet -> Ajouter une classe)
• Renommé le fichier via l'Explorateur de solutions et cliqué sur Oui lorsqu'on m'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 -

• Accédez à la page d'accueil de Team Explorer
• Cliquez sur Source Control Explorer
• Explorez le dossier où se trouvent tous les fichiers de classe / projet
• Trouver le nom de fichier ORIGINAL dans la liste et le supprimer via un clic droit
• Construire

Si c'est le cas pour vous, assurez-vous simplement de supprimer le fichier fantôme plutôt que le fichier réel 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 ++ constamment à jour ( winwlm.h macwin32.h rpcerr.h macname1.hmanquant)

Problème:

Dans Visual C ++ .Net 2003, l'un de mes projets a toujours prétendu être obsolète, même si rien n'avait changé et aucune erreur n'avait été signalée dans 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 aucune 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:

Inclure afxres.hau lieu de l' resource.hintérieur du fichier .rc du projet.

Le fichier .rc du projet contenait "#include resource.h". Comme le compilateur de ressources n'honore pas les #ifdefblocs du préprocesseur , il déchirera et essaiera de trouver les fichiers d'inclusion qu'il devrait ignorer. Windows.h contient de nombreux blocs de ce type. L'inclusion de afxres.h a plutôt corrigé les avertissements du PRJ0041 et éliminé la boîte de dialogue 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 amené Visual Studio à compiler les fichiers IDL sur chaque génération, même sans modification d'aucun 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é Fichier DllData

J'ai passé de nombreuses heures à m'arracher les cheveux. La sortie de génération n'était pas cohérente; différents projets ne seraient «pas à jour» pour différentes raisons d'une génération à la suivante. 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 sais pas si c'est la raison), mais DropBox "touche" en quelque sorte les fichiers pendant une construction. Synchronisation interrompue et tout est constamment à jour.

Il existe de nombreuses 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 indiquée serait explicite et vous seriez en mesure d'agir immédiatement, MAIS occasionnellement MSBuild prétendrait à tort que certains fichiers sont modifiés et doivent être copiés.

Si tel est le cas, vous devez désactiver la tunnellisation NTFS ou dupliquer votre dossier de sortie vers un nouvel emplacement. Le voici en plus de mots.

Cela m'est arrivé plusieurs fois, puis je suis parti avant de pouvoir comprendre pourquoi. Dans mon cas, c'était:

Heure système incorrecte dans la configuration à double démarrage!

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

Par malchance, j'ai construit le projet une fois, avec la mauvaise heure système, puis corrigé l'heure. En conséquence, tous les fichiers de construction avaient des horodatages incorrects, et VS penserait qu'ils sont tous obsolètes et reconstruirait le projet.

La plupart des systèmes de génération utilisent des horodatages de données pour déterminer quand les reconstructions doivent avoir lieu - l'horodatage de tous les fichiers de sortie est vérifié par rapport à la dernière heure modifiée des dépendances - si l'une des dépendances est plus récente, la cible est reconstruite.

Cela peut provoquer des problèmes si l'une des dépendances obtient en quelque sorte un horodatage de données non valide car il est difficile pour l'horodatage d'une sortie de génération de dépasser jamais l'horodatage d'un fichier supposément créé à l'avenir: P

Pour moi, le problème est survenu dans un projet WPF où certains fichiers avaient leur propriété "Build Action" définie sur "Resource" et leur "Copy to Output Directory" défini sur "Copy if newer". La solution semblait être de changer la propriété «Copier dans le répertoire de sortie» en «Ne pas copier».

msbuild sait qu'il ne faut pas copier les fichiers 'Resource' dans la sortie - mais déclenche quand même une construction s'ils n'y sont pas. Peut-être que cela pourrait être considéré comme un bug?

Il est extrêmement utile avec les réponses ici, indiquant comment obtenir msbuild pour renverser les haricots sur pourquoi il continue de tout construire!

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

J'ai eu un problème similaire avec Visual Studio 2005, et ma solution consistait en cinq projets dans la dépendance suivante (d'abord construite en haut):

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 construction complète même après un nettoyage complet puis une reconstruction de la solution.

J'ai corrigé cela en m'assurant que le pdbfichier de sortie du C / C ++ et de l'éditeur de liens correspondait à l'emplacement utilisé par les autres projets de travail. J'ai également activé 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 qu'en quelque sorte un mauvais fichier cpp était utilisé pour les en-têtes précompilés (j'avais donc deux fichiers cpp qui créaient les en-têtes précompilés). Maintenant, pourquoi Visual Studio a-t-il modifié les indicateurs sur le mauvais cpp pour 'créer des en-têtes précompilés' sans ma demande, je n'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é sur chaque build. Visual Studio reconstruit donc tous les en-têtes et à cause de cela l'ensemble du projet.

Eh bien, maintenant, il revient à un comportement normal.

J'avais un projet VC ++ qui compilait toujours tous les fichiers et avait été précédemment mis à niveau de VS2005 à VS2010 (par d'autres personnes). J'ai trouvé que tous les fichiers cpp du projet, à l'exception de StdAfx.cpp, étaient définis pour créer (/ Yc) l'en-tête précompilé. J'ai changé cela afin que seul StdAfx.cpp ait été défini pour créer l'en-tête précompilé et le reste a été défini sur Utiliser (/ Yu) l'en-tête précompilé et cela a résolu le problème pour moi.

Je suis sur Visual Studio 2013 et je viens de mettre à jour la mise à jour de Windows 10 de mai 2019 et la compilation a soudainement dû être refaite à chaque fois, indépendamment des modifications. J'ai essayé de renommer le pch en ProjectName au lieu de TargetName, j'ai cherché les fichiers manquants avec le journal détaillé et ce script Python, mais à la fin, c'était mon temps n'était pas synchronisé avec les serveurs de MS (par comme millisecondes).

Ce qui a résolu cela pour moi était

• "Ajuster la date et l'heure" dans le panneau de commande
• "Synchroniser maintenant"

Maintenant, mes projets n'ont plus besoin d'être recompilés sans raison.

Je pense que vous avez placé une nouvelle ligne ou un autre espace blanc. Retirez-le et appuyez à nouveau sur F5.

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