Ich habe eine Lösung mit 50 Projekten und jedes Projekt hat mindestens 100 Dateien (was ich für relevant halte).
Das Problem ist, wenn ich die Lösung oder ein einzelnes Projekt erstelle, dass es eine Verzögerung von 5 bis 10 Sekunden gibt, bevor das Fenster "Build Output" geschrieben wird. Wenn der Ausführlichkeitsbereich "Ausgabe erstellen" auf "Diagnose" gesetzt wird, gibt dies keinen Hinweis darauf, was die Ursache der Verzögerung ist. Diese Verzögerung tritt sogar auf, wenn keine Dateien geändert wurden (zuvor erstellt).
%Vor%Wenn es Änderungen in der Build-Ausgabe gibt, heißt es, dass der Build ungefähr 2 Sekunden benötigt hat, aber die Ende-zu-Ende dauert ungefähr 7 bis 12 Sekunden.
Build-Ausgabe:
%Vor%MSBuild:
%Vor% Das Ausführen von MSBuild über die Befehlszeile hat keine solche Verzögerung, die 2.17 Sekunden ist die Zeit, in der die Tastatur zum Abschluss gedrückt wird.
Wie ich feststellen kann, werden die msbuild-Aufgaben in Visual Studio selbst schnell ausgeführt, aber es scheint, dass Visual Studio hinter den Kulissen etwas tut, bevor die msbuild-Aufgaben starten, die diese Verzögerung verursachen.
Wenn ich Visual Studio (devenv.exe) über Process Monitor überprüfe, merke ich Aufrufe an CreateFile , QueryDirectory und CloseFile für jede Datei und jeden Ordner im Projekt und die Abhängigkeiten des Projekts. Dies scheint mit der Verzögerung beim Betrachten der Zeitlinie zu korrelieren.
Wie reduziere ich die Verzögerung, wenn ich den Build-Prozess von Visual Studio aus starte (Rechtsklick auf Projekt & gt; Build), bis wann der Build tatsächlich stattfindet?
Ich habe mir die folgenden Antworten zur Lösung angesehen, sie reduzieren jedoch entweder die Verzögerung nicht oder sind einfach nicht anwendbar:
Ich denke, Ihr Problem ist "Ich habe eine Lösung mit 50 Projekten". Nach meiner Erfahrung sollte dies nicht für die Entwicklung verwendet werden. Dies sollte nur für einen Build-Server verwendet werden. Ich würde also mehrere Lösungsdateien erstellen. Ein großer mit allen Projekten für den Build-Server, und einige mit nur wenigen Projekten für die Entwicklung. Die Verpackung dieser verschiedenen Lösungen sollte sich an dem orientieren, was sich oft zusammen ändert. Wenn die Antwort alles ist, würde ich die Projektstruktur in Frage stellen.
Weil ich deine Frage nicht genau beantworte was genau vs im Vergleich zu msbuild macht, würde ich das normalerweise als Kommentar schreiben. Aber mein Ruf ist im Moment nicht genug (daran zu arbeiten), aber weil niemand anderes das empfohlen hat, dachte ich, dass es eine Antwort wert wäre. Oder ist das nur zu offensichtlich, dass niemand darauf hingewiesen hat? Dann bitte verzeih mir.
Tags und Links .net c# visual-studio visual-studio-2012 msbuild