Важно!
Эта информация относится к предварительному выпуску продукта, который может быть существенно изменен до его коммерческого выпуска. Корпорация Майкрософт не предоставляет никаких гарантий, явных или подразумеваемых в отношении информации, предоставленной здесь.
Актуальная версия — см. версию этой статьи для .NET 9.
В этой статье объясняется, как размещать и развертывать Blazor WebAssembly приложения.
При использовании модели хостинга Blazor WebAssembly:
- Приложение Blazor, его зависимости и среда выполнения .NET скачиваются в браузере параллельно.
- Приложение выполняется непосредственно в потоке пользовательского интерфейса браузера.
Эта статья относится к сценарию развертывания, в котором Blazor приложение размещается на статическом веб-сервере или службе размещения, .NET не используется для обслуживания Blazor приложения. Эта стратегия рассматривается в разделе изолированного развертывания и других статьях этого раздела для служб IIS, служб Azure, Apache, Nginx и GitHub Pages.
Поддерживаются следующие стратегии развертывания:
Размещение поддомена и подприложения IIS
Для размещения поддомена не требуется специальная конфигурация приложения. Вам не нужно настраивать базовый путь приложения (тег <base>
в wwwroot/index.html
) для размещения приложения в поддомене.
Для размещения подприложений IIS действительно требуется установить базовый путь приложения. Дополнительные сведения и ссылки на дополнительные рекомендации по размещению подприложений IIS см. в Размещение и развертывание ASP.NET Core Blazor.
Уменьшение максимального размера кучи для некоторых браузеров мобильных устройств
При создании Blazor приложения, работающего .Client
на клиенте (Blazor Web App проекте или автономном Blazor WebAssembly приложении) и предназначенного для браузеров мобильных устройств, особенно Safari на iOS, может потребоваться снизить максимальный объём памяти приложения с помощью свойства EmccMaximumHeapSize
MSBuild. Значение по умолчанию — 2 147 483 648 байт, которое может быть слишком большим и привести к сбою приложения, если оно попытается выделить больше памяти, а браузер откажется её предоставить. В следующем примере значение устанавливается на 268 435 456 байт в файле Program
:
При создании приложения, предназначенного для браузеров мобильных устройств, особенно Safari на iOS, возможно, потребуется уменьшить максимальную память для приложения с использованием свойства MSBuild Blazor WebAssembly. Значение по умолчанию — 2 147 483 648 байт, которое может быть слишком большим и привести к сбою приложения, если оно попытается выделить больше памяти, а браузер откажется её предоставить. В следующем примере значение устанавливается на 268 435 456 байт в файле Program
:
<EmccMaximumHeapSize>268435456</EmccMaximumHeapSize>
Дополнительную информацию о свойствах и целях MSBuild для Mono/WebAssembly можно найти в
Формат упаковки Webcil для .NET-сборок
Webcil — это удобный для интернета формат упаковки сборок .NET, предназначенный для использования Blazor WebAssembly в ограничивающих сетевых средах. Файлы Webcil используют стандартную оболочку WebAssembly, где сборки развертываются как файлы WebAssembly, использующие стандартное .wasm
расширение файла.
Webcil — это формат упаковки по умолчанию при публикации Blazor WebAssembly приложения. Чтобы отключить использование Webcil, задайте в файле проекта приложения следующее свойство MSBuild:
<PropertyGroup>
<WasmEnableWebcil>false</WasmEnableWebcil>
</PropertyGroup>
Настройка способа загрузки загрузочных ресурсов
Настройте способ загрузки загрузочных ресурсов с помощью API loadBootResource
. Дополнительные сведения см. в статье Запуск ASP.NET Core Blazor.
При публикации приложения Blazor WebAssembly выходные данные статически сжимаются, чтобы уменьшить размер приложения и исключить издержки на сжатие среды выполнения. Используются следующие алгоритмы сжатия:
Blazor полагается на хост для предоставления соответствующих сжатых файлов. При размещении автономного приложения Blazor WebAssembly, возможно, потребуется реализовать дополнительные действия для обслуживания статически сжатых файлов.
Blazor полагается на хост для предоставления соответствующих сжатых файлов. При использовании проекта ASP.NET Core Hosted, хост-проект способен выполнять согласование содержания и предоставлять статически сжатые файлы. При размещении автономного приложения Blazor WebAssembly, возможно, потребуется реализовать дополнительные действия для обслуживания статически сжатых файлов.
- Сведения о конфигурации сжатия IIS
web.config
см. в разделе IIS: сжатие Brotli и Gzip.
- При размещении на статических сервисах хостинга, которые не поддерживают переговоры о содержимом для статически сжатых файлов, рассмотрите возможность настройки приложения для извлечения и декодирования сжатых файлов Brotli.
Получите декодатор JavaScript Brotli из google/brotli
репозитория GitHub. Сокращенный файл декодера называется decode.min.js
и находится в папке js
репозитория.
Примечание
Если сокращенная версия скрипта decode.js
(decode.min.js
) не работает, попробуйте вместо нее использовать не сокращенную версию (decode.js
).
обновите приложение для использования декодера.
В файле wwwroot/index.html
установите для autostart
значение false
в теге Blazor элемента <script>
:
<script src="_framework/blazor.webassembly.js" autostart="false"></script>
После тега Blazor<script>
и перед закрывающим тегом </body>
добавьте следующий блок JavaScript-кода <script>
. Следующая функция вызывает fetch
с cache: 'no-cache'
для обновления кэша браузера.
Blazor Web App:
<script type="module">
import { BrotliDecode } from './decode.min.js';
Blazor.start({
webAssembly: {
loadBootResource: function (type, name, defaultUri, integrity) {
if (type !== 'dotnetjs' && location.hostname !== 'localhost' && type !== 'configuration' && type !== 'manifest') {
return (async function () {
const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
if (!response.ok) {
throw new Error(response.statusText);
}
const originalResponseBuffer = await response.arrayBuffer();
const originalResponseArray = new Int8Array(originalResponseBuffer);
const decompressedResponseArray = BrotliDecode(originalResponseArray);
const contentType = type ===
'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
return new Response(decompressedResponseArray,
{ headers: { 'content-type': contentType } });
})();
}
}
}
});
</script>
Самостоятельное Blazor WebAssembly:
<script type="module">
import { BrotliDecode } from './decode.min.js';
Blazor.start({
loadBootResource: function (type, name, defaultUri, integrity) {
if (type !== 'dotnetjs' && location.hostname !== 'localhost' && type !== 'configuration') {
return (async function () {
const response = await fetch(defaultUri + '.br', { cache: 'no-cache' });
if (!response.ok) {
throw new Error(response.statusText);
}
const originalResponseBuffer = await response.arrayBuffer();
const originalResponseArray = new Int8Array(originalResponseBuffer);
const decompressedResponseArray = BrotliDecode(originalResponseArray);
const contentType = type ===
'dotnetwasm' ? 'application/wasm' : 'application/octet-stream';
return new Response(decompressedResponseArray,
{ headers: { 'content-type': contentType } });
})();
}
}
});
</script>
Дополнительные сведения о загрузке загрузочных ресурсов см. в статье Запуск ASP.NET Core Blazor.
Чтобы отключить сжатие, добавьте свойство CompressionEnabled
MSBuild в файл проекта приложения и задайте для него значение false
.
<PropertyGroup>
<CompressionEnabled>false</CompressionEnabled>
</PropertyGroup>
Свойство CompressionEnabled
можно передать в команду dotnet publish
с помощью следующего синтаксиса в командной оболочке.
dotnet publish -p:CompressionEnabled=false
Чтобы отключить сжатие, добавьте свойство BlazorEnableCompression
MSBuild в файл проекта приложения и задайте для него значение false
.
<PropertyGroup>
<BlazorEnableCompression>false</BlazorEnableCompression>
</PropertyGroup>
Свойство BlazorEnableCompression
можно передать в команду dotnet publish
с помощью следующего синтаксиса в командной оболочке.
dotnet publish -p:BlazorEnableCompression=false
Переписывание URL-адресов для правильной маршрутизации
Запросы маршрутизации для компонентов страниц в Blazor WebAssembly приложении не так просто, как запросы маршрутизации в Blazor Server приложении. Рассмотрим сценарий с приложением Blazor WebAssembly с двумя компонентами:
-
Main.razor
: загружается в корне приложения и содержит ссылку на About
компонент (href="About"
).
-
About.razor
: компонент About
.
При запросе документа приложения по умолчанию в адресной строке браузера (например, https://www.contoso.com/
):
- Браузер отправляет запрос.
- Возвращается страница по умолчанию; обычно это
index.html
.
- Страница
index.html
обеспечивает начальную загрузку приложения.
-
Router компонент загружается, а Razor
Main
компонент отрисовывается.
На странице Main возможность выбора ссылки на компонент About
доступна на клиентском компьютере, так как маршрутизатор Blazor не разрешает браузеру сделать запрос в Интернете к www.contoso.com
для About
и сам обрабатывает отображенный компонент About
. Все запросы внутренних конечных точек в приложении работают одинаково: запросы через браузер не активируют запросы к размещенным на сервере ресурсам в Интернете. Маршрутизатор обрабатывает запросы внутренним образом.
Если запрос www.contoso.com/About
сделан с помощью адресной строки браузера, он завершится ошибкой. Такой ресурс не существует на интернет-узле приложения, поэтому возвращается ответ 404 — Not Found (не найдено).
Поскольку браузеры выполняют запросы к интернет-узлам для клиентских страниц, веб-серверам и службам хостинга необходимо переписывать все запросы к ресурсам, которые физически отсутствуют на сервере, на страницу index.html
. Когда возвращается index.html
, маршрутизатор Blazor приложения принимает управление и отвечает нужным ресурсом.
При развертывании на сервере IIS можно использовать модуль переопределения URL-адресов с опубликованным файлом web.config
приложения. Дополнительные сведения см. в разделе Хостинг и развертывание ASP.NET Core Blazor WebAssembly с помощью IIS.
Размещенное развертывание с использованием ASP.NET Core
Размещенное развертывание обслуживает приложение Blazor WebAssembly для браузеров из приложения ASP.NET Core, выполняющегося на веб-сервере.
Клиентское приложение Blazor WebAssembly будет опубликовано в папку /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot
серверного приложения вместе со статическими веб-ресурсами серверного приложения. Оба приложения развертываются вместе. Веб-сервер, позволяющий размещать приложения ASP.NET Core, является обязательным. Для размещаемого развертывания Visual Studio включает шаблон проекта Blazor WebAssembly Приложение (шаблон blazorwasm
, когда используется команда dotnet new
) с выбранной опцией Hosted
(-ho|--hosted
, когда используется команда dotnet new
).
Дополнительные сведения см. в следующих статьях:
Чтобы развернуть размещенное приложение Blazor WebAssembly в качестве исполняемого файла, зависящего от среды выполнения для определенной платформы (не автономной), используйте следующие рекомендации на основе используемых инструментов.
Автономное развёртывание настроено для сгенерированного профиля публикации.pubxml
. Убедитесь, что профиль публикации проекта Server содержит свойство MSBuild <SelfContained>
, которому присвоено значение false
.
В файле профиля публикации .pubxml
в папке Server проекта Properties
выполните следующие действия:
<SelfContained>false</SelfContained>
Задайте Идентификатор среды выполнения (RID) с помощью параметра Целевая среда выполнения в области Параметры пользовательского интерфейса Публикация, который создает свойство MSBuild <RuntimeIdentifier>
в профиле публикации:
<RuntimeIdentifier>{RID}</RuntimeIdentifier>
В предыдущей конфигурации заполнитель {RID}
представляет собой Идентификатор среды выполнения (RID).
Опубликуйте проект Server в конфигурации Выпуск.
Примечание
Вы можете опубликовать приложение с параметрами профиля публикации с помощью CLI .NET, передав /p:PublishProfile={PROFILE}
в команду dotnet publish
, где заполнитель {PROFILE}
представляет собой профиль. Дополнительные сведения см. в разделах Профили публикации и Пример публикации папки в статье Профили публикации Visual Studio (.pubxml) для развертывания приложения ASP.NET Core. Если вы передаете RID в команде dotnet publish
, а не в профиле публикации, используйте свойство MSBuild (/p:RuntimeIdentifier
) с командой, а не с -r|--runtime
параметром.
Интерфейс командной строки .NET
Настройте автономное развертывание, указав свойство MSBuild <SelfContained>
в секции <PropertyGroup>
файла проекта Server, установив его значение на false
:
<SelfContained>false</SelfContained>
Важно!
Свойство SelfContained
должно быть помещено в файл проекта Server. Свойство не может быть корректно задано с помощью команды dotnet publish
при использовании параметра --no-self-contained
или свойства MSBuild /p:SelfContained=false
.
Задайте Идентификатор среды выполнения (RID), используя любой из указанных ниже подходов:
Вариант 1. Задайте RID в разделе <PropertyGroup>
в файле проекта Server:
<RuntimeIdentifier>{RID}</RuntimeIdentifier>
В предыдущей конфигурации заполнитель {RID}
представляет собой Идентификатор среды выполнения (RID).
Опубликуйте приложение в конфигурации Release из проекта Server.
dotnet publish -c Release
Вариант 2: Передайте RID в команде dotnet publish
в качестве свойства MSBuild (/p:RuntimeIdentifier
), а не с параметром -r|--runtime
:
dotnet publish -c Release /p:RuntimeIdentifier={RID}
В предыдущей команде заполнитель {RID}
представляет собой Идентификатор среды выполнения (RID).
Дополнительные сведения см. в следующих статьях:
Автономное развертывание обрабатывает приложение Blazor WebAssembly как набор статических файлов, которые будут запрашиваться непосредственно клиентами. Любой статический файловый сервер способен обслуживать приложение Blazor.
Файлы автономного развертывания публикуются в папку /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot
или в папку bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish\
(в зависимости от используемой версии пакета SDK для .NET), где {TARGET FRAMEWORK}
заменитель является целевой платформой.
Blazor WebAssembly приложения можно развернуть в службах Azure App Services на Windows, где они размещаются на IIS.
Развертывание автономного приложения Blazor WebAssembly в Службе приложений Azure для Linux в настоящее время не поддерживается. Рекомендуем разместить автономное приложение Blazor WebAssembly с помощью службы Статические веб-приложения Azure, которая поддерживает этот сценарий.
Автономная работа с Docker
Автономное Blazor WebAssembly приложение публикуется в виде набора статических файлов для размещения статическим файловым сервером.
Чтобы разместить приложение в Docker, выполните следующие действия.
- Выберите контейнер Docker с поддержкой веб-сервера, например Nginx или Apache.
- Скопируйте активы папки
publish
в папку, определенную на веб-сервере для размещения статических файлов.
- При необходимости примените дополнительную конфигурацию для обслуживания Blazor WebAssembly приложения.
Инструкции по настройке см. в следующих ресурсах:
Значения конфигурации хоста
Приложения Blazor WebAssembly могут принимать следующие значения конфигурации узла в качестве аргументов командной строки во время выполнения в среде разработки.
Аргумент --contentroot
задает абсолютный путь к каталогу, где находятся файлы содержимого приложения (корневой каталог содержимого). В следующих примерах /content-root-path
— это путь к корневому каталогу содержимого приложения.
Передайте этот аргумент при локальном запуске приложения в командной строке. Перейдите в каталог приложения и выполните следующую команду:
dotnet watch --contentroot=/content-root-path
Добавьте запись в файл приложения launchSettings.json
в профиле IIS Express. Этот параметр используется при запуске приложения с отладчиком Visual Studio и из командной строки с dotnet watch
(или dotnet run
).
"commandLineArgs": "--contentroot=/content-root-path"
В Visual Studio укажите аргумент в меню Свойства>Отладка>Аргументы приложения. Установка аргумента на странице свойств Visual Studio добавляет аргумент в файл launchSettings.json
.
--contentroot=/content-root-path
Аргумент --pathbase
задает базовый путь приложения для локального выполнения с некорневым относительным путем URL (в теге <base>
переменная href
задана с путем, отличным от /
для промежуточной и рабочей среды). В следующих примерах /relative-URL-path
— это базовый путь приложения. Дополнительные сведения см. в разделе ASP.NET CoreBlazor Базовый путь к приложению.
Важно!
В отличие от пути, заданного через href
в теге <base>
, не ставьте завершающую косую черту (/
) когда передаёте значение аргумента --pathbase
. Если основной путь приложения задан в теге <base>
как <base href="/CoolApp/">
(включая косую черту в конце), передайте значение аргумента командной строки как --pathbase=/CoolApp
(без косой черты в конце).
Передайте этот аргумент при локальном запуске приложения в командной строке. Перейдите в каталог приложения и выполните следующую команду:
dotnet watch --pathbase=/relative-URL-path
Добавьте запись в файл приложения launchSettings.json
в профиле IIS Express. Этот параметр используется при запуске приложения с отладчиком Visual Studio и из командной строки с dotnet watch
(или dotnet run
).
"commandLineArgs": "--pathbase=/relative-URL-path"
В Visual Studio укажите аргумент в меню Свойства>Отладка>Аргументы приложения. Установка аргумента на странице свойств Visual Studio добавляет аргумент в файл launchSettings.json
.
--pathbase=/relative-URL-path
Дополнительные сведения см. в разделе ASP.NET Базовый путь к приложению CoreBlazor.
Аргумент --urls
задает IP-адреса или адреса узлов с портами и протоколами для прослушивания запросов.
Передайте этот аргумент при локальном запуске приложения в командной строке. Перейдите в каталог приложения и выполните следующую команду:
dotnet watch --urls=http://127.0.0.1:0
Добавьте запись в файл приложения launchSettings.json
в профиле IIS Express. Этот параметр используется при запуске приложения с отладчиком Visual Studio и из командной строки с dotnet watch
(или dotnet run
).
"commandLineArgs": "--urls=http://127.0.0.1:0"
В Visual Studio укажите аргумент в меню Свойства>Отладка>Аргументы приложения. Установка аргумента на странице свойств Visual Studio добавляет аргумент в файл launchSettings.json
.
--urls=http://127.0.0.1:0
Изменение расширения имени файла DLL-файлов
Этот раздел относится к ASP.NET Core 6.x и 7.x. В ASP.NET Core в .NET 8 или более поздней версии сборки .NET развертываются как файлы WebAssembly (.wasm
) с помощью формата файла Webcil. В ASP.NET Core в .NET 8 или более поздней версии этот раздел применяется только в том случае, если формат файла Webcil отключен в файле проекта приложения.
Если брандмауэр, антивирусная программа или сетевое устройство безопасности блокирует передачу файлов библиотеки динамической компоновки (DLL) приложения (.dll
), вы можете следовать инструкциям в этом разделе, чтобы изменить расширения имен файлов опубликованных DLL-файлов приложения.
Примечание
Изменение расширений имен файлов DLL приложения может не устранить проблему, так как многие системы безопасности сканируют содержимое файлов приложения, а не просто проверяют расширения файлов.
Для более надежного подхода в средах, которые блокируют загрузку и выполнение DLL-файлов, используйте ASP.NET Core в .NET 8 или более поздней версии, которая упаковает сборки .NET в виде файлов WebAssembly (.wasm
) с использованием формата файла Webcil . Дополнительные сведения см. в разделе о формате упаковки Webcil для .NET сборок в версии 8.0 или более поздней этой статьи.
Сторонние подходы существуют для решения этой проблемы. Дополнительные сведения см. в ресурсах на Awesome Blazor.
Примечание
Изменение расширений имен файлов DLL приложения может не устранить проблему, так как многие системы безопасности сканируют содержимое файлов приложения, а не просто проверяют расширения файлов.
Для более надежного подхода в средах, которые блокируют загрузку и выполнение DLL-файлов, выполните любой из следующих подходов:
- Используйте ASP.NET Core в .NET 8 или более поздней версии, которая упаковает сборки .NET в виде файлов WebAssembly (
.wasm
) с использованием формата файла Webcil . Дополнительные сведения см. в разделе о формате упаковки Webcil для .NET сборок в версии 8.0 или более поздней этой статьи.
- В ASP.NET Core в .NET 6 или более поздней версии используйте пользовательский макет развертывания.
Сторонние подходы существуют для решения этой проблемы. Дополнительные сведения см. в ресурсах на Awesome Blazor.
После публикации приложения используйте скрипт оболочки или конвейер сборки DevOps для переименования .dll
-файлов для использования другого расширения файла в каталоге опубликованных выходных данных приложения.
В следующих примерах:
- Для обновления расширений файлов используется PowerShell (PS).
- Файлы
.dll
переименовываются с использованием расширения имени файла .bin
из командной строки.
- Файлы, перечисленные в опубликованном Blazor манифесте загрузки с расширением
.dll
файла, обновляются до .bin
расширения файла.
- Если также используются ресурсы service worker, команда PowerShell обновляет файлы
.dll
, перечисленные в файле service-worker-assets.js
, изменяя расширение их имени на .bin
.
Чтобы использовать расширение файла, отличное от .bin
, замените .bin
в приведенных ниже командах нужным расширением файла.
В Windows:
dir {PATH} | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content {PATH}\dotnet.boot.js -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\dotnet.boot.js
dir {PATH} | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content {PATH}\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\blazor.boot.json
В приведенной выше команде заполнитель {PATH}
представляет собой путь к опубликованной папке _framework
(например, .\bin\Release\{TFM}\browser-wasm\publish\wwwroot\_framework
из корневой папки проекта, где заполнитель {TFM}
является идентификатором целевой платформы (TFM)).
Если рабочие ресурсы службы также используются, так как приложение является прогрессивным веб-приложением (PWA):
((Get-Content {PATH}\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\service-worker-assets.js
В предыдущей команде заполнитель {PATH}
— это путь к опубликованному файлу service-worker-assets.js
.
В Linux или macOS:
for f in {PATH}/*; do mv "$f" "`echo $f | sed -e 's/\.dll/.bin/g'`"; done
sed -i 's/\.dll"/.bin"/g' {PATH}/dotnet.boot.js
for f in {PATH}/*; do mv "$f" "`echo $f | sed -e 's/\.dll/.bin/g'`"; done
sed -i 's/\.dll"/.bin"/g' {PATH}/blazor.boot.json
В предыдущей команде {PATH}
заполнитель обозначает путь к опубликованной папке _framework
(например, .\bin\Release\{TFM}\browser-wasm\publish\wwwroot\_framework
от корневой папки проекта), где {TFM}
заполнитель соответствует моникеру целевого фреймворка (TFM).
Если рабочие ресурсы службы также используются, так как приложение является прогрессивным веб-приложением (PWA):
sed -i 's/\.dll"/.bin"/g' {PATH}/service-worker-assets.js
В предыдущей команде заполнитель {PATH}
— это путь к опубликованному файлу service-worker-assets.js
.
Для сжатых файлов dotnet.boot.js.gz
и dotnet.boot.js.br
используйте один из следующих подходов:
- Удалите сжатые файлы
dotnet.boot.js.gz
и dotnet.boot.js.br
.
Сжатие отключено с помощью этого подхода.
- Выполните повторное сжатие обновленного файла
dotnet.boot.js
.
Предыдущие рекомендации для сжатого файла dotnet.boot.js
также применимы при использовании ресурсов служебного работника. Выполните удаление или повторное сжатие файлов service-worker-assets.js.br
и service-worker-assets.js.gz
. иначе проверка целостности файлов в браузере завершится ошибкой.
В следующем примере Windows для .NET 6 или более поздней версии используется сценарий PowerShell, размещенный в корне проекта. Следующий сценарий, который отключает сжатие, является основой для дальнейшего изменения, если вы хотите повторно сжать файл dotnet.boot.js
. Передайте путь приложения и TFM в скрипт.
ChangeDLLExtensions.ps1:
:
param([string]$filepath,[string]$tfm)
dir $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\dotnet.boot.js -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\dotnet.boot.js
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\dotnet.boot.js.gz
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\dotnet.boot.js.br
Перекомпрессируйте dotnet.boot.js
, чтобы снова включить сжатие.
Для сжатых файлов blazor.boot.json.gz
и blazor.boot.json.br
используйте один из следующих подходов:
- Удалите сжатые файлы
blazor.boot.json.gz
и blazor.boot.json.br
.
Сжатие отключено с помощью этого подхода.
- Выполните повторное сжатие обновленного файла
blazor.boot.json
.
Предыдущие рекомендации для сжатого файла blazor.boot.json
также применимы при использовании ресурсов служебного работника. Выполните удаление или повторное сжатие файлов service-worker-assets.js.br
и service-worker-assets.js.gz
. иначе проверка целостности файлов в браузере завершится ошибкой.
В следующем примере Windows для .NET 6 до .NET 9 используется скрипт PowerShell, размещенный в корне проекта. Следующий сценарий, который отключает сжатие, является основой для дальнейшего изменения, если вы хотите повторно сжать файл blazor.boot.json
. Передайте путь приложения и TFM в скрипт.
ChangeDLLExtensions.ps1:
:
param([string]$filepath,[string]$tfm)
dir $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework | rename-item -NewName { $_.name -replace ".dll\b",".bin" }
((Get-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json.gz
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\blazor.boot.json.br
Повторно сожмите blazor.boot.json
, чтобы снова включить сжатие.
Если рабочие ресурсы службы также используются, так как приложение является прогрессивным веб-приложением (PWA), добавьте следующие команды:
((Get-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\service-worker-assets.js
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\service-worker-assets.js.gz
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\service-worker-assets.js.br
Повторное сжатие service-worker-assets.js
.
В файле проекта скрипт выполняется после публикации приложения для конфигурации Release
:
<Target Name="ChangeDLLFileExtensions" AfterTargets="AfterPublish" Condition="'$(Configuration)'=='Release'">
<Exec Command="powershell.exe -command "& { .\ChangeDLLExtensions.ps1 '$(SolutionDir)' '$(TargetFramework)'}"" />
</Target>
Как правило, серверу приложения требуется настройка статического ресурса для обслуживания файлов с обновленным расширением. Для приложения, размещенного в IIS, добавьте запись карты MIME (<mimeMap>
) для нового расширения файла в разделе статического содержимого (<staticContent>
) в пользовательском файле web.config
. В следующем примере предполагается, что расширение файла изменено на .dll
.bin
:
<staticContent>
...
<mimeMap fileExtension=".bin" mimeType="application/octet-stream" />
...
</staticContent>
Включите обновление для сжатых файлов, если сжатие используется:
<mimeMap fileExtension=".bin.br" mimeType="application/octet-stream" />
<mimeMap fileExtension=".bin.gz" mimeType="application/octet-stream" />
Удалите запись для файлового расширения .dll
.
- <mimeMap fileExtension=".dll" mimeType="application/octet-stream" />
Удалите записи для сжатых .dll
файлов, если сжатие используется:
- <mimeMap fileExtension=".dll.br" mimeType="application/octet-stream" />
- <mimeMap fileExtension=".dll.gz" mimeType="application/octet-stream" />
Дополнительные сведения о пользовательских web.config
файлах смотрите в разделе «Использование пользовательского web.config
».
Нарушение данных перед развертыванием
Обычно при развертывании:
- Заменяются только измененные файлы, что обычно приводит к ускорению развертывания.
- Существующие файлы, не являющиеся частью нового развертывания, остаются на месте для использования в новом развертывании.
В редких случаях устаревшие файлы из предыдущих развертываний могут повредить новое развертывание. Полное удаление существующего развертывания (или локально размещённого приложения перед развертыванием) может помочь устранить проблему с повреждённым развертыванием. Часто для устранения проблемы достаточно удалить существующее развертывание однократно, в том числе для конвейера сборки и развертывания DevOps.
Если вы определили, что очистка до развертывания всегда требуется при использовании конвейера сборки и развертывания DevOps, можно временно добавить шаг в конвейер сборки, чтобы удалить прежнее развертывание для каждого нового развертывания, пока не будет устранена точная причина повреждения.