App-Start

Tipp

Diese Inhalte sind ein Auszug aus dem eBook „Blazor for ASP NET Web Forms Developers for Azure“, verfügbar unter .NET Docs oder als kostenlos herunterladbare PDF-Datei, die offline gelesen werden kann.

PDF herunterladen

Anwendungen, die für ASP.NET geschrieben werden, enthalten normalerweise die Datei global.asax.cs, mit der das Ereignis Application_Start definiert wird. Hiermit wird gesteuert, welche Dienste konfiguriert und für das HTML-Rendering und die .NET-Verarbeitung verfügbar gemacht werden. In diesem Kapitel wird beschrieben, inwiefern dies bei ASP.NET Core und Blazor Server leicht abweicht.

Application_Start und Web Forms

Die Bedeutung der Web Forms-Standardmethode Application_Start hat im Laufe der Jahre zugenommen, und sie wird für die Durchführung vieler Konfigurationsaufgaben verwendet. Ein neues Web Forms-Projekt mit der Standardvorlage in Visual Studio 2022 enthält jetzt die folgende Konfigurationslogik:

• RouteConfig: Anwendungs-URL-Routing
• BundleConfig: CSS- und JavaScript-Bündelung und -Minimierung

Jede dieser einzelnen Dateien befindet sich im Ordner App_Start und wird nur einmal beim Starten Ihrer Anwendung ausgeführt. Mit RouteConfig in der Standardprojektvorlage wird FriendlyUrlSettings für Web Forms hinzugefügt, damit für Anwendungs-URLs die Dateierweiterung .ASPX weggelassen werden kann. Die Standardvorlage enthält auch eine Direktive, mit der dauerhafte HTTP-Umleitungsstatuscodes (HTTP 301) für die .ASPX-Seiten für die Friendly URL mit dem Dateinamen ohne Erweiterung bereitgestellt werden.

Bei ASP.NET Core und Blazor werden diese Methoden entweder vereinfacht und in der Klasse Startup zusammengefasst, oder sie werden durch gängige Webtechnologie ersetzt.

Startstruktur für Blazor Server

Blazor Server-Anwendungen basieren auf Version 3.0 von ASP.NET Core (oder höher). ASP.NET Core-Webanwendungen werden in Program.cs oder über ein Methodenpaar in der Klasse Startup.cs konfiguriert. Die folgende Abbildung zeigt ein Beispiel einer Datei Program.cs:

using BlazorApp1.Data;
using Microsoft.AspNetCore.Components;
using Microsoft.AspNetCore.Components.Web;

var builder = WebApplication.CreateBuilder(args);

// Add services to the container.
builder.Services.AddRazorPages();
builder.Services.AddServerSideBlazor();
builder.Services.AddSingleton<WeatherForecastService>();

var app = builder.Build();

// Configure the HTTP request pipeline.
if (!app.Environment.IsDevelopment())
{
    app.UseExceptionHandler("/Error");
    // The default HSTS value is 30 days. You may want to change this for production scenarios, see https://aka.ms/aspnetcore-hsts.
    app.UseHsts();
}

app.UseHttpsRedirection();
app.UseStaticFiles();
app.UseRouting();
app.MapBlazorHub();
app.MapFallbackToPage("/_Host");

app.Run();

Die erforderlichen Dienste der App werden der Services-Sammlung von Instanz WebApplicationBuilder hinzugefügt. So werden die verschiedenen Dienste des ASP.NET Core-Frameworks mit dem im Framework integrierten Container für die Abhängigkeitsinjektion konfiguriert. Mit den verschiedenen builder.Services.Add*-Methoden werden Dienste hinzugefügt, die die Nutzung bestimmter Features ermöglichen, z. B. Authentifizierung, Razor Pages, MVC-Controller-Routing, SignalR und Blazor Server-Interaktionen sowie weitere Features. Diese Methode wurde in Web Forms nicht benötigt, da die Analyse und Verarbeitung der ASPX-, ASCX-, ASHX- und ASMX-Dateien definiert wurde, indem in der web.config-Konfigurationsdatei auf ASP.NET verwiesen wurde. Weitere Informationen zur Abhängigkeitsinjektion in ASP.NET Core finden Sie in der Onlinedokumentation.

Nachdem app über builder erstellt wurde, konfigurieren die übrigen Aufrufe für app die zugehörige HTTP-Pipeline. Mit diesen Aufrufen deklarieren wir von oben nach unten die Middleware, mit der die einzelnen Anforderungen verarbeitet werden, die an unsere Anwendung gesendet werden. Die meisten dieser Features der Standardkonfiguration waren auf die Web Forms-Konfigurationsdateien verteilt und befinden sich nun an einem zentralen Ort, um die Nutzung zu vereinfachen.

Die Konfiguration der benutzerdefinierten Fehlerseite ist nicht mehr in einer web.config-Datei enthalten. Jetzt ist festgelegt, dass sie immer angezeigt wird, wenn die Anwendungsumgebung nicht über die Bezeichnung Development verfügt. Darüber hinaus sind die ASP.NET Core-Anwendungen jetzt so konfiguriert, dass mit dem Methodenaufruf UseHttpsRedirection standardmäßig sichere Seiten über TLS bereitgestellt werden.

Als Nächstes erfolgt ein unerwarteter Konfigurationsmethodenaufruf an UseStaticFiles. In ASP.NET Core muss die Unterstützung für statische Dateien (z. B. JavaScript, CSS und Bilddateien) explizit aktiviert werden, und nur Dateien im Ordner wwwroot der App sind standardmäßig öffentlich erreichbar.

Die nächste Zeile ist die erste Zeile, in der eine der Konfigurationsoptionen aus Web Forms repliziert wird: UseRouting. Mit dieser Methode wird der ASP.NET Core-Router der Pipeline hinzugefügt. Hierbei kann die Konfiguration entweder hier oder in den einzelnen Dateien erfolgen, die für das Routing in Frage kommen. Weitere Informationen zur Routingkonfiguration finden Sie unter Seiten, Routing und Layouts.

Die abschließenden app.Map*-Aufrufe definieren die Endpunkte, an denen ASP.NET Core lauscht. Diese Routen sind die über das Web zugänglichen Orte, auf die Sie über den Webserver zugreifen und Inhalte empfangen können, die per .NET verarbeitet und an Sie zurückgegeben werden. Mit dem ersten Eintrag MapBlazorHub wird ein SignalR-Hub für die Verwendung bei der Bereitstellung der Echtzeit- und dauerhaften Verbindung mit dem Server konfiguriert, auf dem der Status und das Rendering von Blazor-Komponenten verarbeitet werden. Mit dem Methodenaufruf MapFallbackToPage wird der über das Web zugängliche Ort der Seite angegeben, über die die Blazor-Anwendung gestartet und die Anwendung so konfiguriert wird, dass Deep-Linking-Anforderungen der Clientseite verarbeitet werden können. Sie können dieses Feature in Aktion erleben, wenn Sie einen Browser öffnen und in Ihrer Anwendung direkt zu einer von Blazor verarbeiteten Route navigieren, z. B. /counter in der Standardprojektvorlage. Die Anforderung wird über die Fallbackseite _Host.cshtml verarbeitet, von der dann der Blazor-Router ausgeführt und die Zählerseite gerendert wird.

In der allerletzten Zeile wird die Anwendung gestartet, was bei Webformularen nicht erforderlich war (da sie sich auf die Ausführung von IIS verließen).

Aktualisieren des BundleConfig-Prozesses

Die Weiterentwicklung der Technologie für die Bündelung von Ressourcen wie CSS-Stylesheets und JavaScript-Dateien wurde stark vorangetrieben. Es sind auch weitere Technologielösungen mit sich schnell entwickelnden Tools und Verfahren verfügbar, mit denen diese Ressourcen verwaltet werden können. Hierfür empfehlen wir die Verwendung eines Node-Befehlszeilentools, z. B. Grunt, gulp oder WebPack, um Ihre statischen Ressourcen zu verpacken.

Die Befehlszeilentools Grunt, gulp und WebPack und die zugehörigen Konfigurationen können Ihrer Anwendung hinzugefügt werden. Diese Dateien werden von ASP.NET Core beim Buildvorgang der Anwendung stillschweigend ignoriert. Sie können einen Aufruf für die Ausführung der Aufgaben hinzufügen. Fügen Sie in Ihrer Projektdatei hierfür ein Target-Element mit der folgenden Syntax hinzu, mit der ein gulp-Skript und das Ziel min innerhalb dieses Skripts ausgelöst werden:

<Target Name="MyPreCompileTarget" BeforeTargets="Build">
  <Exec Command="gulp min" />
</Target>

Weitere Informationen zu den beiden Strategien für die Verwaltung Ihrer CSS- und JavaScript-Dateien finden Sie in der Dokumentation unter Bündelung und Minimierung statischer Ressourcen in ASP.NET Core.

ZurückWeiter