Uruchamianie aplikacji

Napiwek

Ta zawartość jest fragmentem książki eBook Blazor for ASP NET Web Forms Developers for Azure, dostępnej na platformie .NET Docs lub jako bezpłatny plik PDF do pobrania, który można odczytać w trybie offline.

Pobierz plik PDF

Aplikacje napisane dla ASP.NET zazwyczaj mają global.asax.cs plik definiujący Application_Start zdarzenie, które kontroluje, które usługi są skonfigurowane i udostępniane do renderowania HTML i przetwarzania platformy .NET. W tym rozdziale omówiono nieco różnice między elementami ASP.NET Core i Blazor Server.

Application_Start i formularze sieci Web

Domyślna metoda formularzy Application_Start internetowych wzrosła w ciągu lat, aby obsługiwać wiele zadań konfiguracyjnych. Nowy projekt formularzy internetowych z szablonem domyślnym w programie Visual Studio 2022 zawiera teraz następującą logikę konfiguracji:

• RouteConfig — Routing adresów URL aplikacji
• BundleConfig - CSS i JavaScript bundling and minification

Każdy z tych pojedynczych plików znajduje się w App_Start folderze i jest uruchamiany tylko raz na początku naszej aplikacji. RouteConfig W domyślnym szablonie projektu dodano formularze FriendlyUrlSettings dla formularzy internetowych, aby umożliwić adresom URL aplikacji pominięcie .ASPX rozszerzenia pliku. Szablon domyślny zawiera również dyrektywę, która udostępnia trwałe kody stanu przekierowania HTTP (HTTP 301) dla .ASPX stron przyjazny adres URL z nazwą pliku pomijającą rozszerzenie.

W przypadku ASP.NET Core i Blazor te metody są uproszczone i skonsolidowane w Startup klasie lub są one wyeliminowane na rzecz typowych technologii internetowych.

Struktura uruchamiania serwera Blazor

Aplikacje platformy Blazor Server znajdują się w wersji ASP.NET Core 3.0 lub nowszej. ASP.NET Core aplikacje internetowe są konfigurowane w Program.cs lub za pomocą pary metod w Startup.cs klasie. Poniżej przedstawiono przykładowy plik 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();

Wymagane usługi aplikacji są dodawane do WebApplicationBuilder kolekcji Services wystąpienia. W ten sposób różne usługi platformy ASP.NET Core są konfigurowane za pomocą wbudowanego kontenera iniekcji zależności platformy. Różne builder.Services.Add* metody dodają usługi, które umożliwiają między innymi funkcje, takie jak uwierzytelnianie, strony razor, routing kontrolera MVC, signalR i interakcja serwera Blazor. Ta metoda nie była potrzebna w formularzach internetowych, ponieważ analizowanie i obsługa plików ASPX, ASCX, ASHX i ASMX zostały zdefiniowane przez odwołanie ASP.NET w pliku konfiguracji web.config. Więcej informacji na temat wstrzykiwania zależności w programie ASP.NET Core jest dostępne w dokumentacji online.

Po skompiluj builderelement app , pozostałe wywołania konfigurują app jego potok HTTP. Za pomocą tych wywołań deklarujemy od góry do dołu oprogramowanie pośredniczące, które będzie obsługiwać każde żądanie wysłane do naszej aplikacji. Większość z tych funkcji w konfiguracji domyślnej została rozrzucona w plikach konfiguracji formularzy internetowych i jest teraz w jednym miejscu, aby ułatwić odwołanie.

Nie jest już konfiguracją niestandardowej strony błędu umieszczonej web.config w pliku, ale teraz jest skonfigurowany tak, aby zawsze był wyświetlany, jeśli środowisko aplikacji nie ma etykiety Development. Ponadto aplikacje ASP.NET Core są teraz skonfigurowane do obsługi bezpiecznych stron przy użyciu protokołu TLS domyślnie z wywołaniem UseHttpsRedirection metody.

Następnie jest wykonywane nieoczekiwane wywołanie metody konfiguracji na .UseStaticFiles W ASP.NET Core obsługa żądań dotyczących plików statycznych (takich jak JavaScript, CSS i pliki obrazów) musi być jawnie włączona, a tylko pliki w folderze wwwroot aplikacji są domyślnie adresowane publicznie.

Następny wiersz to pierwszy, który replikuje jedną z opcji konfiguracji z formularzy internetowych: UseRouting. Ta metoda dodaje router ASP.NET Core do potoku i można go skonfigurować w tym miejscu lub w poszczególnych plikach, do których może rozważyć routing. Więcej informacji na temat konfiguracji routingu można znaleźć w sekcji Routing.

Ostatnie app.Map* wywołania w tej sekcji definiują punkty końcowe, na których nasłuchuje ASP.NET Core. Te trasy są lokalizacjami dostępnymi w Internecie, do których można uzyskać dostęp na serwerze internetowym i odbierać zawartość obsługiwaną przez platformę .NET i zwracaną do Ciebie. Pierwszy wpis MapBlazorHub konfiguruje centrum SignalR do użycia w celu zapewnienia połączenia w czasie rzeczywistym i trwałego z serwerem, na którym jest obsługiwany stan i renderowanie składników platformy Blazor. Wywołanie MapFallbackToPage metody wskazuje dostępną w Internecie lokalizację strony, która uruchamia aplikację Blazor, a także konfiguruje aplikację do obsługi żądań łączenia głębokiego po stronie klienta. Ta funkcja będzie widoczna w pracy, jeśli otworzysz przeglądarkę i przejdziesz bezpośrednio do trasy obsługiwanej przez platformę Blazor w aplikacji, na przykład /counter w domyślnym szablonie projektu. Żądanie jest obsługiwane przez stronę rezerwową _Host.cshtml , która następnie uruchamia router Blazor i renderuje stronę licznika.

Ostatni wiersz uruchamia aplikację, co nie było wymagane w formularzach internetowych (ponieważ polegało na uruchomieniu usług IIS).

Uaktualnianie procesu BundleConfig

Technologie tworzenia pakietów zasobów, takich jak arkusze stylów CSS i pliki JavaScript, uległy znacznej zmianie, a inne technologie zapewniają szybkie rozwijanie narzędzi i technik zarządzania tymi zasobami. W tym celu zalecamy użycie narzędzia wiersza polecenia Node, takiego jak Grunt / Gulp / WebPack, aby spakować zasoby statyczne.

Narzędzia wiersza polecenia Grunt, Gulp i WebPack oraz skojarzone z nimi konfiguracje można dodać do aplikacji, a ASP.NET Core po cichu zignoruje te pliki podczas procesu kompilacji aplikacji. Możesz dodać wywołanie, aby uruchomić swoje zadania, dodając Target wewnątrz pliku projektu składnię podobną do następującej, która wyzwoli skrypt gulp i min element docelowy wewnątrz tego skryptu:

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

Więcej szczegółowych informacji na temat obu strategii zarządzania plikami CSS i JavaScript można znaleźć w artykule Bundle (Pakiet) i minify static assets in ASP.NET Core documentation (Pakiet) i minify static assets in ASP.NET Core documentation (Elementy statyczne).

PoprzedniNastępny