Start der App

Tipp

Dieser Inhalt ist ein Auszug aus dem eBook Blazor für ASP NET Web Forms Developers für Azure, verfügbar auf .NET Docs oder als kostenlose herunterladbare PDF, die offline gelesen werden kann.

PDF herunterladen

Anwendungen, die für ASP.NET geschrieben wurden, verfügen in der Regel über eine global.asax.cs Datei, die das Application_Start Ereignis definiert, das steuert, welche Dienste konfiguriert und für die HTML-Rendering- und .NET-Verarbeitung zur Verfügung gestellt werden. In diesem Kapitel wird erläutert, wie sich die Dinge mit ASP.NET Core und Blazor Server geringfügig unterscheiden.

Application_Start und Webformulare

Die Standardwebformularmethode Application_Start hat sich im Laufe der Jahre für die Verarbeitung vieler Konfigurationsaufgaben entwickelt. Ein neues Webformularprojekt mit der Standardvorlage in Visual Studio 2022 enthält nun die folgende Konfigurationslogik:

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

Jede dieser einzelnen Dateien befindet sich im App_Start Ordner und wird nur einmal zu Beginn unserer 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, die permanente HTTP-Umleitungsstatuscodes (HTTP 301) für die .ASPX Seiten zur benutzerfreundlichen URL mit dem Dateinamen bereitstellt, der die Erweiterung auslässt.

Mit ASP.NET Core und Blazor werden diese Methoden entweder vereinfacht und in die Startup Klasse konsolidiert oder zugunsten gängiger Webtechnologien eliminiert.

Blazor Server-Startstruktur

Blazor Server-Anwendungen befinden sich auf einer ASP.NET Core 3.0- oder höher-Version. ASP.NET Core-Webanwendungen werden in Program.cs oder über ein Methodenpaar in der Startup.cs Klasse konfiguriert. Nachfolgend finden Sie ein Beispiel Program.cs Datei:

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 Sammlung der WebApplicationBuilder Instanz Services hinzugefügt. So werden die verschiedenen ASP.NET Core Framework-Dienste mit dem integrierten Abhängigkeitsinjektionscontainer des Frameworks 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 Webformularen nicht benötigt, da die Analyse und Verarbeitung der ASPX-, ASCX-, ASHX- und ASMX-Dateien durch Verweisen auf ASP.NET in der web.config Konfigurationsdatei definiert wurden. Weitere Informationen zur Abhängigkeitsinjektion in ASP.NET Core finden Sie in der Onlinedokumentation.

Nachdem der app von builder erstellt wurde, konfigurieren die restlichen Aufrufe auf app seine HTTP-Pipeline. Mit diesen Aufrufen deklarieren wir von oben nach unten die Middleware , die jede anforderung verarbeitet, die an unsere Anwendung gesendet wird. Die meisten dieser Features in der Standardkonfiguration wurden über die Konfigurationsdateien von Webformularen verteilt und befinden sich nun an einer zentralen Stelle, um einfacher zu referenzieren.

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

Als Nächstes erfolgt ein unerwarteter Konfigurationsmethodenaufruf an UseStaticFiles. In ASP.NET Core müssen Die Unterstützung für Anforderungen für statische Dateien (z. B. JavaScript, CSS und Bilddateien) explizit aktiviert sein, und nur Dateien im wwwroot-Ordner der App können standardmäßig öffentlich adressierbar sein.

Die nächste Zeile ist die erste, die eine der Konfigurationsoptionen aus Webformularen repliziert: 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 im Abschnitt "Routing".

Die letzten app.Map* Aufrufe in diesem Abschnitt definieren die Endpunkte, die ASP.NET Core überwacht. 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. Der erste Eintrag MapBlazorHub konfiguriert einen SignalR-Hub für die Bereitstellung der Echtzeit- und persistenten Verbindung mit dem Server, auf dem der Zustand und das Rendering von Blazor-Komponenten verarbeitet werden. Der MapFallbackToPage Methodenaufruf gibt den Webzugriffsort der Seite an, die die Blazor-Anwendung startet, und konfiguriert die Anwendung auch für die Verarbeitung von Deep-Linking-Anforderungen von clientseitiger Seite. Dieses Feature sehen Sie in Aktion, wenn Sie einen Browser öffnen und direkt zu einer von Blazor verarbeiteten Route in Ihrer Anwendung navigieren, z. B. in der Standardprojektvorlage mit /counter. Die Anforderung wird von der _Host.cshtml-Fallbackseite verarbeitet, die dann den Blazor-Router ausführt und die Zählerseite rendert.

Die letzte Zeile startet die Anwendung, etwas, das in Webformularen nicht erforderlich war (da iis für die Ausführung verwendet wurde).

Upgrade des BundleConfig-Prozesses

Technologien zum Bündeln von Ressourcen wie CSS-Stylesheets und JavaScript-Dateien haben sich erheblich geändert, mit anderen Technologien, die sich schnell entwickelnde Tools und Techniken für die Verwaltung dieser Ressourcen bieten. Zu diesem Zweck empfehlen wir die Verwendung eines Node-Befehlszeilentools wie Grunt / Gulp / WebPack, um Ihre statischen Objekte zu verpacken.

Die Befehlszeilentools Grunt, Gulp und WebPack und ihre zugehörigen Konfigurationen können Ihrer Anwendung hinzugefügt werden, und ASP.NET Core ignoriert diese Dateien während des Anwendungsbuildprozesses leise. 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 Details zu beiden Strategien zum Verwalten von CSS- und JavaScript-Dateien finden Sie in der Bündeln und Minimieren statischer Ressourcen in der Dokumentation zu ASP.NET Core.

ZurückWeiter