Поделиться через


Запуск приложений

Совет

Это содержимое является фрагментом из электронной книги Blazor для ASP NET веб-формы разработчиков для Azure, доступных в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.

Blazor-for-ASP-NET-Web-Forms-Developers eBook cover thumbnail.

Приложения, написанные для ASP.NET, обычно имеют файл global.asax.cs, определяющий событие Application_Start, которое управляет тем, какие службы настроены и доступны как для преобразования для просмотра HTML, так и для обработки .NET. В этой главе рассматриваются небольшие различия между ASP.NET Core и Blazor Server.

Application_Start и Web Forms

Метод Web Forms по умолчанию Application_Start разросся в течение нескольких лет для решения многих задач настройки. Новый проект Web Forms с шаблоном по умолчанию в Visual Studio 2022 теперь содержит следующую логику конфигурации:

  • RouteConfig — маршрутизация URL-адресов приложений.
  • BundleConfig — объединение и минификация CSS и JavaScript.

Каждый из этих отдельных файлов находится в папке App_Start и запускается только один раз в начале приложения. RouteConfig в шаблоне проекта по умолчанию добавляет FriendlyUrlSettings для Web Forms, чтобы разрешить URL-адресам приложений опустить расширение файла .ASPX. Шаблон по умолчанию также содержит директиву, которая предоставляет постоянные коды состояния перенаправления HTTP (HTTP 301) для страниц .ASPX по понятному URL-адресу с именем файла, в котором пропущено расширение.

В ASP.NET Core и Blazor эти методы либо упрощены и объединяются в класс Startup, либо устраняются в пользу распространенных веб-технологий.

Структура класса Startup Blazor Server

Приложения Blazor Server размещаются поверх ASP.NET Core 3.0 или более поздней версии. Веб-приложения ASP.NET Core настраиваются в файле Program.cs или с помощью пары методов класса Startup.cs. Вот пример файла 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();

Необходимые для приложения службы добавляются в коллекцию Services экземпляра WebApplicationBuilder. Вот как настраиваются различные службы платформы ASP.NET Core с помощью встроенного контейнера внедрения зависимостей платформы. Различные методы builder.Services.Add* добавляют службы, которые включают такие функции, как проверка подлинности, Razor Pages, маршрутизация контроллера MVC, SignalR и взаимодействие с Blazor Server, среди многих других. Этот метод не требовался в веб-формах, так как синтаксический анализ и обработка файлов ASPX, ASCX, ASHX и ASMX были определены ссылками на ASP.NET в файле конфигурации web.config. Дополнительные сведения о внедрении зависимостей в ASP.NET Core доступны в интерактивной документации.

После сборки app с помощью builder остальные вызовы в app настраивают соответствующий конвейер HTTP. С использованием этих вызовов мы объявляем сверху вниз ПО промежуточного слоя, которое будет обрабатывать все запросы, отправленные в наше приложение. Большинство этих функций в конфигурации по умолчанию были разбиты по файлам конфигурации Web Forms и теперь находятся в одном месте для простоты ссылок.

Конфигурация настраиваемой страницы ошибок больше не помещается в файл web.config, теперь она настроена так, чтобы всегда отображаться, если среда приложения не помечена Development. Кроме того, приложения ASP.NET Core настроены для предоставления защищенных страниц с помощью TLS по умолчанию, используя вызов метода UseHttpsRedirection.

Далее к UseStaticFiles выполняется непредвиденный вызов метода конфигурации. В ASP.NET Core поддержка запросов для статических файлов (таких как JavaScript, CSS и файлы изображений) должна быть явно включена. По умолчанию общедоступными могут быть только файлы в папке wwwroot приложения.

Следующая строка является первой, которая реплицирует один из параметров конфигурации из Web Forms: UseRouting. Этот метод добавляет маршрутизатор ASP.NET Core к конвейеру, который можно настроить здесь или в отдельных файлах, к которым может быть выполнена маршрутизация. Дополнительные сведения о конфигурации маршрутизации см. в разделе "Маршрутизация".

Последние вызовы app.Map* в этом методе определяют конечные точки, которые прослушивает ASP.NET Core. Эти маршруты представляют собой доступные в Интернете расположения, к которым вы можете получить доступ на веб-сервере для получения некоторого содержимого, обрабатываемого .NET, и возвращаемого вам. Первая запись, MapBlazorHub, настраивает концентратор SignalR для предоставления постоянного подключения в режиме реального времени к серверу, где обрабатывается состояние и преобразование для просмотра компонентов Blazor. Вызов метода MapFallbackToPage указывает на веб-расположение страницы, которая запускает приложение Blazor, а также настраивает приложение для обработки запросов на глубокую компоновку со стороны клиента. Эту функцию можно увидеть в действии, если открыть браузер и перейти непосредственно к обработанному Blazor маршруту в приложении, например /counter в шаблоне проекта по умолчанию. Запрос обрабатывается с помощью резервной страницы _Host. cshtml, которая затем запускает маршрутизатор Blazor и визуализирует страницу счетчика.

Последняя строка запускает приложение, которое не требовалось в веб-формах (так как для его работы требовалось выполнение IIS).

Обновление процесса BundleConfig

Технологии объединения таких ресурсов, как каскадные таблицы стилей и файлы JavaScript, значительно изменились благодаря другим технологиям, обеспечивающим быстрое развитие средств и методов управления этими ресурсами. Для этого мы рекомендуем использовать средство командной строки узла, такое как Grunt/Gulp/WebPack, для упаковки статических ресурсов.

Средства командной строки Grunt, Gulp и WebPack и связанные с ними конфигурации могут быть добавлены в приложение, а ASP.NET Core будет тихо игнорировать эти файлы в процессе сборки приложения. Можно добавить вызов для выполнения их задач, добавив Target в файл проекта с синтаксисом, аналогичным приведенному ниже, который активирует скрипт gulp и целевой объект min внутри этого скрипта:

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

Дополнительные сведения о обеих стратегиях управления файлами CSS и JavaScript можно найти в документации по Объединению и минификации статических ресурсов в ASP.NET Core.