Das Verhalten einer Anwendung je nach Umgebung anpassen zu können, kann eine große Hilfe für Entwickler sein: So lassen sich Debug-Informationen wie detaillierte Fehlerseiten während der Entwicklung anzeigen, die auf dem Produktivsystem kein Nutzer sehen wird. Durch das Definieren von Umgebungen die darüber entscheiden wird sichergestellt, dass die manuelle Entfernung solcher Entwicklungstools nicht vergessen wird. Im alten ASP.NET Framework gab es keine eingebaute Lösung hierfür. Doch auch hier hat ASP.NET Core einen großen Schritt nach Vorne gemacht: Der Nutzer kann mit wenig Aufwand eigene Umgebungen erstellen und seinen Code entsprechend anpassen. Folgender Artikel zeigt, wie es geht.
Definieren und setzen einer Umgebung
Die aktuell genutzte Umgebung wird über die Umgebungsvariable ASPNETCORE_ENVIRONMENT definiert. Sie enthält den Namen der Umgebung als String. Standardmäßig sieht ASP.NET dabei Development, Staging und Production vor. Man kann aber problemlos eigene Definieren. Während des Debuggens in Visual Studio kann die Umgebung über die Projekteigenschaften (Rechtsklick auf das Projekt) definiert werden:
Oder alternativ über Properties > launchSettings.json im Attribute profiles, hier lassen sich die gleichen Einstellungen im JSON-Format ändern.
Umgebung aus C# heraus abfragen
Da ASP.NET Core stark auf Dependency Injection statt statischer, geteilter Instanzen setzt, erhalten wir die Umgebung nur über IApplicationBuilder – Also in Configure der Startup-Klasse. Für die eingebauten Umgebungen existieren bereits Hilfsfunktionen wie IsDevelopment(). Selbst definierte lassen sich über IsEnvironment() abfragen:
public void Configure(IApplicationBuilder app, IHostingEnvironment env, ILoggerFactory loggerFactory){
bool isDevelopment = env.IsDevelopment();
bool isMyEnvironment = env.IsEnvironment("MyEnvironment");
if(isDevelopment) {
app.UseDeveloperExceptionPage();
}else {
app.UseExceptionHandler("/Home/Error");
}
}
Der Vorteil von IsEnvironment() gegenüber dem Attribute EnvironmentName liegt in der Unabhängigkeit der Schreibweise. IsEnvironment() ignoriert die Groß- und Kleinschreibung, wogegen EnvironmentName die definierte Umgebung in der Originalschreibweise enthält. Möchte man die Umgebung außerhalb der Startup-Klasse abfragen, muss wie Anfangs schon erwähnt Dependency Injection verwendet werden.
Umgebung in Razor-Ansichten abfragen
Einzige Ausnahme sind Ansichten (Views) in Razor. Hier existiert ein TagHelper namens environment, mit dem sich HTML- oder Razor-Code nur in bestimmten Umgebungen einfügen lässt. Man hat die Wahl eine einzige Umgebung anzugeben, oder mehrere mit Komma zu trennen:
<environment names="Development">
<link rel="stylesheet" href="~/lib/bootstrap/dist/css/bootstrap.css" asp-append-version="true" />
<link rel="stylesheet" href="~/css/site.css" asp-append-version="true" />
</environment>
<environment names="Staging,Production">
<link rel="stylesheet" href="~/css/full.min.css" asp-append-version="true" />
</environment>
Dieses Beispiel fügt die Stylesheets in der Entwicklungsumgebung einzeln und unverändert ein, um das Debuggen zu erleichtern. In der Staging- und Produktivumgebung dagegen wird die kombinierte und verkleinerte Version geladen, um die Ladezeit zu verbessern. Außerdem wird in beiden Umgebungen durch das aktivieren des asp-append-version Attributes der Hash in Form eines URL-Parameters angefügt:
<link rel="stylesheet" href="/css/full.min.css?v=1wp5zz4e-mOPFx4X2O8seW_DmUtePn5xFJk1vB7JKRc" />
Dies nennt sich Cache busting. Sie verhindert die Zwischenspeicherung des Stylesheets durch den Browser, wodurch Änderungen nicht oder erst verspätet geladen und somit sichtbar werden. Bei den alten ASP.NET Bundles wurde er automatisch eingefügt, wenn das Projekt nicht im Debug-Modus gestartet wird.