Visual Studio 2010 hält das Projekt immer für veraltet, aber nichts hat sich geändert

Ich habe ein sehr ähnliches Problem wie beschrieben hier .

Ich habe auch eine gemischte Lösung von C ++ / CLI- und C # -Projekten von Visual Studio 2008 auf Visual Studio 2010 aktualisiert. In Visual Studio 2010 ist ein C ++ / CLI-Projekt immer veraltet.

Auch wenn es kurz vor und kompiliert und verlinkt wurde F5 getroffen wird, erscheint die Meldung "Das Projekt ist veraltet. Möchten Sie es erstellen?" erscheint. Dies ist sehr ärgerlich, da die DLL-Datei sehr niedrig ist und fast alle Projekte der Lösung zur Neuerstellung zwingt.

Meine PDF-Einstellungen sind auf den Standardwert eingestellt ( Lösungsvorschlag für dieses Problem ).

Ist es möglich, den Grund dafür zu ermitteln, warum Visual Studio 2010 eine Neuerstellung erzwingt oder ein Projekt für aktuell hält?

Irgendwelche anderen Ideen, warum sich Visual Studio 2010 so verhält?

Nur für Visual Studio / Express 2010. Weitere (einfachere) Antworten für VS2012, VS2013 usw.

Um die fehlenden Dateien zu finden , verwenden Sie die Informationen aus dem Artikel Aktivieren der C ++ - Projektsystemprotokollierung , um die Debugprotokollierung in Visual Studio zu aktivieren, und lassen Sie sich nur sagen, was die Neuerstellung verursacht:

1. Öffnen Sie die devenv.exe.configDatei (gefunden in %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\oder in %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\). Bei Express-Versionen wird die Konfigurationsdatei benannt V*Express.exe.config.

2. Fügen Sie nach der </configSections>Zeile Folgendes hinzu:

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

3. Starten Sie Visual Studio neu
4. Öffnen Sie DbgView und stellen Sie sicher, dass die Debug-Ausgabe erfasst wird
5. Versuchen Sie zu debuggen (drücken Sie F5 in Visual Studio)

6. Durchsuchen Sie das Debug-Protokoll nach Zeilen des Formulars:

   devenv.exe Information: 0: Das Projekt 'Bla \ Bla \ Dummy.vcxproj' ist nicht aktuell, da die Build-Eingabe 'Bla \ Bla \ SomeFile.h' fehlt.

   (Ich habe gerade Strg + F gedrückt und gesucht not up to date) Dies sind die Referenzen, die dazu führen, dass das Projekt ständig "veraltet" ist.

Um dies zu korrigieren, entfernen Sie entweder alle Verweise auf die fehlenden Dateien aus Ihrem Projekt oder aktualisieren Sie die Verweise, um deren tatsächlichen Speicherort anzugeben.

Hinweis: Wenn Sie 2012 oder höher verwenden, sollte das Snippet wie folgt lauten:

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

In Visual Studio 2012 konnte ich das gleiche Ergebnis einfacher erzielen als in der akzeptierten Lösung.

Ich habe die Option im Menü Extras → Optionen → Projekte und Lösungen → Erstellen und Ausführen → * Ausführlichkeit der Ausgabe des MSBuild-Projekts "von" Minimal " in" Diagnose " geändert .

Dann fand ich in der Build-Ausgabe die gleichen Zeilen, indem ich nach "nicht aktuell" suchte:

Das Projekt 'blabla' ist nicht aktuell. Für das Projektelement 'c: \ foo \ bar.xml' wurde das Attribut 'In Ausgabeverzeichnis kopieren' auf 'Immer kopieren' gesetzt.

Das ist mir heute passiert. Ich konnte die Ursache ausfindig machen: Das Projekt enthielt eine Header-Datei, die nicht mehr auf der Festplatte vorhanden war.

Das Entfernen der Datei aus dem Projekt löste das Problem.

Wir sind auch auf dieses Problem gestoßen und haben herausgefunden, wie es behoben werden kann.

Das Problem war wie oben angegeben: "Die Datei ist nicht mehr auf der Festplatte vorhanden."

Das ist nicht ganz richtig. Die Datei ist auf der Festplatte vorhanden, aber die VCPROJ-Datei verweist auf die Datei an einer anderen Stelle.

Sie können dies "entdecken", indem Sie in der Ansicht "Include-Datei" nacheinander auf jede Include-Datei klicken, bis Sie diejenige finden, die Visual Studio nicht finden kann. Anschließend fügen Sie diese Datei (als vorhandenes Element) hinzu und löschen die Referenz, die nicht gefunden werden kann, und alles ist in Ordnung.

Eine gültige Frage lautet: Wie kann Visual Studio überhaupt erstellen, wenn es nicht weiß, wo sich die Include-Dateien befinden?

Wir glauben, dass die .vcproj-Datei einen relativen Pfad zu der fehlerhaften Datei hat, der nicht in der Visual Studio-GUI angezeigt wird, und dies erklärt, warum das Projekt tatsächlich erstellt wird, obwohl die Baumansicht der Includes falsch ist.

Die akzeptierte Antwort half mir auf dem richtigen Weg, um herauszufinden, wie ich dieses Problem für das vermasselte Projekt lösen konnte, mit dem ich anfangen musste zu arbeiten. Ich musste mich jedoch mit einer sehr großen Anzahl von fehlerhaften Include-Headern auseinandersetzen. Bei der ausführlichen Debug-Ausgabe hat das Entfernen einer IDE 30 Sekunden lang eingefroren, während die Debug-Ausgabe ausgegeben wurde, wodurch der Prozess sehr langsam ablief.

Ich wurde ungeduldig und schrieb ein schnelles und schmutziges Python-Skript, um die (Visual Studio 2010) Projektdateien für mich zu überprüfen und alle fehlenden Dateien auf einmal zusammen mit den Filtern auszugeben, in denen sie sich befinden. Sie finden es als Geben Sie hier Folgendes an: https://gist.github.com/antiuniverse/3825678 (oder diese Gabelung, die relative Pfade unterstützt )

Beispiel:

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)
  ...

Quellcode:

#!/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 + ")")

Ich habe eine CPP und einige Header-Dateien von der Lösung (und von der Festplatte) gelöscht, hatte aber immer noch das Problem.

Jede Datei, die der Compiler verwendet, befindet sich in einer * .tlog-Datei in Ihrem temporären Verzeichnis. Wenn Sie eine Datei entfernen, wird diese * .tlog-Datei nicht aktualisiert. Dies ist die Datei, die von inkrementellen Builds verwendet wird, um zu überprüfen, ob Ihr Projekt auf dem neuesten Stand ist.

Bearbeiten Sie diese .tlog-Datei entweder manuell oder bereinigen Sie Ihr Projekt und erstellen Sie es neu.

Ich hatte ein ähnliches Problem, aber in meinem Fall fehlten keine Dateien. Es gab einen Fehler bei der Definition der PDF-Ausgabedatei: Ich habe das Suffix .pdb vergessen (ich habe es mit dem Debug-Protokollierungstrick herausgefunden).

Um das Problem zu lösen, habe ich in der Datei vxproj die folgende Zeile geändert:

<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>

zu

<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>

Ich hatte dieses Problem in VS2013 (Update 5) und es kann zwei Gründe dafür geben, die Sie beide finden können, indem Sie "Detaillierte" Build-Ausgabe unter "Tools" -> "Projekte und Lösungen" -> "Build and Run" aktivieren. .

1. "Forcing recompile of all source files due to missing PDB "..."
   Dies geschieht, wenn Sie die Ausgabe von Debug-Informationen in Ihren Compiler-Optionen deaktivieren (Unter Projekteinstellungen: „C / C ++“ -> „Debug-Informationsformat“ auf „Keine“ und „Linker“ -> „Debug-Informationen generieren“ auf „Nein“ :) . Wenn Sie „C / C ++“ -> „Name der Programmdatenbankdatei“ standardmäßig verlassen haben (dies ist „$ (IntDir) vc $ (PlatformToolsetVersion) .pdb“), findet VS die Datei aufgrund eines Fehlers ( https) nicht : //connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds ).
   Um dies zu beheben, löschen Sie einfach den Dateinamen auf "" (leeres Feld).

2. "Forcing rebuild of all source files due to a change in the command line since the last build."
   Dies scheint auch ein bekannter VS-Fehler zu sein ( https://connect.microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due-to-a-change-in- die-Befehlszeile seit dem letzten Build ) und scheint in neueren Versionen (aber nicht VS2013) behoben zu sein. Ich kannte keine Problemumgehung, aber wenn Sie dies tun, posten Sie es auf jeden Fall hier.

Ich weiß nicht, ob jemand anderes das gleiche Problem hat, aber die Eigenschaften meines Projekts wurden "Configuration Properties" -> C/C++ -> "Debug Information Format"auf "Keine" gesetzt, und als ich es wieder auf die Standard "Programmdatenbank (/ Zi)" zurückstellte, konnte das Projekt nicht jedes Mal neu kompiliert werden .

Eine weitere einfache Lösung, auf die das Visual Studio Forum verweist .

Ändern der Konfiguration: Menü Extras → Optionen → Projekte und Lösungen → VC ++ - Projekteinstellungen → Projektmappen- Explorer-Modus, um alle Dateien anzuzeigen .

Anschließend können Sie alle Dateien im Projektmappen-Explorer anzeigen.

Suchen Sie die mit dem gelben Symbol gekennzeichneten Dateien und entfernen Sie sie aus dem Projekt.

Es ist in Ordnung.

Visual Studio 2013 - "Erzwingen der Neukompilierung aller Quelldateien aufgrund fehlenden PDB". Ich habe die detaillierte Build-Ausgabe aktiviert, um das Problem zu lokalisieren: Ich habe die "detaillierte" Build-Ausgabe unter "Tools" → "Projekte und Lösungen" → "Build and Run" aktiviert.

Ich hatte mehrere Projekte, alle C ++, ich habe die Option für unter Projekteinstellungen festgelegt: (C / C ++ → Debug-Informationsformat) auf Programmdatenbank (/ Zi) für das Problemprojekt. Dies hat das Problem für dieses Projekt jedoch nicht gestoppt. Das Problem kam von einem der anderen C ++ - Projekte in der Lösung.

Ich habe alle C ++ - Projekte auf "Program Database (/ Zi)" gesetzt. Dies hat das Problem behoben.

Auch hier war das Projekt, das das Problem meldete, nicht das Problemprojekt. Versuchen Sie, alle Projekte auf "Programmdatenbank (/ Zi)" zu setzen, um das Problem zu beheben.

Ich bin heute auf dieses Problem gestoßen, aber es war ein bisschen anders. Ich hatte ein CUDA-DLL-Projekt in meiner Lösung. Das Kompilieren in einer sauberen Lösung war in Ordnung, aber ansonsten schlug es fehl und der Compiler behandelte das CUDA-DLL-Projekt immer als nicht aktuell.

Ich habe die Lösung aus diesem Beitrag ausprobiert .

In meiner Lösung fehlt jedoch keine Header-Datei. Dann fand ich den Grund in meinem Fall heraus.

Ich habe das Zwischenverzeichnis des Projekts bereits geändert, obwohl es keine Probleme verursacht hat. Und jetzt, als ich das Zwischenverzeichnis des CUDA DLL-Projekts wieder in $ (Konfiguration) \ geändert habe, funktioniert alles wieder richtig.

Ich denke, es gibt ein kleines Problem zwischen der CUDA-Build-Anpassung und dem nicht standardmäßigen Zwischenverzeichnis.

Ich hatte ein ähnliches Problem und befolgte die obigen Anweisungen (die akzeptierte Antwort), um die fehlenden Dateien zu finden, aber nicht ohne meinen Kopf zu kratzen. Hier ist meine Zusammenfassung dessen, was ich getan habe. Um genau zu sein, fehlen keine Dateien, da sie vom Projekt nicht erstellt werden müssen (zumindest in meinem Fall), sondern Verweise auf Dateien, die nicht auf der Festplatte vorhanden sind und nicht wirklich benötigt werden.

Hier ist meine Geschichte:

1. Unter Windows 7 befindet sich die Datei unter %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%. Es gibt zwei ähnliche Dateien devenv.exe.config.configund devenv.exe.config. Sie möchten später eine ändern.

2. Unter Windows 7 haben Sie keine Berechtigung zum Bearbeiten dieser Datei in Programmdateien. Kopieren Sie es einfach an eine andere Stelle (Desktop), ändern Sie es und kopieren Sie es zurück in den Speicherort der Programmdateien.

3. Ich habe versucht herauszufinden, wie DebugView mit der IDE verbunden werden kann, um die fehlenden Dateien anzuzeigen . Du musst nichts tun. Führen Sie es einfach aus, und es werden alle Nachrichten erfasst. Stellen Sie sicher, dass Capture Eventsim CaptureMenü die Menüoption ausgewählt ist, die standardmäßig ausgewählt werden soll.

4. DebugView zeigt NICHT alle fehlenden Dateien auf einmal an (zumindest nicht für mich)! Sie würden DebugView ausführen lassen und dann das Projekt in Visual Studio 2010 ausführen. Es wird die project out of dateMeldung angezeigt , wählen Sie Ja zum Erstellen und DebugView zeigt die erste Datei an, die fehlt oder die Neuerstellung verursacht. Öffnen Sie die Projektdatei (keine Lösungsdatei) im Editor, suchen Sie nach dieser Datei und löschen Sie sie. Schließen Sie Ihr Projekt besser und öffnen Sie es erneut, während Sie diesen Löschvorgang ausführen. Wiederholen Sie diesen Vorgang, bis in DebugView keine fehlenden Dateien mehr angezeigt werden.

5. Es ist hilfreich, den Nachrichtenfilter über die DebugView-Symbolleistenschaltfläche oder die Option Bearbeiten → Filter / Hervorheben auf nicht aktuell einzustellen . Auf diese Weise werden nur Nachrichten angezeigt, die die Zeichenfolge "Nicht aktuell" enthalten.

Ich hatte viele Dateien, die unnötige Verweise waren, und das Entfernen aller Dateien behebt das Problem gemäß den obigen Schritten.

Zweiter Weg, um alle fehlenden Dateien auf einmal zu finden

Es gibt eine zweite Möglichkeit, diese Dateien auf einmal zu finden. Sie umfasst jedoch (a) die Quellcodeverwaltung und (b) die Integration in Visual Studio 2010. Fügen Sie Ihr Projekt mit Visual Studio 2010 einem gewünschten Speicherort oder Dummy-Speicherort in der Quelle hinzu Steuerung. Es wird versucht, alle Dateien hinzuzufügen, einschließlich derjenigen, die nicht auf der Festplatte vorhanden sind, auf die jedoch in der Projektdatei verwiesen wird. Gehen Sie zu Ihrer Versionsverwaltungssoftware wie Perforce , und diese Dateien, die nicht auf der Festplatte vorhanden sind, sollten in einem anderen Farbschema markiert werden. Perforce zeigt sie mit einem schwarzen Schloss. Dies sind Ihre fehlenden Referenzen. Jetzt haben Sie eine Liste von allen, und Sie können alle mit Notepad aus Ihrer Projektdatei löschen, und Ihr Projekt würde sich nicht darüber beschweren, dass es veraltet ist .

Für mich war es das Vorhandensein einer nicht vorhandenen Header-Datei unter "Header-Dateien" im Projekt. Nachdem Sie diesen Eintrag entfernt haben (Rechtsklick> Aus Projekt ausschließen), werden Sie ihn zuerst neu kompiliert und dann direkt

========== Build: 0 erfolgreich, 0 fehlgeschlagen, 5 aktuell, 0 übersprungen ==========

und es wurde kein Versuch unternommen, ohne Modifikation wieder aufzubauen. Ich denke, es handelt sich um eine von VS2010 implementierte Prüfung vor dem Erstellen (nicht sicher, ob dies dokumentiert ist), die das Flag "AlwaysCreate" auslöst.

Wenn Sie den Befehlszeilenbefehl MSBuild verwenden (nicht die Visual Studio-IDE), z. B. wenn Sie AppVeyor als Ziel festlegen oder nur die Befehlszeile bevorzugen, können Sie diese Option zu Ihrer MSBuild-Befehlszeile hinzufügen:

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

Wie hier dokumentiert (Warnung: übliche MSDN-Ausführlichkeit). Wenn der Build abgeschlossen ist, suchen Sie nach der Zeichenfolge will be compiledin der Protokolldatei, die während des Builds erstellt wurde MyLog.log.

Ich verwende Visual Studio 2013 Professional mit Update 4, habe jedoch mit keinem der anderen Vorschläge eine Lösung gefunden. Es ist mir jedoch gelungen, das Problem für mein Teamprojekt zu beheben.

Folgendes habe ich getan, um das Problem zu verursachen:

• Neues Klassenobjekt erstellt (Projekt -> Klasse hinzufügen)
• Benennen Sie die Datei über den Projektmappen-Explorer um und klicken Sie auf Ja, wenn Sie gefragt werden, ob ich alle übereinstimmenden Verweise automatisch umbenennen möchte

Folgendes habe ich getan, um das Problem zu lösen:

• Gehen Sie zu Team Explorer Home
• Klicken Sie auf Versionsverwaltungs-Explorer
• Bohren Sie in den Ordner, in dem sich alle Klassen- / Projektdateien befinden
• Den ORIGINAL-Dateinamen in der Liste gefunden und per Rechtsklick gelöscht
• Bauen

Wenn dies bei Ihnen der Fall ist, stellen Sie sicher, dass Sie die Phantomdatei löschen und nicht die eigentliche, die Sie im Projekt behalten möchten.

Ich hatte dieses Problem und fand Folgendes:

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

Visual C ++ - Projekt ständig veraltet ( winwlm.h macwin32.h rpcerr.h macname1.hfehlt)

Problem:

In Visual C ++ .Net 2003 gab eines meiner Projekte immer an, veraltet zu sein, obwohl sich nichts geändert hatte und im letzten Build keine Fehler gemeldet wurden.

Beim Öffnen der Datei BuildLog.htm für das entsprechende Projekt wurde eine Liste von PRJ0041-Fehlern für diese Dateien angezeigt, von denen keiner auf meinem System irgendwo angezeigt wird: winwlm.h macwin32.h rpcerr.h macname1.h

Jeder Fehler sieht ungefähr so ​​aus:

  MyApplication : warning PRJ0041 : Cannot find missing dependency 'macwin32.h' for file 'MyApplication.rc'.  

Ihr Projekt wird möglicherweise noch erstellt, aber möglicherweise weiterhin veraltet angezeigt, bis diese Datei gefunden wird.

Lösung:

Einfügen afxres.hstatt resource.hin die RC-Datei des Projekts.

Die RC-Datei des Projekts enthielt "#include resource.h". Da der Ressourcen-Compiler Präprozessorblöcke nicht berücksichtigt #ifdef, wird er durchbrechen und versuchen, Include-Dateien zu finden, die ignoriert werden sollten. Windows.h enthält viele solcher Blöcke. Das Einbeziehen von afxres.h hat stattdessen die PRJ0041-Warnungen behoben und den Fehlerdialog "Projekt ist veraltet" beseitigt.

In meinem Fall enthält eines der Projekte mehrere IDL-Dateien. Der MIDL-Compiler generiert für jede von ihnen eine DLL-Datendatei mit dem Namen 'dlldata.c', unabhängig vom IDL-Dateinamen. Dies führte dazu, dass Visual Studio die IDL-Dateien bei jedem Build kompilierte, auch ohne Änderungen an den IDL-Dateien.

Die Problemumgehung besteht darin, für jede IDL-Datei eine eindeutige Ausgabedatei zu konfigurieren (der MIDL-Compiler generiert immer eine solche Datei, auch wenn der Schalter / dlldata weggelassen wird):

• Klicken Sie mit der rechten Maustaste auf die IDL-Datei
• Wählen Sie Eigenschaften - MIDL - Ausgabe
• Geben Sie einen eindeutigen Dateinamen für die Eigenschaft DllData File ein

Ich habe viele Stunden damit verbracht, mir darüber die Haare auszureißen. Die Build-Ausgabe war nicht konsistent. Unterschiedliche Projekte wären aus unterschiedlichen Gründen von einem Build zum nächsten aufeinanderfolgenden Build "nicht aktuell". Ich fand schließlich heraus, dass der Schuldige DropBox (3.0.4) war. Ich verbinde meinen Quellordner von ... \ DropBox mit meinem Projektordner (nicht sicher, ob dies der Grund ist), aber DropBox "berührt" Dateien während eines Builds irgendwie . Die Synchronisierung wurde unterbrochen und alles ist stets auf dem neuesten Stand.

Es gibt einige mögliche Gründe, und wie bereits erwähnt, müssen Sie diese zuerst diagnostizieren, indem Sie die MSBuild-Ausführlichkeit auf "Diagnose" setzen. Meistens ist der angegebene Grund selbsterklärend und Sie können sofort darauf reagieren, ABER gelegentlich behauptet MSBuild fälschlicherweise, dass einige Dateien geändert wurden und kopiert werden müssen.

In diesem Fall müssen Sie entweder das NTFS-Tunneling deaktivieren oder Ihren Ausgabeordner an einen neuen Speicherort duplizieren. Hier ist es in mehr Worten.

Das passierte mir mehrmals und ging dann weg, bevor ich herausfinden konnte warum. In meinem Fall war es:

Falsche Systemzeit im Dual-Boot-Setup!

Es stellte sich heraus, dass mein Dual-Boot mit Ubuntu die Hauptursache war !! Ich war zu faul, um Ubuntu zu reparieren und nicht mehr mit meiner Hardware-Uhr herumzuspielen. Wenn ich mich bei Ubuntu anmelde, springt die Zeit 5 Stunden vorwärts.

Aus Pech habe ich das Projekt einmal mit der falschen Systemzeit erstellt und dann die Zeit korrigiert. Infolgedessen hatten alle Build-Dateien falsche Zeitstempel, und VS würde denken, dass sie alle veraltet sind, und das Projekt neu erstellen.

Die meisten Build-Systeme verwenden Datenzeitstempel, um zu bestimmen, wann Neuerstellungen stattfinden sollen. Der Datums- / Zeitstempel aller Ausgabedateien wird mit der letzten geänderten Zeit der Abhängigkeiten verglichen. Wenn eine der Abhängigkeiten frischer ist, wird das Ziel neu erstellt.

Dies kann zu Problemen führen, wenn eine der Abhängigkeiten einen ungültigen Datenzeitstempel erhält, da es schwierig ist, dass der Zeitstempel einer Build-Ausgabe jemals den Zeitstempel einer Datei überschreitet, die angeblich in der Zukunft erstellt wurde: P.

Für mich trat das Problem in einem WPF-Projekt auf, in dem für einige Dateien die Eigenschaft "Build Action" auf "Resource" und die Eigenschaft "Copy to Output Directory" auf "Copy if new" gesetzt war. Die Lösung schien darin zu bestehen, die Eigenschaft "In Ausgabeverzeichnis kopieren" in "Nicht kopieren" zu ändern.

msbuild kann keine 'Resource'-Dateien in die Ausgabe kopieren - löst jedoch einen Build aus, wenn sie nicht vorhanden sind. Vielleicht könnte das als Fehler angesehen werden?

Es ist sehr hilfreich bei den Antworten hier, die darauf hinweisen, wie man msbuild dazu bringt, die Bohnen darüber zu verschütten, warum es immer alles baut!

Wenn Sie die Argumente des Debugging-Befehls für das Projekt ändern, wird dadurch auch die Meldung ausgelöst, dass das Projekt neu erstellt werden muss. Obwohl das Ziel selbst nicht von den Debugging-Argumenten betroffen ist, haben sich die Projekteigenschaften geändert. Wenn Sie jedoch neu erstellen, sollte die Nachricht verschwinden.

Ich hatte ein ähnliches Problem mit Visual Studio 2005 und meine Lösung bestand aus fünf Projekten in der folgenden Abhängigkeit (zuerst oben erstellt):

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.

Ich stellte fest, dass das Video_Codec-Projekt auch nach einer vollständigen Bereinigung und einem erneuten Erstellen der Lösung einen vollständigen Build wünschte.

Ich habe dies behoben, indem ich sichergestellt habe, dass die pdbAusgabedatei von C / C ++ und Linker mit dem von den anderen Arbeitsprojekten verwendeten Speicherort übereinstimmt. Ich habe auch RTTI eingeschaltet.

Ein weiteres Problem in Visual Studio 2015 SP3, aber ich habe vor einigen Jahren ein ähnliches Problem in Visual Studio 2013 festgestellt.

Mein Problem war, dass irgendwie eine falsche CPP-Datei für vorkompilierte Header verwendet wurde (also hatte ich zwei CPP-Dateien, die die vorkompilierten Header erstellt haben). Warum hat Visual Studio die Flags auf der falschen CPP geändert, um ohne meine Anfrage vorkompilierte Header zu erstellen? Ich habe keine Ahnung, aber es ist passiert ... vielleicht ein Plugin oder so ???

Auf jeden Fall enthält die falsche CPP-Datei die Datei version.h, die bei jedem Build geändert wird. Visual Studio erstellt also alle Header neu und aus diesem Grund das gesamte Projekt.

Nun ist es wieder normal.

Ich hatte ein VC ++ - Projekt, das immer alle Dateien kompilierte und zuvor (von anderen Personen) von VS2005 auf VS2010 aktualisiert wurde. Ich fand heraus, dass alle cpp-Dateien im Projekt außer StdAfx.cpp auf Create (/ Yc) the vorkompilierten Header gesetzt waren. Ich habe dies so geändert, dass nur StdAfx.cpp festgelegt wurde, um den vorkompilierten Header zu erstellen, und der Rest wurde auf Verwenden (/ Yu) des vorkompilierten Headers festgelegt. Dies hat das Problem für mich behoben.

Ich bin in Visual Studio 2013 und habe gerade auf das Windows 10-Update vom 10. Mai 2019 aktualisiert. Das Kompilieren musste plötzlich jedes Mal wiederholt werden, unabhängig von Änderungen. Ich habe versucht, die pch in ProjectName anstelle von TargetName umzubenennen, habe nach fehlenden Dateien mit dem detaillierten Protokoll und dem Python-Skript gesucht, aber am Ende war es meine Zeit, die nicht mit den Servern von MS synchronisiert wurde (etwa Millisekunden).

Was das für mich gelöst hat, war

• "Datum und Uhrzeit einstellen" im Bedienfeld
• "Jetzt synchronisieren"

Jetzt müssen meine Projekte nicht mehr ohne Grund neu kompiliert werden.

Ich denke, dass Sie einen Zeilenumbruch oder ein anderes Leerzeichen platziert haben. Entfernen Sie es und drücken Sie erneut F5.

Die .NET-Projekte werden unabhängig davon immer neu kompiliert. Ein Teil davon besteht darin, die IDE auf dem neuesten Stand zu halten (z. B. IntelliSense). Ich erinnere mich, dass ich diese Frage vor Jahren in einem Microsoft-Forum gestellt habe, und dies war die Antwort, die mir gegeben wurde.