Ich arbeite derzeit mit einem ASP.NET-CMS, der fast 500 Code-Dateien im Verzeichnis App_Code speichert, sowie mit Hunderten von Webformularen mit Code-Behind in verschiedenen Ordnern der Site. Es ist ein Website-Projekt (kein Web-Anwendungsprojekt) und ich möchte es nur ungern ändern, da es sich um ein Projekt mit mehreren beteiligten Entwicklern handelt, und so wird das CMS ausgeliefert.
Ich suche nach Hinweisen und Tipps zur Optimierung des Build-Prozesses dieses Website-Projekts, da Visual Studio häufig alle Quelldateien und Code-Behind-Dateien neu erstellen möchte, was einige Minuten dauern kann.
Gibt es Möglichkeiten, die Neuerstellung aller Dateien zu vermeiden? Soll ich meinen Code und den CMS-Code in separate Web-Anwendungsprojekte (statt in ein Website-Projekt) aufteilen? Gibt es andere Möglichkeiten, die Build-Leistung zu verbessern?
Wenn die einfachste Lösung patch-weise darin besteht, die .cs-Struktur so ähnlich wie möglich zu halten, würde ich Andreas 'Empfehlung, den App_Code in mindestens ein anderes Projekt zu verschieben, berücksichtigen.
Scott Guthrie postete ein paar Tipps zum Erstellen von Kompilieren in VS 2005. Sie haben nicht angegeben, auf welcher Version Sie waren, aber es gelten die gleichen Geschwindigkeitstipps. Der zweite Abschnitt seines Beitrags ist spezifisch für Website-Projekte.
Ein anderer Tipp wäre, wenn Sie an Seiten arbeiten und nicht wirklich im Verzeichnis App_Code , Es gibt eine Build-Option, die nützlich sein kann . Wechseln Sie zu Projekteigenschaften & gt; Erstellen & gt; Ändern Sie Vor dem Start der Startseite von Website erstellen nach Seite erstellen . Dadurch wird nur die Startseite erstellt, wenn Sie den Debugger starten. Ich bin mir nicht sicher, ob dieses Szenario häufig vorkommt, aber wenn die meiste Arbeit auf den Seiten und nicht in App_Code passiert, sparen Sie viel Zeit beim Kompilieren.
App_Code muss zusammen gebaut werden, Sie sollten vermeiden, dass Ihre Codebehinds, etc dort sind. Alles, was anderswo sein kann, sollte sein. Nur eine Anmerkung: Die Kompilierungszeit ist, zumindest im Debugging, in einer Web Application in der Regel 30-50x schneller. Das heißt, Sie müssen die gesamte Anwendung jede Codeänderung neu kompilieren, so dass es Nachteile gibt ... aber mit Namespace ändert sich und so, ich verstehe, die Belastung Patches würden Sie auf.
Beachten Sie auch, dass Visual Studio, wenn Sie Code in andere Projekte aufteilen, nicht nur einfacher kompiliert sein muss, sondern alle anderen abhängigen Projekte kompilieren muss, sofern sie sich nicht geändert haben. So wie es jetzt aussieht, ist alles ein faires Spiel, da alles in Ihrem Projekt, das sich ändern kann, möglicherweise etwas anderes beeinflusst. Wenn Sie es jedoch aufteilen, wird Visual Studio nur Ihre anderen Projekte kompilieren, wenn sie sich ändern oder ein Projekt Die Referenz wird neu erstellt.
Sie sollten das neue OptimizeCompilation-Flag ausprobieren, das wir kürzlich hinzugefügt haben.
%Vor%Siehe meine blog post , um zu erfahren, worum es geht und wo man es bekommt. Es sei denn, Sie sind auf Win7 oder verwenden VS2010, müssen Sie es über einen Hotfix erhalten.
Sie sollten zumindest versuchen, es in eine Webanwendung zu konvertieren, es sei denn, es gibt einen politischen Grund dafür, es nicht zu tun. Es ist nicht so schwer wie es klingt, das größte Problem ist, dass alle Ihre Entwickler ihre Lösungen möglicherweise neu konfigurieren müssen.
Versuchen Sie, den Code in App_Code in verschiedene Projekte zu verschieben, da sie nicht unbedingt auf der Web-Site sein müssen. Das sollte zumindest ein bisschen helfen.
Ich denke, Ihr größtes Problem wäre die enorme Menge an Dateien. Ich würde die Web-App in mehrere (mindestens zwei) Projekte aufteilen: Ihr Web-Projekt und eine Business-Schicht (oder etwas in dieser Art).
Ich empfehle am besten, dass die meisten dieser Dateien im App-Code Entitäten oder Dateien sind, die sich nur sehr selten ändern. Daher ist es in Ihrer Situation nicht sinnvoll, sie in Ihrer Web-App zu speichern.
Wenn Sie diese Route wählen, wenn Sie eine der Dateien in Ihrem anderen Projekt ändern, müssen Sie sehr vorsichtig sein, wenn Sie Änderungen bereitstellen, da Sie die gesamte DLL bereitstellen müssen.
>Wir hatten ein ähnliches Problem mit unserem Projekt, das auf diese Weise erstellt wurde, um das Hinzufügen neuer whitelabel-Partnerseiten zu ermöglichen.
Die einfachste Möglichkeit, die Build-Zeit zu verkürzen, bestand darin, den I / O-Engpass zu reduzieren, an dem sich Visual Studio aufhängt. Holen Sie sich eine anständige SSD (wir verwenden die OCZ 60 GB Summit Laufwerke) sollten Sie die Bauzeiten erheblich verbessert finden.
Der andere Zeitsparer ist es, die Gesamtzahl der Verzeichnisse Ihres Projekts zu reduzieren. Für jedes neue Verzeichnis, das von Visual Studio erkannt wird, wird eine neue Instanz des Compilers gestartet. Wenn Sie so viele Dateien im selben Verzeichnis wie möglich haben, reduzieren sich diese Kosten. (Um die Ordnerstruktur zu erhalten, die das Projekt pflegbar macht, verwenden Sie virtuelle Ordner)
Tags und Links optimization asp.net build-process