Razor-Ansichten wurden in ASP.NET bisher zur Laufzeit geladen. Das vorkompilieren (oft auch aus PreCompilieren bezeichnet) ändert dies: Die .cshtml Dateien werden zu einer DLL kompiliert. Damit lassen sich diese zur Laufzeit nicht mehr verändern. Im Regelfall ist dies zumindest produktiv auch nicht erforderlich.
Warum ist PreCompilieren sinnvoll?
Dieses Vorgehen hat zwei große Vorteile: Zum einen werden Fehler in den Razor-Ansichten bereits während des Kompilierens sichtbar. Besonders macht sich dies beispielsweise bei eingebundenen Teilansichten bemerkbar. Diese wurden bisher erst zur Laufzeit eingebunden. Im schlechtesten Falle tritt so ein Fehler erst dann auf, wenn ein Nutzer eine bestimmte Aktion ausführt.
Außerdem steigt die Performance: Das Kompilieren wurde bisher bei jedem Aufruf durchgeführt. Dies kostet Zeit und Rechenleistung. Mittels Vorkompilieren verlagert sich dies in den Buildprozess. Nun muss lediglich einmal Vorkompiliert werden, statt pro Request. Gerade bei vielen, komplexeren Views bzw. stark frequentierten Anwendungen sind die Auswirkungen deutlich spürbar.
Wie kann Vorkompilieren in ASP.NET Core aktiviert werden?
ASP.NET Core 1.x
Dies hängt davon ab, welche Version eingesetzt wird. Bei der alten 1.1 LTS-Version war dies noch nicht aktiviert. Hier muss zunächst die .csproj Datei des Projektes angepasst werden:
<PropertyGroup>
<TargetFramework>netcoreapp1.1</TargetFramework>
<MvcRazorCompileOnPublish>true</MvcRazorCompileOnPublish>
<PreserveCompilationContext>true</PreserveCompilationContext>
</PropertyGroup>
Nun müssen wir zwei NuGet-Pakete einbinden:
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.ViewCompilation" Version="1.1.1" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.Razor.ViewCompilation.Tools" Version="1.1.0-preview4-final" />
</ItemGroup>
Die Versionen sind entsprechend der eingesetzten .NET Core Version anzupassen. Zu guter Letzt ist es notwendig, den Views-Ordner in den Deployment-Prozess mit einzubinden:
<ItemGroup>
<!-- Wird fuer das PreCompilieren von Views benoetigt -->
<Folder Include="Views" />
</ItemGroup>
Wird nun neu kompiliert, sollte man im bin/Debug/netcoreapp1.1 Ordner eine DLL namens ${Projektname}.Views.dll finden. Darin befinden sich die vorkompilierten Views.
ASP.NET Core 2.x und 3.x
Auch in der .NET Foundation wurde festgestellt, dass Vorkompilieren sinnvoll ist. Daher ist es seit Version 2 nicht nur standardmäßig aktiviert, sondern sogar in das Razor-SDK deaktiviert. Das dadurch veraltete Pre-Compilierungstool von .NET Core 1.x sollte daher nicht eingesetzt werden.
Wenn die oben beschriebenen Eigenschaften in einem 2.x Projekt gesetzt sind. findet jedoch ein Fallback auf das alte Tool statt. Daher empfiehlt es sich, die Konfiguration bei 2.x Projekten vollständig zu entfernen und das SDK im <Project> Tag zu setzen:
<Project SDK="Microsoft.NET.Sdk.Razor">
<!-- Projektkonfiguration -->
</Project>
In 3.x wurde das alte Tool ohnehin entfernt, wie man in der ASP.NET Core Dokumentation nachlesen kann.
Fazit
Das Vorkompilieren macht sowohl hinsichtlich Leistung als auch einer geringeren Fehleranfälligkeit Sinn. War die explizite Aktivierung bei .NET Core 1.x noch notwendig, gehört es mittlerweile zum Standard Razor-SDK. Da das Supportende von 1.1 naht, sind zukünftig keine manuellen Änderungen mehr notwendig, um die Vorteile nutzen zu können. Beim alten ASP.NET MVC 4.x Stack bleibt dies weiterhin der Fall.