Visual Studio baut Projekt vor Debug obwohl keine Änderung in Quellcode durchgerführt

Hallo,

ich habe in meinem Projekt das Problem, dass Visual Studio jedesmal die Anwendung baut sobald ich das Debugging starte, auch wenn am Quellcode nichts geändert wurde.
Gerade für Tests, wenn das Programm mal hängen bleibt, nervt das ganz gehörig wenn der folgende Debug Neustart einen Build voranstellt.
Könnt ihr mir einen Tipp geben, an welchen Stellschrauben ich hierfür drehen muss? Ich habe weder bei den Projekteinstellungen noch in den Build Einstellungen etwas passendes gefunden 😦
Auch habe ich keine passenden Forumseintrag gefunden.

Vielen Dank für eure Hilfe

Visual Studio baut standardmäßg immer..by Design und gewollt so.
Zu oft ändern Leute Code und debuggen dann noch alten Code.

Daher der Weg zur gefährlichen Einstellung
-> Rechtslick auf Solution, dann Configuration Manager
Und dann an den gewünschten Stellen das Debug entfernen.

Diese Einstellung wird auf Solution Ebene vorgenommen und betrifft damit alle anderen Personen, die ebenfalls mit dieser Solution arbeiten.

Ich rate unbedingt davon ab, Debug und Build hier nicht zeitgleich durchzuführen.

Das kuriose ist, dass bis vor ein paar Wochen Visual Studio das Projekt nur neu gebaut hat, wenn ich Änderungen am Quellcode gemacht habe. Deswegen ist es so nervig wenn ich jedesmal in Ruhe einen Kaffe holen kann, bis der Debug der Applikation startet.

Ich vermute mal, dass meine Änderung in den Einstellungen der Solution auch meine Kollegen betreffen würde wenn ich meine Änderungen übers Git commite?

Dann ist das natürlich keine Lösung, die ich einsetzen kann.

Trotzdem Vielen Dank für diesen Tipp.

Wenn du bei jedem Build die Zeit hast einen Kaffee zu holen, wie groß ist dann dein Projekt?
Ich kann hier eine Solution bestehend aus zwei Webs, den drei DLL für das Schichten Modell, vier Tasks sowie einem WinForms Support Tool innerhalb von wenigen Sekunden bauen.
Und dies bei einem kompletten Rebuild ohne zwischengespeicherte obj oder andere Dateien.

Um so lange Kompilierzeiten zu haben hast du entweder uralte Hardware oder ein zu großes Projekt.
Erstes sollte sich durch neue Hardware leicht beheben lassen.
Du solltest lieber die Ursache lösen als mit Workarounds das Problem nur umgehen zu wollen.
Auf lange Sicht wirst du immer an den langen Buildzeiten hängen.

T-Virus

Wenn aber an den Sourcen nichts geändert wurde, sollte ein "Start Debugging" auch keinen neuen Build anstoßen.

Hast du mal einen kompletten Clean (Löschen des "obj"-Verzeichnisses) + Rebuild durchgeführt. Baut das Projekt danach immer noch neu?

Schau auch mal auf das Änderungsdatum der Dateien im "bin"-Verzeichnis? Passen diese oder liegen diese in der Vergangenheit?

Wie schon von Th69 gesagt, normalerweise wird ohne Änderung kein neuer, kompletter Build gestartet.

Man kann über den Output herausfinden, warum ein Projekt gebaut wird. Dazu einfach temporär über Options - Projects and Solutions - Build and Run - MSBuild project build output verbosity die Ausgabe auf "Detailed" stellen - dann sollte man es sehen.

Wir hatten mal ein ähnliches Problem, bei dem die ganze Solution jedes Mal gebaut wurde, ohne Änderung am Code. Ich weiß nicht mehr genau woran es lag, kann aber sagen dass der Trigger dafür beim aller ersten Projekt der Solution zu finden war. Nachdem dieser (falsche) Trigger behoben wurde, wurde auch nur brav das gebaut, was sich geändert hat.

Deswegen ist es so nervig wenn ich jedesmal in Ruhe einen Kaffe holen kann, bis der Debug der Applikation startet.

.. dann sollte man evtl. auch mal die Struktur und die Modularisierung überdenken.
Windows baut in wenigen Minuten; wenn das "eine kleine Applikation" ebenfalls benötigt.... 😃

Ansonsten könnte p!lle's Hinweis ebenfalls zielführend sein.

Das Projekt ist relativ umfangreich und hat viele Abhängigkeiten zu anderen Projekten der Solution sowie externen DLLs von Gerätetreibern etc. (typische Eierlegendewollmichsau).
Das ganze wird auf einem i5 6300U gebaut und dauert für mein Projekt 4,2 min und für die Solution 11,1 min. Die Frage nach potenter Hardware wurde schonmal abgelehnt.
Den Clean fürhre ich fast täglich durch, um vor Commit und Push sicherzustellen, dass die Solution korrekt mit dem neu gepushten Code der Kollengen zusammenarbeitet.
Durch die 28k Zeilen des Build detailierten Outputs muss ich mich erstmal durchwühlen. Gibt es erfahrungsgemäß Schlagwörter, nach denen ich suchen könnte?

Hört sich an, dass hier enormes Potential für ein ordentliches DevOps bzgl. Paketierung steckt, sodass nicht ständig alles neu kompiliert werden muss.

Durch die 28k Zeilen des Build detailierten Outputs muss ich mich erstmal durchwühlen. Gibt es erfahrungsgemäß Schlagwörter, nach denen ich suchen könnte?

Das ist ganz einfach:

• den Wert in den Options nochmal auf "Minimal" stellen

• "Rebuild Solution" durchführen (damit ist sichergestellt, dass prinzipiell alles gebaut ist)

• "Build Solution" durchführen
  -> dadurch siehst du im Output welche Projekt in welcher Reihenfolge gebaut werden
  -> für die weiteren Tests pickst du dir das Projekt an 1. Stelle heraus

• den Wert in den Options auf "Detailed" stellen

• für das Projekt, was du dir gemerkt hast, ein "Build" durchführen
  -> dadurch ist der Output erheblich kleiner
  -> und dann einfach oben anfangen zu lesen 😁

Genaue Stichpunkte gab es mMn nicht.
Es ist ein bissel Forschung, z.B. werden Projekte immer gebaut, wenn es Ressourcen gibt, die "Copy to Output directory: copy always" haben.

Edit sagt, ein mögliches Stichwort könnte "is not up to date" sein.

Vielen Dank erstmal für die Anregungen. Sobald ich neue Infos habe gibts eine entsprechende Antwort 😃