StartseiteSoftwareentwicklungASP.NET MVC: Razor-Ansichten vorkompilieren für mehr Performance und Flexibilität

ASP.NET MVC: Razor-Ansichten vorkompilieren für mehr Performance und Flexibilität

Empfehle diesen Artikel deinen Freunden:Share on Facebook
Facebook
Tweet about this on Twitter
Twitter
Share on LinkedIn
Linkedin

Im Gegensatz zum .NET Code werden Razor-Ansichten in ASP.NET zur Laufzeit compiliert. Dies ist recht verbreitet und wird bei anderen serverseitigen Technologien im Web-Bereich wie etwa PHP eben so gehandhabt. Bei PHP betrifft dies sogar  auf den gesamten Code zu, der bei jedem Seitenaufruf vom Interneter aufs neue verarbeitet wird. Auf den logischen Programmcode trifft dies bei ASP.NET zwar nicht zu (Stichwort Common Intermediate Language, kurz CIL), wohl aber auf die Razor-Ansichten. Der RazorGenerator ermöglicht es, die Ansichten bereits beim Erstellen der .NET Anwendung zu kompilieren. Dies erhöht die Performance der Webanwendung und reduziert die Serverlast.

RazorGenerator installieren

Zunächst installieren wir das NuGet-Paket RazorGenerator.Mvc – wahlweise über den grafischen Paketmanager oder mit dem Install-Package Befehl über die Konsole:

Install-Package RazorGenerator.Mvc

Damit Visual Studio den Razor Generator erkennt und die Ansichten automatisch beim Debuggen oder Erstellen ebenfalls compiliert, benötigen wir noch die dazugehörige gleichnamige Visual Studio Erweiterung. Um diese zu installieren, navigieren wir über das Menü Extras > Erweiterungen und Updates in den Erweiterungsmanager. Über die Suche kann der Razor Generator installiert werden:

Anschließend muss Visual Studio neu gestartet werden. Leider ist dieser Schritt nicht dokumentiert. Fehlt die Erweiterung, funktioniert der Generator schlicht und einfach nicht. Fehlermeldungen werden keine angezeigt, außer man versucht den Vorgang durch Rechtsklick auf die Ansicht > Benutzerdefiniertes Tool ausführen manuell zu starten.

Damit eine Razor-Ansicht vorkompiliert wird, muss der RazorGenerator als benutzerdefiniertes Tool in den Eigenschaften definiert werden. Dazu mit der rechten Maustaste auf die View klicken und Eigenschaften auswählen. Unter Benutzerdefiniertes Tool wird RazorGenerator eingetragen:

Zum testen einfach das Projekt neu erstellen – Oder alternativ wie oben bereits erwähnt das Tool manuell mit einem Rechtsklick auf die View und Benutzerdefiniertes Tool ausführen starten. In beiden Fällen sollte anschließend eine der View untergeordnete Datei entstanden sein, die mit .generated.cs endet:

Dies ist die kompilierte View, welche automatisch beim kompilieren des Projektes erzeugt wird. ASP.NET verwendet sie zur Laufzeit, wodurch das wiederkehrende Kompilieren der Razor-Ansicht verhindert wird. Daher sollte man keine Änderungen an der .generated.cs Datei vornehmen! Diese werden beim nächsten Erstellen des Projektes überschrieben. Als logische Konsequenz haben Änderungen an den Originalen Razor-Ansichten (.cshtml Dateien) zur Laufzeit keine Auswirkungen mehr. Dies sollte aber kein Problem darstellen, da in diesem Falle ohnehin das Projekt neu deployt werden sollte.

Auch wenn sowohl das RazorGenerator NuGet-Paket als auch die Visual Studio Erweiterung installiert sind, werden Razor-Ansichten nicht automatisch vorkompiliert. Dazu ist es wie oben beschrieben nötig, das benutzerdefinierte Tool zu setzen. Ob dies funktioniert erkennt man daran, dass die jeweilige Razor-Ansicht eine untergeordnete .generated.cs Datei besitzt.

Weitere Einsatzmöglichkeit: Teilen von Ansichten

Ein Problem der Razor-Ansichten besteht darin, dass sie sich nicht einfach über mehrere Projekte in einer Projektmappe teilen lassen. Beispielsweise wenn man ein zentrales Layout für mehrere Projekte verwenden möchte. Hier bieten sich meist nur eher weniger schöne Workarounds an – Beispielsweise einen Pre-Build Schritt, der die Ansichten in die gewünschten Projekte kopiert. Da vorkompilierte Razor-Ansichten de Facto nur aus einer C#-Klasse bestehen, kann man diese wesentlich einfacher zwischen verschiedenen Projekten teilen.

Wer vor diesem Einsatzszenario steht, sollte sich jedoch fragen, ob mehrere Projekte wirklich notwendig sind. Bereiche (Areas) stellen beispielsweise eine attraktive Alternative dar, die performanter und flexibler ist. Je nach Funktionsumfang kann der Einsatz verschiedener Projekte die miteinander vernetzt sind, auch an anderen Stellen Probleme bereiten.

Deployment ohne Visual Studio

Die hier vorgestellten Pakete und Erweiterungen integrieren sich in den Buildprozess von Visual Studio. Für lokale Tests und kleinere Anwendungen die manuell deployt werden, mag dies kein Problem darstellen. Möchte man jedoch die Projektmappe selbst mit MsBuild/MsDeploy Erstellen und deployen, wird dies nicht reibungslos funktionieren. Dies wäre beispielsweise nützlich, wenn man den Deployment-Prozess mittels kontinuierlicher Integration automatisieren möchte. In diesem Fall muss zusätzlich das NuGet-Paket RazorGenerator.MsBuild installiert werden.

Über DMW007

Schreibe einen Kommentar