Примечание
Для доступа к этой странице требуется авторизация. Вы можете попробовать войти или изменить каталоги.
Для доступа к этой странице требуется авторизация. Вы можете попробовать изменить каталоги.
Совет
Это содержимое является фрагментом из электронной книги Blazor для ASP NET веб-формы разработчиков для Azure, доступных в документации .NET или в виде бесплатного скачиваемого PDF-файла, который можно прочитать в автономном режиме.
Приложения, написанные для 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.