wake-up-neo.net

Visual Studio: Projekt ist nicht auf dem neuesten Stand "weil" AlwaysCreate "angegeben wurde"?

Ich habe eine Lösung von VS2008 zu VS2010 (SP1) migriert.
Nun, eines meiner Projekte findet niemals die Ruhe, auf dem neuesten Stand zu sein. Jeder Build hat folgende Ausgabe:

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 ==========

Irgendwelche Ideen?

34

Ich hatte ein ähnliches Problem, wenn eine der im Projekt aufgeführten Include-Dateien nicht wirklich vorhanden war. Ich hatte die Datei gelöscht, aber vergessen, sie aus dem Projekt zu entfernen.

Die Abhängigkeitsüberprüfung geht davon aus, dass das Projekt nicht auf dem neuesten Stand ist, der Builder findet jedoch nichts zu erstellen.

40
Bo Persson

Ich hatte zwei Projekte, die dieselbe Datei enthielten. Wenn das zweite Projekt erstellt wurde, kompilierte es die Datei erneut und änderte die 'Touch'-Datumszeit. Dies setzt wiederum das Flag "AlwaysCreate" für das erste Projekt.

Ich habe dies herausgefunden, indem ich 'CPS' in meiner Datei "C:\Programme (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe.config" wie im nachstehenden XML-Snippet aktiviert habe. Wenn dies aktiviert ist, können Sie das DebugView-Tool verwenden, um Nachrichten von VS2010 abzurufen, aus denen hervorgeht, warum das Projekt neu erstellt wird. Warum diese Nachrichten nicht in das Build-Protokoll aufgenommen werden, ist mir unklar, aber trotzdem ist sie da. 

Füge das hinzu:

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

Bis hierhin:

<?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" />
34
Bzzt

Laut diesem Thread auf MSDN:

In meinem Fall in VS10 lag es an fehlenden (aber nicht erfüllten .h-Dateien, daher keine zusätzlichen Fehler zu identifizieren) in Projektordnern.

Eine schnelle Überprüfung, ob alle Projektdateien im Editor geöffnet werden können, hat dieses Problem behoben.

9
Oded

Sie müssen auch andere Dateien als .h überprüfen. In meinem Projekt wurde Readme.txt vermisst.

2
Jacek

Ich habe eine Lösung in einen neuen Ordner verschoben und jedes Mal, wenn ich eine neue Version baute oder versuchte, zu debuggen, würde ich behaupten wollen, dass alle Projekte, aus denen die Lösung bestand, nicht mehr aktuell waren, obwohl sie gerade gebaut wurden.

Ich durchsuchte alle .vcxproj-Dateien, verwendete DebugView mit CPS = 4 (siehe @Bzzts Antwort oben) und stellte fest, dass die Header-Dateien an ihrem alten Speicherort gesucht wurden. Da die Lösung verschoben, nicht kopiert wurde, waren diese Dateien nicht vorhanden.

Was schließlich für mich gelöst wurde, war das Reinigen der Lösung und das Wiederherstellen. Danach verursachte das "AlwaysCreate" nicht mehr das "Erstellen" aller Unterprojekte. Sie müssen jede Konfiguration (Debug und Release) separat bereinigen, aber nachdem der Clean-Zustand wiederhergestellt wurde, ist alles in Ordnung.

In meinem Fall hat er eigentlich kein Gebäude erstellt, aber MSBuild oder was auch immer für veraltet war, verwendete einen zwischengespeicherten Dateipfad, der nicht mehr existierte. Das Bereinigen und Wiederherstellen ersetzte diesen Cache und wurde dann wie erwartet aufgebaut

2
boatcoder

Für die Befehlszeile von msbuild.exe können Sie/verbosity: detail verwenden und die Ausgabe nach durchsuchen 

  • "wird kompiliert als", um Zusammenstellungen zu finden
  • "Quellensammlung erforderlich", um Links zu finden

Hinweis: Die Ausgabe kann mit msbuild.exe/verbosity: Detailed> output.txt in eine Datei geleitet werden

z.B.

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:
0
Shane Gannon

In Visual Studio 2010 habe ich falsche Wiederherstellungen einer Lösung mit vielen Projekten beseitigt, indem die Multiprozessor-Kompilierung (/ MP) nicht festgelegt wurde (schade!). Zuvor hatte ich es aktiviert. Das Flag finden Sie hier: Allgemeine Eigenschaften> C/C++> Allgemein> Multiprozessor-Kompilierung. Ich bemerkte auch, dass ich die fehlerhaften Neuerstellungen einzelner Projekte beseitigen konnte, indem ich jedes Projekt einzeln neu aufbaute. dann zeigte ein Build von jedem, dass jeder auf dem neuesten Stand war.

0
Vince

Ich habe das gleiche Problem.

Grundursache: falsche Build-Version von VS (32bit und 64bit)

Lösung: Schalten Sie den Modus Debug/Release von 32 Bit auf 64 Bit oder umgekehrt

http://postimg.org/image/3jurey1qr/

0
zizopen

Möglicherweise wird dies auch nach einem Windows-Update angezeigt: Aktuelle Projekte, die wegen TZRE.DLL-Datumsstempel erneut kompiliert wurden, befinden sich nach einem Windows-Update in der Zukunft

Die Lösung besteht darin, bis zu diesem Zeitpunkt zu warten, und das Problem wird magisch verschwinden. __ Ich hatte gerade das gleiche Problem 15:15

0
GilesDMiddleton

Damit dies funktioniert, habe ich einfach mein vorhandenes Ausgabeverzeichnis umbenannt, um alle Zwischendateien neu zu erstellen (nachdem ich alle oben akzeptierten Antworten ausprobiert hatte).

Ich hatte in der Vergangenheit Erfolg, DebugView in VS2010 zu verwenden, um zu löschende Dateien zu finden, aber heute funktionierte dieser Ansatz nicht. Ich konnte in keinem meiner Code- oder Projekt-XML-Dateien irgendeine Referenz auf die fehlenden Header-Dateien finden, die mit DebugView gefunden wurden. Ich habe auch die veralteten Dateien von TFS abgerufen, um sie auf meinem Rechner sowohl anwesend als auch abwesend zu versuchen.

Ich habe dann GREP verwendet, um mein gesamtes Lösungsverzeichnis zu durchsuchen. Die einzigen Ergebnisse waren Binärdateien: die alten Codedateien * .obj, die Projektdatei * .pdb und vc100.idb. Ich weiß nicht, wie diese Dateien während des Erstellens und Wiederherstellens geändert/ersetzt werden. Daher bin ich mir nicht sicher, ob eine vorherige Referenz in einer dieser Dateien dafür verantwortlich war, dass die alten Header-Dateien fehlten. 

Hoffe, das hilft jemandem die Straße runter und danke für die obigen Informationen, die mich dazu gebracht haben!

0
Matthew Lowe