VS2010: Kompiliervorgang dauert 30s, trotz keiner gemachten Änderung

Hi,

der Kompiliervorgang dauert bei mir immer knapp 30 Sekunden. Generell finde ich das bei der Projektgröße auch in Ordnung (etwa 20 Projekte in der Projektmappe).

Normalerweise ist der doch so intelligent und kompiliert nur die Projekte neu, die auch wirklich geändert wurden. Und wenn man (ganz praktisch gesprochen) auf F5 gedrückt hat, sein Programm wird kompiliert, gezeigt, man schließt es, dann drückt man direkt wieder auf F5, dann wird das Programm doch normalerweise überhaupt nicht neu kompiliert sondern wirklich SOFORT neu gestartet. Aber auch das ist hier nicht (mehr) der Fall.

Wisst ihr da eine Lösung? Es nervt irgendwie etwas, dass bei jeder kleinsten Änderung alles neu kompiliert wird. 😃

Vielen Dank und viele Grüße,
Daniel

Schau mal in das Output-Window, ob er wirklich einen Rebuild macht, oder ob es einfach nur dauert, bis der Debugger an deinen Assemblies hängt.

Hi,

er kompiliert wirklich neu.

Bei einem kleinen Testprojekt verhält es sich übrigens wie erwartet. Bei einer Änderung kompiliert er neu, sonst nicht. 😕

Ob da irgend ein Projekt zwischen sein kann, das neues kompilieren erzwingt?

Daniel

Geht wieder. 😃

VS geschlossen, alle bin und obj-Verzeichnisse aller Projekte gelöscht, VS gestartet, Projekt neu erstellt (das dauerte natürlich wieder die 30 Sekunden) und jetzt geht's wie gewünscht.
Bei keiner Änderung wird sofort neu gestartet, bei einer Änderung an einem Projekt wird nur das Projekt neu kompiliert.

Frage mich trotzdem woran das jetzt lag...

Problemlösung übrigens von Cameron aus dem Thread Why is Visual Studio 2008 always rebuilding my whole project?

Daniel

Die bin- und obj-Verzeichnis-Löscherei hat leider nur kurze Abhilfe gebracht.

Nach 2-3 Änderungen ist wieder alles wie vorher. Keiner eine Idee was es sein könnte, dass der nicht mehr merkt, dass doch gar nichts geänderet wurde?

Falls es relevant ist: Wir arbeiten mit einem TFS. Aber auch im Offline-Modus tritt das Problem auf.

Daniel

Hallo Daniel_3_17,

warte (im Offlinie-Modus) bis es wieder passiert, dann kopiere das "kaputte" Projekt, lösche die Dateien im Original, übersetze neu und vergleiche das Projekt mit der Kopie. Natürlich nicht nur den Quellcode und nicht nur die gelöschten und neu erstellten Dateien, sondern alle Dateien (diff). Bei binären Dateien wird es natürlich etwas schwieriger, die Unterschiede herauszufinden und vor allem, ob die Unterschiede relevant sind, aber einen besseren/einfacheren Weg sehe ich nicht, außer jemand kennt die Ursache und schreibt hier noch eine Antwort.

herbivore

Hi Daniel,

hast du denn schon überprüft, ob nicht doch eine der Dateien (nzw. Referenzen) ein Datum in der Zukunft hat (wie auch in dem Link beschrieben)?
Und bei 20 Projekten würde ich zuerst einmal rausfinden wollen, welches davon wirklich die Ursache ist. Dazu dann der Reihe nach die einzelnen Projekte mittels "Build" versuchen zu bauen und dann den Build-Output anschauen (bei abhängigen Projekten kann es natürlich vorkommen, daß mehrere "anschlagen" - dann mußt du den untersten der Dependency-Reihe näher untersuchen).