Ich habe eine Visual Studio (2005) Lösungsdatei mit 70 Projekten.
Jedes Mal, wenn ich F5 drücke, um es auszuführen, sagt es mir, dass 4 der Projekte veraltet sind, und fragt mich, ob ich sie neu erstellen möchte. Es macht das, obwohl ich gerade einen kompletten Build gemacht habe.
Ich verstehe (im Prinzip), dass eines der anderen Projekte etwas aktualisieren muss, von dem diese Projekte abhängen, aber wie finde ich heraus, was?
Gibt es irgendwelche Tools, um zu helfen, oder welche Prozedur sollte ich befolgen, um herauszufinden, warum VS diese Projekte für eine Neuerstellung markiert?
UPDATE:
Für diejenigen, die daran interessiert sind, sieht es so aus, als wäre mein PC das Problem (meine HD hat sich in letzter Zeit verändert). Während ich versuchte, das Problem aufzuspüren, begannen sukzessive Neuerstellungen Kompilierungsfehler zu generieren. Ich habe einen Clean-and-Build gemacht und eine große Anzahl von (offensichtlich falschen) Fehlern erhalten. Ein Neustart später, gefolgt von einer Neuerstellung, sind alle Fehler und das Abhängigkeitsproblem verschwunden.
Entschuldigen Sie mich jetzt, während ich alle meine wichtigen Dateien abspeicherte ...
Ich würde zweimal hintereinander eine normale Build ausführen. Beim zweiten Mal würde ich die MSBUILD-Ausführlichkeit auf "Normal" oder höher setzen (in Extras-> Optionen, "Projekte und Lösungen", "Erstellen und Ausführen". Ich würde die Ausgabe sorgfältig lesen, um zu sehen, was tatsächlich erstellt wird das zweite Mal.
In der Tat, jetzt, wo ich darüber nachdenke, wenn das wirklich ein Zyklus ist, dann muss ein Teil dessen, was beim zweiten Mal gebaut wird, sein, was bewirkt, dass es das dritte Mal baut usw. Vielleicht hast du einen Post-Build Schritt in einem der Projekte, die eine Assembly oder eine andere Ressource berühren, die als Eingabe für einen früheren Schritt verwendet wird. Bei 70 Projekten in der Lösung wäre so etwas leicht unbeabsichtigt und schwer zu erfassen. Sie müssen möglicherweise genug über MSBUILD erfahren, um erkennen zu können, wann einer der Schritte zu entscheiden hat, dass er erstellt werden muss, weil sich etwas geändert hat, und dann Ihre Lösung gut genug zu verstehen, um zu wissen, dass sich nichts hätte ändern sollen. dann zu sehen, dass sich etwas geändert hat, das sich nicht hätte ändern sollen.
Wenn Sie mit dieser Übung fertig sind, haben Sie vielleicht einen Einblick gewonnen, der Ihnen hilft, die Lösung in kleinere Lösungen aufzuteilen.
Ich hatte das gleiche Problem mit der Verknüpfung eines .netmoduls in mein Projekt, das mit einem benutzerdefinierten Buildschritt ausgeführt wurde. Das Prolem stellte sich heraus, dass ich auch eine C ++ - Bibliothek verknüpfte und die .netmodule-Datei in der gleichen Zeile in der Linker-Eingabe aufgeführt war.
Beispiel: .lib .netmodule
Insead von: .lib \ n .netmodul
Ein schnellerer Weg als Johns Protokoll-Ausführlichkeit in Visual Studio 2013 besteht darin, den Projektbaum des Projektmappen-Explorers zu öffnen. Die Dateien, die nicht gefunden wurden, haben nicht das kleine Dreieck vor dem Dateinamen (mit dem Sie normalerweise eine Liste von Symbolen in dieser Datei sehen können).
Entfernen Sie diese Dateien und für mich ist die AlwaysCreate-Nachricht weggegangen (Sie sehen nur 'AlwaysCreate', wenn die Ausführlichkeitsstufe auf 'Normal' gesetzt ist).
Ich hatte dieses Problem und es stellte sich heraus, dass ich eine Header-Datei zu meinem Projekt hinzugefügt hatte, die ich aber von der Festplatte gelöscht hatte. Entfernen Sie die nicht vorhandene Header-Datei aus dem behebt das Verhalten.
Tags und Links dependencies visual-studio projects-and-solutions