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?
quelle
Antworten:
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:
devenv.exe.config
Datei (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 benanntV*Express.exe.config
.Fügen Sie nach der
</configSections>
Zeile Folgendes hinzu:Durchsuchen Sie das Debug-Protokoll nach Zeilen des Formulars:
(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:
quelle
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:
quelle
1>Project not up to date because build input 'C:\...\ReadMe.txt' is missing.
:Ö !!?!was modified at
im Diagnosemodus suchen, da ich keinenot up to date
Ausgänge hatte.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.
quelle
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.
quelle
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:
Quellcode:
quelle
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.
quelle
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:
zu
quelle
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. .
"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).
"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.
quelle
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 .quelle
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.
quelle
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.
quelle
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.
quelle
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:
Unter Windows 7 befindet sich die Datei unter
%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%
. Es gibt zwei ähnliche Dateiendevenv.exe.config.config
unddevenv.exe.config
. Sie möchten später eine ändern.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.
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 Events
imCapture
Menü die Menüoption ausgewählt ist, die standardmäßig ausgewählt werden soll.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 date
Meldung 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.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 .
quelle
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.
quelle
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:
Wie hier dokumentiert (Warnung: übliche MSDN-Ausführlichkeit). Wenn der Build abgeschlossen ist, suchen Sie nach der Zeichenfolge
will be compiled
in der Protokolldatei, die während des Builds erstellt wurdeMyLog.log
.quelle
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:
Folgendes habe ich getan, um das Problem zu lösen:
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.
quelle
Ich hatte dieses Problem und fand Folgendes:
http://curlybrace.blogspot.com/2005/11/visual-c-project-continually-out-of.html
quelle
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):
quelle
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.
quelle
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.
quelle
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.
quelle
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.
quelle
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!
quelle
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.
quelle
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):
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
pdb
Ausgabedatei von C / C ++ und Linker mit dem von den anderen Arbeitsprojekten verwendeten Speicherort übereinstimmt. Ich habe auch RTTI eingeschaltet.quelle
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.
quelle
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.
quelle
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
Jetzt müssen meine Projekte nicht mehr ohne Grund neu kompiliert werden.
quelle
Ich denke, dass Sie einen Zeilenumbruch oder ein anderes Leerzeichen platziert haben. Entfernen Sie es und drücken Sie erneut F5.
quelle
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.
quelle