Hostowanie i wdrażanie platformy ASP.NET Core Blazor WebAssembly

W tym artykule wyjaśniono, jak hostować i wdrażać Blazor WebAssembly przy użyciu ASP.NET Core, Content Delivery Networks (CDN), serwerów plików i usługi GitHub Pages.

Z Blazor WebAssembly modelem hostingu

• Aplikacja Blazor , jej zależności i środowisko uruchomieniowe platformy .NET są pobierane równolegle do przeglądarki.
• Aplikacja jest wykonywana bezpośrednio w wątku interfejsu użytkownika przeglądarki.

Poddomena i hostowanie aplikacji podrzędnych usług IIS

Hosting poddomeny nie wymaga specjalnej konfiguracji aplikacji. Nie musisz konfigurować ścieżki bazowej aplikacji (<base> tagu w wwwroot/index.html), aby hostować aplikację na poddomenie.

Hostowanie aplikacji podrzędnych usług IIS wymaga ustawienia ścieżki podstawowej aplikacji. Aby uzyskać więcej informacji i linki krzyżowe do dalszych wskazówek dotyczących hostowania subaplikacji w usługach IIS, zobacz Host and deploy ASP.NET Core Blazor.

Zmniejsz maksymalny rozmiar sterty dla niektórych przeglądarek urządzeń przenośnych

<EmccMaximumHeapSize>268435456</EmccMaximumHeapSize>

Aby uzyskać więcej informacji na temat właściwości i obiektów docelowych programu Mono/WebAssembly MSBuild, zobacz WasmApp.Common.targets (dotnet/runtime repozytorium GitHub).

<PropertyGroup>
  <WasmEnableWebcil>false</WasmEnableWebcil>
</PropertyGroup>

Dostosowywanie sposobu ładowania zasobów rozruchowych

Dostosuj sposób ładowania zasobów rozruchowych przy użyciu interfejsu loadBootResource API. Aby uzyskać więcej informacji, zobacz uruchamianie ASP.NET CoreBlazor.

Kompresja

Po opublikowaniu Blazor WebAssembly aplikacji dane wyjściowe są statycznie kompresowane podczas publikowania, aby zmniejszyć rozmiar aplikacji i usunąć obciążenie związane z kompresją środowiska uruchomieniowego. Używane są następujące algorytmy kompresji:

• Brotli (najwyższy poziom)
• Gzip

• Aby uzyskać informacje o konfiguracji kompresji usług IISweb.config, zobacz sekcję IIS: kompresja Brotli i Gzip.
• W przypadku hostowania statycznych rozwiązań hostingowych, które nie obsługują statycznie skompresowanych negocjacji zawartości plików, rozważ skonfigurowanie aplikacji do pobierania i dekodowania skompresowanych plików Brotli:

Pozyskaj dekoder Brotli JavaScript z repozytorium GitHub. Plik zminimalizowanego dekodera nosi nazwę decode.min.js i znajduje się w folderze js repozytorium.

Zaktualizuj aplikację, aby korzystała z dekodera.

W pliku wwwroot/index.html ustaw autostart na false w tagu <script>Blazor:

<script src="_framework/blazor.webassembly.js" autostart="false"></script>

Po Blazortagu <script> i przed tagiem zamykającym </body> dodaj następujący blok kodu <script> JavaScript. Następująca funkcja wywołuje fetch za pomocą cache: 'no-cache' w celu zachowania aktualizacji pamięci podręcznej przeglądarki.

<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>

<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>

pl-PL: Aby uzyskać więcej informacji na temat ładowania zasobów rozruchowych, zobacz ASP.NET Core Blazor uruchamianie.

<PropertyGroup>
  <CompressionEnabled>false</CompressionEnabled>
</PropertyGroup>

dotnet publish -p:CompressionEnabled=false

<PropertyGroup>
  <BlazorEnableCompression>false</BlazorEnableCompression>
</PropertyGroup>

dotnet publish -p:BlazorEnableCompression=false

Ponowne zapisywanie adresów URL w celu poprawnego routingu

Routing żądań składników strony w Blazor WebAssembly aplikacji nie jest tak prosty, jak routing żądań w Blazor Server aplikacji. Rozważmy aplikację z dwoma Blazor WebAssembly składnikami:

• Main.razor: Ładuje się w katalogu głównym aplikacji i zawiera link do About komponentu (href="About").
• About.razor: About składnik.

Gdy domyślny dokument aplikacji jest żądany przy użyciu paska adresu przeglądarki (na przykład https://www.contoso.com/):

1. Przeglądarka wysyła żądanie.
2. Zwracana jest strona domyślna, czyli zwykle index.html.
3. index.html uruchamia aplikację.
4. Router składnik jest ładowany, a RazorMain składnik jest renderowany.

Na stronie głównej wybranie linku do składnika About działa po stronie klienta, ponieważ router Blazor uniemożliwia przeglądarce wysyłanie żądania w Internecie do www.contoso.com dla About i sam dostarcza renderowany składnik About. Wszystkie żądania dla wewnętrznych punktów końcowych w Blazor WebAssembly aplikacji działają tak samo: żądania nie wyzwalają żądań opartych na przeglądarce do zasobów hostowanych przez serwer w Internecie. Router obsługuje żądania wewnętrznie.

Jeśli żądanie zostanie wykonane przy użyciu paska adresu przeglądarki dla www.contoso.com/About, żądanie zakończy się niepowodzeniem. Taki zasób nie istnieje na hoście internetowym aplikacji, więc zostanie zwrócona odpowiedź 404 — Nie znaleziono .

Ponieważ przeglądarki wysyłają żądania do hostów internetowych na stronach po stronie klienta, serwery internetowe i usługi hostingowe muszą ponownie zapisać wszystkie żądania dotyczące zasobów, które nie znajdują się fizycznie na serwerze na index.html stronie. Gdy index.html zostanie zwrócony, router aplikacji Blazor przejmuje kontrolę i odpowiada, dostarczając odpowiedni zasób.

Podczas wdrażania na serwerze usług IIS można użyć modułu ponownego zapisywania adresu URL z opublikowanym web.config plikiem aplikacji. Aby uzyskać więcej informacji, zobacz sekcję IIS .

<SelfContained>false</SelfContained>

<RuntimeIdentifier>{RID}</RuntimeIdentifier>

<SelfContained>false</SelfContained>

Wdrożenie autonomiczne

Samodzielne wdrożenie udostępnia aplikację jako zestaw plików statycznych, które są bezpośrednio żądane przez klientów. Każdy statyczny serwer plików może obsługiwać aplikację Blazor .

Zasoby wdrożenia autonomicznego są publikowane w folderze /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot lub bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish\ (w zależności od używanej wersji zestawu ".NET SDK"), gdzie symbol zastępczy {TARGET FRAMEWORK} jest docelową platformą.

Azure App Service

Blazor WebAssemblyaplikacje można wdrażać w usługach aplikacji Azure w systemie Windows, które hostują aplikację na platformie IIS.

Wdrażanie autonomicznej aplikacji Blazor WebAssembly do Azure App Service dla systemu Linux nie jest obecnie obsługiwane. Zalecamy hostowanie autonomicznej Blazor WebAssembly aplikacji przy użyciu usługi Azure Static Web Apps, która obsługuje ten scenariusz.

Azure Static Web Apps

Użyj jednej z następujących metod wdrażania Blazor WebAssembly aplikacji w usłudze Azure Static Web Apps:

• Wdrażanie z poziomu programu Visual Studio
• Wdrażanie z programu Visual Studio Code
• Wdrażanie z repozytorium GitHub

Wdrażanie za pomocą programu Visual Studio

Aby wdrożyć z poziomu programu Visual Studio, utwórz profil publikowania dla usługi Azure Static Web Apps:

1. Zapisz wszystkie niezapisane prace w projekcie, ponieważ podczas procesu może być wymagane ponowne uruchomienie programu Visual Studio.

2. W interfejsie użytkownika publikowania programu Visual Studio wybierz Target>, Azure>, Specific Target>, Azure Static Web Apps, aby utworzyć profil publikowania.

3. Jeśli składnik Narzędzi usługi Azure WebJobs dla programu Visual Studio nie jest zainstalowany, zostanie wyświetlony monit o zainstalowanie składnika ASP.NET i tworzenia aplikacji internetowych. Postępuj zgodnie z monitami, aby zainstalować narzędzia przy użyciu Instalator programu Visual Studio. Program Visual Studio zamyka i otwiera ponownie automatycznie podczas instalowania narzędzi. Po zainstalowaniu narzędzi zacznij od początku od pierwszego kroku, aby utworzyć profil publikowania.

4. W konfiguracji profilu publikowania podaj nazwę subskrypcji. Wybierz istniejące wystąpienie lub wybierz pozycję Utwórz nowe wystąpienie. Podczas tworzenia nowego wystąpienia w interfejsie użytkownika Tworzenia statycznej aplikacji internetowej w portalu Azure, ustaw szczegóły wdrożenia>Źródło na Inne. Przed kontynuowaniem poczekaj na ukończenie wdrożenia w witrynie Azure Portal.

5. W konfiguracji profilu publikowania wybierz instancję Azure Static Web Apps z odpowiedniej grupy zasobów. Wybierz Zakończ, aby utworzyć profil publikowania. Jeśli program Visual Studio wyświetli monit o zainstalowanie interfejsu wiersza polecenia usługi Static Web Apps (SWA), zainstaluj interfejs wiersza polecenia, postępując zgodnie z monitami. Interfejs wiersza polecenia platformy SWA wymaga npm/Node.js (dokumentacji programu Visual Studio).

Po utworzeniu profilu publikowania wdróż aplikację w wystąpieniu usługi Azure Static Web Apps przy użyciu profilu publikowania, wybierając przycisk Publikuj .

Wdrażanie z programu Visual Studio Code

Aby wdrożyć program Visual Studio Code, zobacz Szybki start: tworzenie pierwszej statycznej witryny przy użyciu usługi Azure Static Web Apps.

Wdrażanie z repozytorium GitHub

Aby wdrożyć aplikację z repozytorium GitHub, zobacz Samouczek: tworzenie statycznej aplikacji internetowej za pomocą Blazor usługi Azure Static Web Apps.

IIS

IIS to wydajny serwer statycznych plików dla aplikacji Blazor. Aby skonfigurować usługi IIS do hostowania Blazor, zobacz Tworzenie statycznej witryny internetowej w usługach IIS.

Opublikowane zasoby są tworzone w folderze /bin/Release/{TARGET FRAMEWORK}/publish lub bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish, w zależności od używanej wersji zestawu SDK i gdzie {TARGET FRAMEWORK} symbol zastępczy jest platformą docelową. Hostowanie zawartości publish folderu na serwerze internetowym lub w usłudze hostingu.

web.config

Po opublikowaniu Blazorweb.config projektu zostanie utworzony plik z następującą konfiguracją usług IIS:

• MIME, typy
• Kompresja HTTP jest włączona dla następujących typów MIME:
  • application/octet-stream
  • application/wasm
• Reguły modułu ponownego zapisywania adresów URL są ustanawiane:
  • Obsługa podkatalogu, w którym znajdują się zasoby statyczne aplikacji (wwwroot/{PATH REQUESTED}).
  • Utwórz awaryjny routing aplikacji SPA, aby żądania dotyczące zasobów innych niż pliki zostały przekierowane do domyślnego dokumentu aplikacji w folderze zasobów statycznych (wwwroot/index.html).

Użyj niestandardowego web.config

Aby użyć pliku niestandardowego web.config :

Jeśli generowanie lub przekształcanie zestawu SDK web.config podczas publikacji nie przenosi pliku do zasobów opublikowanych w folderze publish lub modyfikuje konfigurację w pliku własnym web.config, użyj dowolnego podejścia według uznania, aby przejąć pełną kontrolę nad procesem.

• Jeśli zestaw SDK nie generuje pliku, na przykład w autonomicznej aplikacji Blazor WebAssembly w lokalizacji /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot lub bin\Release\{TARGET FRAMEWORK}\browser-wasm\publish, w zależności od używanej wersji zestawu SDK i miejsca, gdzie {TARGET FRAMEWORK} jest strukturą docelową, ustaw właściwość <PublishIISAssets> na wartość true w pliku projektu (.csproj). Zazwyczaj w przypadku autonomicznych aplikacji WebAssembly jest to jedyne ustawienie wymagane do przeniesienia pliku niestandardowego web.config i uniemożliwienie przekształcenia pliku przez zestaw SDK.

  <PropertyGroup>
    <PublishIISAssets>true</PublishIISAssets>
  </PropertyGroup>
  

• Wyłącz przekształcenie SDK web.config w pliku projektu (.csproj):

  <PropertyGroup>
    <IsTransformWebConfigDisabled>true</IsTransformWebConfigDisabled>
  </PropertyGroup>
  

• Dodaj obiekt docelowy niestandardowy do pliku projektu (.csproj), aby przenieść plik niestandardowy web.config . W poniższym przykładzie deweloper umieścił plik niestandardowy web.config w katalogu głównym projektu. Jeśli plik znajduje się w innym miejscu, określ ścieżkę do niego w SourceFiles. W poniższym przykładzie określono folder publish za pomocą $(PublishDir), ale podaj ścieżkę do DestinationFolder dla niestandardowej lokalizacji wyjściowej.

  <Target Name="CopyWebConfig" AfterTargets="Publish">
    <Copy SourceFiles="web.config" DestinationFolder="$(PublishDir)" />
  </Target>
  

Instalowanie modułu ponownego zapisywania adresów URL

Moduł ponownego zapisywania adresów URL jest wymagany do ponownego zapisywania adresów URL. Moduł nie jest instalowany domyślnie i nie jest dostępny do zainstalowania jako funkcja usługi roli serwera sieci Web (IIS). Moduł musi zostać pobrany ze strony IIS. Zainstaluj moduł za pomocą Instalatora platformy internetowej:

1. Przejdź lokalnie do strony pobierania Modułu Przepisywania Adresów URL. W przypadku wersji angielskiej wybierz WebPI, aby pobrać instalator WebPI. W przypadku innych języków wybierz odpowiednią architekturę serwera (x86/x64), aby pobrać instalator.
2. Skopiuj instalator do serwera. Uruchom instalatora. Wybierz przycisk Zainstaluj i zaakceptuj postanowienia licencyjne. Ponowne uruchomienie serwera nie jest wymagane po zakończeniu instalacji.

Konfigurowanie witryny internetowej

Ustaw ścieżkę fizyczną witryny internetowej do folderu aplikacji. Folder zawiera:

• web.config Plik używany przez usługi IIS do konfigurowania witryny internetowej, w tym wymagane reguły przekierowania i typy zawartości plików.
• Folder zasobów statycznych aplikacji.

Hostowanie jako podaplikacja usług IIS

Jeśli autonomiczna aplikacja jest hostowana jako podaplikacja usług IIS, wykonaj jedną z następujących czynności:

• Wyłącz dziedziczoną procedurę obsługi modułu ASP.NET Core.

  Usuń procedurę obsługi w Blazor opublikowanym web.config pliku aplikacji, dodając sekcję <handlers> do <system.webServer> sekcji pliku:

  <handlers>
    <remove name="aspNetCore" />
  </handlers>
  

• Wyłącz dziedziczenie sekcji aplikacji głównej (nadrzędnej) <system.webServer> przy użyciu elementu <location> z ustawioną wartością inheritInChildApplications na false:

  <?xml version="1.0" encoding="utf-8"?>
  <configuration>
    <location path="." inheritInChildApplications="false">
      <system.webServer>
        <handlers>
          <add name="aspNetCore" ... />
        </handlers>
        <aspNetCore ... />
      </system.webServer>
    </location>
  </configuration>
  

  Uwaga

  Wyłączenie dziedziczenia sekcji aplikacji głównej (nadrzędnej <system.webServer> ) jest domyślną konfiguracją opublikowanych aplikacji przy użyciu zestawu .NET SDK.

Usunięcie obsługującego lub wyłączenie dziedziczenia jest wykonywane oprócz konfigurowania podstawowej ścieżki aplikacji. Ustaw ścieżkę bazową aplikacji w pliku aplikacji index.html na alias IIS używany podczas konfigurowania podaplikacji w IIS.

Skonfiguruj ścieżkę podstawową aplikacji, postępując zgodnie ze wskazówkami w artykule Host i wdrażanie ASP.NET Core Blazor .

Kompresja Brotli i Gzip

IIS można skonfigurować za pomocą web.config polecenia, aby obsługiwać skompresowane Blazor zasoby Brotli lub Gzip dla aplikacji autonomicznych Blazor WebAssembly. Przykładowy plik konfiguracji można znaleźć w temacie web.config.

Dodatkowa konfiguracja przykładowego web.config pliku może być wymagana w następujących scenariuszach:

• Specyfikacja aplikacji wymaga jednej z poniższych.
  • Obsługa skompresowanych plików, które nie są skonfigurowane przez przykładowy web.config plik.
  • Serwowanie skompresowanych plików skonfigurowanych przez przykładowy plik web.config w formacie nieskompresowanym.
• Konfiguracja usług IIS serwera (na przykład applicationHost.config) zapewnia domyślne ustawienia usług IIS na poziomie serwera. W zależności od konfiguracji na poziomie serwera, aplikacja może wymagać innej konfiguracji IIS niż to, co zawiera przykładowy plik web.config.

Aby uzyskać więcej informacji na temat plików niestandardowychweb.config, zobacz sekcję Używanie niestandardowego web.config.

Rozwiązywanie problemów

Jeśli zostanie odebrany błąd 500 — wewnętrzny błąd serwera, a Menedżer usług IIS zgłasza błędy podczas próby uzyskania dostępu do konfiguracji witryny internetowej, upewnij się, że moduł ponownego zapisywania adresu URL jest zainstalowany. Gdy moduł nie jest zainstalowany, usługi IIS nie mogą przeanalizować pliku web.config. Uniemożliwia to Menedżerowi IIS załadowanie konfiguracji witryny internetowej oraz uniemożliwia witrynie obsługę plików statycznych Blazor.

Aby uzyskać więcej informacji na temat rozwiązywania problemów z wdrożeniami usług IIS, zobacz Rozwiązywanie problemów z programem ASP.NET Core w usłudze aplikacja systemu Azure i usługach IIS.

Azure Storage

Hostowanie plików statycznych usługi Azure Storage umożliwia hostowanie aplikacji bezserwerowych Blazor . Obsługiwane są niestandardowe nazwy domen, usługa Azure Content Delivery Network (CDN) i protokół HTTPS.

Gdy usługa blob jest włączona na potrzeby hostowania statycznej witryny internetowej w koncie magazynowym:

• Ustaw nazwę dokumentu indeksu na index.html.
• Ustaw ścieżkę dokumentu Błędów na index.html. Razor składniki i inne punkty końcowe inne niż pliki nie znajdują się w ścieżkach fizycznych w zawartości statycznej przechowywanej przez usługę blob. Po odebraniu żądania dla jednego z tych zasobów, które powinien obsłużyć router Blazor, błąd 404 - Nie znaleziono wygenerowany przez usługę blob kieruje żądanie do ścieżki dokumentu błędu. Obiekt index.html blob jest zwracany, a ścieżka jest ładowana i przetwarzana przez router Blazor.

Jeśli pliki nie są ładowane w czasie wykonywania z powodu nieodpowiednich typów MIME w nagłówkach plików Content-Type , wykonaj jedną z następujących akcji:

• Skonfiguruj narzędzia, aby ustawić poprawne typy MIME (Content-Type nagłówki) podczas wdrażania plików.

• Zmień typy MIME (Content-Type nagłówki) dla plików po wdrożeniu aplikacji.

  W Eksploratorze magazynu (portal Azure), dla każdego pliku:

  1. Kliknij plik prawym przyciskiem myszy i wybierz pozycję Właściwości.
  2. Ustaw właściwość ContentType i wybierz przycisk Zapisz .

Aby uzyskać więcej informacji, zobacz Hostowanie statycznej witryny internetowej w usłudze Azure Storage.

Nginx

Poniższy nginx.conf plik jest uproszczony, aby pokazać, jak skonfigurować serwer Nginx do wysyłania index.html pliku zawsze, gdy nie może znaleźć odpowiedniego pliku na dysku.

events { }
http {
    server {
        listen 80;

        location / {
            root      /usr/share/nginx/html;
            try_files $uri $uri/ /index.html =404;
        }
    }
}

Podczas ustawiania limitu szybkości wybuchu NGINX z limit_req, aplikacje mogą wymagać dużej wartości parametru burst, aby obsłużyć stosunkowo dużą liczbę żądań generowanych przez aplikację. Początkowo ustaw wartość na co najmniej 60:

http {
    server {
        ...

        location / {
            ...

            limit_req zone=one burst=60 nodelay;
        }
    }
}

Zwiększ wartość, jeśli narzędzia deweloperskie przeglądarki lub narzędzie ruchu sieciowego wskazuje, że żądania otrzymują kod stanu 503 — Usługa niedostępna .

Aby uzyskać więcej informacji na temat produkcyjnej konfiguracji serwera internetowego Nginx, zobacz Creating NGINX Plus and NGINX Configuration Files (Tworzenie plików konfiguracji NGINX Plus i NGINX).

Apache

Aby wdrożyć aplikację Blazor WebAssembly na platformie Apache:

1. Umieść plik konfiguracji apache w /etc/httpd/conf.d/ katalogu.

2. Umieść opublikowane zasoby aplikacji (/bin/Release/{TARGET FRAMEWORK}/publish/wwwroot, gdzie symbol zastępczy {TARGET FRAMEWORK} odnosi się do struktury docelowej) w katalogu /var/www/blazorapp (lokalizacji określonej dla DocumentRoot w pliku konfiguracji).

3. Uruchom ponownie usługę Apache.

Aby uzyskać więcej informacji, zobacz mod_mime oraz mod_deflate.

Usługa GitHub Pages

Poniższe wskazówki dotyczące wdrażania aplikacji Blazor WebAssembly na GitHub Pages zaprezentowane są z wykorzystaniem narzędzia działającego na żywo wdrożonego na GitHub Pages. Narzędzie jest używane przez autorów dokumentacji platformy ASP.NET Core do tworzenia linków XREF do dokumentacji API w plikach Markdown artykułów.

• przykładowa aplikacja BlazorWebAssemblyXrefGenerator (blazor-samples/BlazorWebAssemblyXrefGenerator)
• Strona internetowa Live Xref Generator

Ustawienia usługi GitHub Pages

• akcje >ogólne
  • uprawnienia akcji
    • Zezwalaj na akcje przedsiębiorstwa, wybierz akcje nieprzedsiębiorstwowe oraz przepływy pracy wielokrotnego użytku> Włączone (wybrane)
    • Zezwalaj na akcje utworzone przez usługę GitHub> Włączone (wybrane)
    • Zezwalaj na akcje i przepływy pracy wielokrotnego użytku>stevesandersonms/ghaction-rewrite-base-href@v1,
  • uprawnienia przepływu pracy >uprawnienia do odczytu zawartości repozytorium i pakietów
• Strony>Kompilacja i wdrażanie
  • Source>GitHub Actions
  • Wybrany przepływ pracy: Statyczne HTML i oprzyj swój skrypt Akcji wdrażania statycznego na pliku Xref Generator static.yml dla narzędzia Xref Generator. Konfiguracja w pliku jest opisana w następnej sekcji.
  • Niestandardowa domena: ustaw, jeśli zamierzasz użyć niestandardowej domeny, która nie jest objęta tymi wskazówkami. Aby uzyskać więcej informacji, zobacz Konfigurowanie domeny niestandardowej dla witryny usługi GitHub Pages.
  • Wymuś HTTPS> Włączone (wybrane)

Konfiguracja skryptu wdrażania statycznego

Plik Generatora Xref static.yml

Skonfiguruj następujące wpisy w skrypcie dla twojego wdrożenia.

• Katalog publikowania (PUBLISH_DIR): Użyj ścieżki do folderu repozytorium, w którym odbywa się publikowanie aplikacji Blazor WebAssembly. Aplikacja jest kompilowana dla określonej wersji platformy .NET, a segment ścieżki tej wersji musi być zgodny. Przykład: BlazorWebAssemblyXrefGenerator/bin/Release/net9.0/publish/wwwroot to ścieżka aplikacji, która przyjmuje net9.0Target Framework Moniker (TFM) dla zestawu SDK platformy .NET 9.0
• Ścieżka wypychania (on:push:paths): Ustaw ścieżkę wypychania, aby dopasować ją do folderu repozytorium aplikacji przy użyciu symbolu wieloznacznego **. Przykład: BlazorWebAssemblyXrefGenerator/**
• Wersja zestawu .NET SDK ( za pomocą Akcja ): Obecnie nie ma możliwości ustawienia wersji na "latest" (zobacz Możliwość ustawienia "latest" jako wersji dotnet ( #497), aby oddać głos na wniosek dotyczący funkcji). Ustaw wersję zestawu SDK co najmniej tak wysoką, jak wersja platformy aplikacji.
• Ścieżka publikowania ( poleceniedotnet publish): ustaw ścieżkę folderu publikowania do folderu repozytorium aplikacji. Przykład: dotnet publish BlazorWebAssemblyXrefGenerator -c Release
• Base HREF (base_href dla akcji SteveSandersonMS/ghaction-rewrite-base-href): ustaw podstawowy href dla aplikacji na nazwę repozytorium. Przykład: właściciel repozytorium przykładu Blazor jest dotnet. Nazwa repozytorium przykładu Blazor to blazor-samples. Gdy narzędzie Xref Generator jest wdrażane w usłudze GitHub Pages, jego adres internetowy jest oparty na nazwie repozytorium (https://dotnet.github.io/blazor-samples/). Podstawowy adres href aplikacji to /blazor-samples/, który jest ustawiany na base_href, aby akcja ghaction-rewrite-base-href mogła zapisać się w tagu wwwroot/index.html<base> podczas wdrażania aplikacji. Aby uzyskać więcej informacji, zobacz Host and deploy ASP.NET Core Blazor.

Serwer z systemem Ubuntu hostowanym w usłudze GitHub (najnowsza wersja) ma wstępnie zainstalowaną wersję zestawu .NET SDK. Możesz usunąć krok actions/setup-dotnet Akcji ze skryptu static.yml, jeśli wstępnie zainstalowany zestaw SDK .NET jest wystarczający do skompilowania aplikacji. Aby określić zestaw .NET SDK zainstalowany dla ubuntu-latest:

1. Przejdź do sekcji Available Images (Dostępne obrazy) repozytorium actions/runner-images GitHub.
2. Znajdź obraz ubuntu-latest, który jest pierwszym wierszem tabeli.
3. Wybierz link w kolumnie Included Software.
4. Przewiń w dół do sekcji .NET Tools, aby wyświetlić pakiet .NET Core SDK zainstalowany wraz z obrazem.

Uwagi dotyczące wdrażania

Domyślna akcja GitHub, która wdraża strony, pomija wdrażanie folderów zaczynających się od podkreślenia, na przykład folderu _framework. Aby wdrożyć foldery rozpoczynające się od podkreślenia, dodaj pusty plik .nojekyll do katalogu głównego repozytorium aplikacji. Przykład: pliku generatora Xref .nojekyll

Wykonaj ten krok przed pierwszym wdrożeniem aplikacji: Git traktuje pliki JavaScript (JS), takie jak blazor.webassembly.js, jako tekst i konwertuje zakończenia wierszy z CRLF (powrót karetki-nowa linia) na LF (nowa linia) w procesie wdrażania. Te zmiany w plikach JS generują inne skróty plików niż te, które Blazor wysyła do klienta w pliku blazor.boot.json. Niezgodności powodują błędy sprawdzania integralności na kliencie. Jednym z podejść do rozwiązania tego problemu jest dodanie pliku .gitattributes z linią *.js binary przed dodaniem zasobów aplikacji do gałęzi Git. Wiersz *.js binary konfiguruje Git-a tak, aby traktować JS pliki jako pliki binarne, co pozwala uniknąć przetwarzania plików w pipeline wdrożenia. Skróty nieprzetworzonych plików są zgodne z wpisami w pliku blazor.boot.json, a testy integralności po stronie klienta przechodzą pomyślnie. Aby uzyskać więcej informacji, zobacz ASP.NET Core Blazor WebAssembly środowisko uruchomieniowe platformy .NET i buforowanie pakietów aplikacji. Przykład: plik generatora Xref .gitattributes

Aby obsługiwać ponowne zapisywanie adresów URL na podstawie aplikacji jednostronicowych dla GitHub Pages (rafrex/spa-github-pages repozytorium GitHub):

• Dodaj plik wwwroot/404.html ze skryptem obsługującym przekierowywanie żądania do strony index.html. Przykład: plik 404.html Xref Generator
• W wwwroot/index.htmldodaj skrypt do zawartości <head>. Przykład: plik index.html Xref Generator

Usługa GitHub Pages nie obsługuje natywnie zasobów skompresowanych metodą Brotli. Aby użyć narzędzia Brotli:

• Dodaj skrypt wwwroot/decode.js do folderu wwwroot aplikacji. Przykład: pliku generatora Xrefdecode.js

• Dodaj tag <script>, aby załadować skrypt decode.js w pliku wwwroot/index.html bezpośrednio powyżej tagu <script>, który ładuje skrypt Blazor. Przykład: plik Xref Generator index.html

  • Ustaw autostart="false" dla skryptu Blazor WebAssembly.
  • Dodaj skrypt loadBootResource po tagu <script>, który ładuje skrypt Blazor WebAssembly. Przykład: Plik index.html generatora Xref

• Dodaj pliki robots.txt i sitemap.txt, aby ulepszyć seo. Przykłady: generator Xref plik robots.txt, generator Xref plik sitemap.txt

Samodzielne użycie z Dockerem

Samodzielna aplikacja Blazor WebAssembly jest publikowana jako zestaw plików statycznych, aby mogły być hostowane przez statyczny serwer plików.

Aby hostować aplikację na platformie Docker:

• Wybierz kontener platformy Docker z obsługą serwera internetowego, na przykład Nginx lub Apache.
• Skopiuj zasoby folderu publish do folderu docelowego zdefiniowanego na serwerze internetowym do obsługi plików statycznych.
• Zastosuj dodatkową konfigurację zgodnie z potrzebami, aby obsłużyć aplikację Blazor WebAssembly .

Aby uzyskać wskazówki dotyczące konfiguracji, zobacz następujące zasoby:

• Sekcja serwera Nginx lub sekcja platformy Apache w tym artykule
• Dokumentacja platformy Docker

Wartości konfiguracji hosta

Blazor WebAssembly aplikacje mogą akceptować następujące wartości konfiguracji hosta jako argumenty wiersza polecenia w czasie wykonywania w środowisku deweloperskich.

Podstawa zawartości

Argument --contentroot ustawia bezwzględną ścieżkę do katalogu zawierającego pliki zawartości aplikacji (katalog główny zawartości). W poniższych przykładach /content-root-path jest ścieżka główna zawartości aplikacji.

• Przekaż argument podczas lokalnego uruchamiania aplikacji w wierszu polecenia. W katalogu aplikacji wykonaj następujące polecenie:

  dotnet watch --contentroot=/content-root-path
  

• Dodaj wpis do pliku aplikacji launchSettings.json w profilu IIS Express. To ustawienie jest używane, gdy aplikacja jest uruchamiana z debugerem Visual Studio oraz z wiersza polecenia przy wykorzystaniu dotnet watch (lub dotnet run).

  "commandLineArgs": "--contentroot=/content-root-path"
  

• W programie Visual Studio określ argument w obszarze Właściwości>Debugowanie>Argumenty aplikacji. Ustawienie argumentu na stronie właściwości programu Visual Studio powoduje dodanie argumentu launchSettings.json do pliku.

  --contentroot=/content-root-path
  

Podstawa ścieżki

--pathbase Argument ustawia podstawową ścieżkę aplikacji dla aplikacji uruchamianej lokalnie z użyciem względnej ścieżki URL innej niż główna (znacznik <base>href jest ustawiony na inną ścieżkę niż / w środowisku testowym i produkcyjnym). W poniższych przykładach /relative-URL-path jest podstawą ścieżki aplikacji. Aby uzyskać więcej informacji, zobacz Ścieżka podstawowa aplikacji.

• Przekaż argument podczas uruchamiania aplikacji lokalnie w wierszu polecenia. W katalogu aplikacji wykonaj następujące polecenie:

  dotnet watch --pathbase=/relative-URL-path
  

• Dodaj wpis do pliku launchSettings.json aplikacji w profilu IIS Express. To ustawienie jest używane podczas uruchamiania aplikacji z użyciem debugera Visual Studio oraz z wiersza polecenia za pomocą dotnet watch (lub dotnet run).

  "commandLineArgs": "--pathbase=/relative-URL-path"
  

• W programie Visual Studio określ argument w obszarze Właściwości>Debug>Argumenty aplikacji. Ustawienie argumentu na stronie właściwości programu Visual Studio powoduje dodanie argumentu launchSettings.json do pliku.

  --pathbase=/relative-URL-path
  

Adresy URL

Argument --urls ustawia adresy IP lub adresy hostów z portami i protokołami do nasłuchiwania żądań.

• Podaj argument, uruchamiając aplikację lokalnie z wiersza polecenia. W katalogu aplikacji wykonaj następujące polecenie:

  dotnet watch --urls=http://127.0.0.1:0
  

• Dodaj wpis do pliku aplikacji launchSettings.json w profilu IIS Express. To ustawienie jest używane podczas uruchamiania aplikacji z debugerem programu Visual Studio oraz z wiersza polecenia za pomocą dotnet watch (lub dotnet run).

  "commandLineArgs": "--urls=http://127.0.0.1:0"
  

• W programie Visual Studio określ argument w obszarze Właściwości>Debug>Argumenty aplikacji. Ustawienie argumentu na stronie właściwości programu Visual Studio powoduje dodanie argumentu launchSettings.json do pliku.

  --urls=http://127.0.0.1:0
  

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

((Get-Content {PATH}\service-worker-assets.js -Raw) -replace '.dll"','.bin"') | Set-Content {PATH}\service-worker-assets.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

sed -i 's/\.dll"/.bin"/g' {PATH}/service-worker-assets.js

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

((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\_framework\wwwroot\service-worker-assets.js
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js.gz
Remove-Item $filepath\bin\Release\$tfm\browser-wasm\publish\wwwroot\_framework\wwwroot\service-worker-assets.js.br

<Target Name="ChangeDLLFileExtensions" AfterTargets="AfterPublish" Condition="'$(Configuration)'=='Release'">
  <Exec Command="powershell.exe -command &quot;&amp; { .\ChangeDLLExtensions.ps1 '$(SolutionDir)' '$(TargetFramework)'}&quot;" />
</Target>

<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" />

- <mimeMap fileExtension=".dll" mimeType="application/octet-stream" />

- <mimeMap fileExtension=".dll.br" mimeType="application/octet-stream" />
- <mimeMap fileExtension=".dll.gz" mimeType="application/octet-stream" />

Uszkodzenie wdrożenia przed jego uruchomieniem

Zazwyczaj w przypadku wdrożenia:

• Tylko zmienione pliki są zastępowane, co zwykle skutkuje szybszym wdrożeniem.
• Istniejące pliki, które nie są częścią nowego wdrożenia, są pozostawione do użycia przez nowe wdrożenie.

W rzadkich przypadkach utrzymujące się pliki z wcześniejszego wdrożenia mogą uszkodzić nowe wdrożenie. Całkowite usunięcie istniejącego wdrożenia (lub lokalnie opublikowanej aplikacji przed wdrożeniem) może rozwiązać problem z uszkodzonym wdrożeniem. Często usunięcie istniejącego wdrożenia wystarczy , aby rozwiązać ten problem, w tym w przypadku potoku kompilacji i wdrażania metodyki DevOps.

Jeśli ustalisz, że wyczyszczenie wcześniejszego wdrożenia jest zawsze wymagane, gdy potok kompilacji i wdrażania metodyki DevOps jest używany, możesz tymczasowo dodać krok do potoku kompilacji, aby usunąć poprzednie wdrożenie dla każdego nowego wdrożenia, dopóki nie rozwiążesz dokładnej przyczyny uszkodzenia.

Rozwiązać awarie sprawdzania integralności

Gdy Blazor WebAssembly pobiera pliki uruchamiania aplikacji, każe przeglądarce przeprowadzać kontrole integralności odpowiedzi. Blazor wysyła wartości skrótu SHA-256 dla bibliotek DLL (.dll), WebAssembly (.wasm) i innych plików w blazor.boot.json pliku, które nie są buforowane po stronie klientów. Skróty plików buforowanych są porównywane z skrótami w blazor.boot.json pliku. W przypadku plików buforowanych z pasującym skrótem Blazor używa buforowanych plików. W przeciwnym razie pliki są żądane z serwera. Po pobraniu pliku jego skrót jest ponownie sprawdzany pod kątem weryfikacji integralności. Błąd jest generowany przez przeglądarkę, jeśli sprawdzanie integralności pobranego pliku nie powiedzie się.

Algorytm Blazor do zarządzania integralnością plików:

• Zapewnia, że aplikacja nie ryzykuje ładowania niespójnego zestawu plików, na przykład jeśli nowe wdrożenie zostanie zastosowane do serwera internetowego, gdy użytkownik jest w trakcie pobierania plików aplikacji. Niespójne pliki mogą spowodować awarię aplikacji.
• Gwarantuje, że przeglądarka użytkownika nigdy nie buforuje niespójnych lub nieprawidłowych odpowiedzi, co może uniemożliwić uruchamianie aplikacji nawet wtedy, gdy użytkownik ręcznie odświeży stronę.
• Zabezpiecza buforowanie odpowiedzi i nie sprawdza zmian po stronie serwera, dopóki oczekiwane skróty SHA-256 się nie zmienią, więc kolejne obciążenia stron obejmują mniej żądań i zakończą się szybciej.

Jeśli serwer internetowy zwraca odpowiedzi, które nie są zgodne z oczekiwanymi skrótami SHA-256, w konsoli dewelopera przeglądarki zostanie wyświetlony błąd podobny do poniższego przykładu:

Nie można odnaleźć prawidłowego skrótu w atrybucie "integrity" dla zasobu "https://myapp.example.com/_framework/MyBlazorApp.dll" z obliczoną integralnością SHA-256 "IIa70iwvmEg5WiDV17OpQ5eCztNYqL186J56852RpJY=". Zasób został zablokowany.

W większości przypadków ostrzeżenie nie wskazuje problemu z sprawdzaniem integralności. Zamiast tego ostrzeżenie zwykle oznacza, że istnieje inny problem.

Aby uzyskać informacje o Blazor WebAssemblyźródle referencji rozruchu, zobacz plik Boot.WebAssembly.ts w repozytorium dotnet/aspnetcore GitHub.

Diagnozowanie problemów z integralnością

Podczas kompilowania aplikacji wygenerowany blazor.boot.json manifest opisuje skróty SHA-256 zasobów rozruchowych w momencie wygenerowania danych wyjściowych kompilacji. Sprawdzanie integralności przechodzi tak długo, jak skrót SHA-256 w blazor.boot.json jest zgodny z plikami dostarczonymi do przeglądarki.

Typowe przyczyny niepowodzenia:

• Odpowiedź serwera internetowego jest błędem (na przykład 404 — Nie znaleziono lub 500 — wewnętrzny błąd serwera) zamiast pliku, którego zażądała przeglądarka. Jest to zgłaszane przez przeglądarkę jako błąd sprawdzania integralności, a nie jako błąd odpowiedzi.
• Coś zmieniło zawartość plików między kompilacją i dostarczaniem plików do przeglądarki. Może się tak zdarzyć:
  • Jeśli ty lub narzędzia kompilacji ręcznie zmodyfikuj dane wyjściowe kompilacji, może to prowadzić do problemów.
  • Jeśli jakiś aspekt procesu wdrażania zmodyfikował pliki. Jeśli na przykład używasz mechanizmu wdrażania opartego na usłudze Git, pamiętaj, że usługa Git w sposób przezroczysty konwertuje zakończenia linii w stylu systemu Windows na zakończenia linii w stylu unix, jeśli zatwierdzisz pliki w systemie Windows i wyewidencjonujesz je w systemie Linux. Zmiana końców wiersza pliku zmienia skróty SHA-256. Aby uniknąć tego problemu, rozważ użycie metody .gitattributes w celu traktowania artefaktów kompilacji jako binary plików.
  • Serwer internetowy modyfikuje zawartość pliku w ramach ich obsługi. Na przykład niektóre sieci dystrybucji zawartości (CDN) automatycznie próbują minimalizować kod HTML, modyfikując go w ten sposób. Może być konieczne wyłączenie takich funkcji.
• Nie można poprawnie załadować pliku blazor.boot.json lub jest on nieprawidłowo buforowany po stronie klienta. Typowe przyczyny obejmują jedną z następujących przyczyn:
  • Nieprawidłowo skonfigurowany lub wadliwie działający kod niestandardowy dewelopera.
  • Co najmniej jedna nieprawidłowo skonfigurowana warstwa buforowania pośredniego.

Aby zdiagnozować, które z nich mają zastosowanie w Twoim przypadku:

1. Zwróć uwagę, który plik wyzwala błąd, odczytując komunikat o błędzie.
2. Otwórz narzędzia deweloperskie przeglądarki i spójrz na kartę Sieć . W razie potrzeby załaduj ponownie stronę, aby wyświetlić listę żądań i odpowiedzi. Znajdź plik, który wyzwala błąd na tej liście.
3. Sprawdź kod stanu HTTP w odpowiedzi. Jeśli serwer zwraca coś innego niż 200 — OK (lub inny kod stanu 2xx), masz problem po stronie serwera do zdiagnozowania. Na przykład kod stanu 403 oznacza, że występuje problem z autoryzacją, natomiast kod stanu 500 oznacza, że serwer kończy się niepowodzeniem w nieokreślony sposób. Zapoznaj się z dziennikami po stronie serwera, aby zdiagnozować i naprawić aplikację.
4. Jeśli kod stanu to 200 — OK dla zasobu, sprawdź zawartość odpowiedzi w narzędziach deweloperskich przeglądarki i sprawdź, czy zawartość jest zgodna z oczekiwanymi danymi. Na przykład typowym problemem jest błędne skonfigurowanie routingu, aby żądania zwracały index.html dane nawet w przypadku innych plików. Upewnij się, że odpowiedzi na .wasm żądania to pliki binarne WebAssembly i że odpowiedzi na .dll żądania to pliki binarne zestawów .NET. Jeśli nie, masz problem z routingiem po stronie serwera do zdiagnozowania.
5. Sprawdź poprawność opublikowanych i wdrożonych danych wyjściowych aplikacji za pomocą skryptu Rozwiązywanie problemów z integralnością programu PowerShell.

Jeśli potwierdzisz, że serwer zwraca wiarygodne poprawne dane, musi istnieć coś innego modyfikujące zawartość między kompilacją i dostarczaniem pliku. Aby zbadać to:

• Sprawdź łańcuch narzędzi kompilacji i mechanizm wdrażania, jeśli modyfikują pliki po skompilowaniu plików. Przykładem tego jest sytuacja, gdy Git przekształca zakończenia linii w pliku, jak opisano wcześniej.
• Sprawdź konfigurację serwera internetowego lub sieci CDN, aby sprawdzić, czy są ustawione w taki sposób, by dynamicznie modyfikować odpowiedzi (na przykład minimalizując HTML). Serwer internetowy może zaimplementować kompresję HTTP (na przykład zwracaną content-encoding: br lub content-encoding: gzip), ponieważ nie ma to wpływu na wynik po dekompresji. Jednak nie w porządku, aby serwer internetowy modyfikował nieskompresowane dane.

Rozwiązywanie problemów ze skryptem PowerShell dotyczących integralności

Użyj skryptu integrity.ps1 programu PowerShell, aby zweryfikować opublikowaną i wdrożona Blazor aplikację. Skrypt jest udostępniany dla programu PowerShell Core 7 lub nowszego jako punkt wyjścia, gdy aplikacja ma problemy z integralnością, których Blazor platforma nie może zidentyfikować. Dostosowanie skryptu może być wymagane dla aplikacji, w tym w przypadku uruchamiania w wersji programu PowerShell nowszej niż wersja 7.2.0.

Skrypt sprawdza pliki w folderze publish oraz te pobrane z wdrożonej aplikacji, aby wykrywać problemy w różnych manifestach zawierających skróty integralności. Te testy powinny wykrywać najczęstsze problemy:

• Zmodyfikowałeś plik w opublikowanym wyniku, nie zdając sobie z tego sprawy.
• Aplikacja nie została poprawnie wdrożona w obiekcie docelowym wdrożenia lub coś się zmieniło w środowisku docelowym wdrożenia.
• Istnieją różnice między wdrożoną aplikacją a wynikiem publikowania aplikacji.

Wywołaj skrypt za pomocą następującego polecenia w powłoce poleceń programu PowerShell:

.\integrity.ps1 {BASE URL} {PUBLISH OUTPUT FOLDER}

W poniższym przykładzie skrypt jest wykonywany w aplikacji uruchomionej lokalnie pod adresem https://localhost:5001/:

.\integrity.ps1 https://localhost:5001/ C:\TestApps\BlazorSample\bin\Release\net6.0\publish\

Symbole zastępcze:

• {BASE URL}: adres URL wdrożonej aplikacji. Wymagany jest ukośnik końcowy (/).
• {PUBLISH OUTPUT FOLDER}: ścieżka do folderu lub lokalizacji aplikacji publish , w której aplikacja jest publikowana na potrzeby wdrożenia.

C:\Users\{USER}\Documents\GitHub\AspNetCore.Docs\aspnetcore\blazor\host-and-deploy\webassembly\_samples\integrity.ps1

CertUtil -hashfile {PATH AND FILE NAME} {SHA256|MD5}

Wyłącz sprawdzanie integralności dla aplikacji innych niż PWA

W większości przypadków nie wyłączaj sprawdzania integralności. Wyłączenie sprawdzania integralności nie rozwiązuje podstawowego problemu, który spowodował nieoczekiwane odpowiedzi i powoduje utratę korzyści wymienionych wcześniej.

Mogą wystąpić przypadki, w których nie można polegać na zwracaniu spójnych odpowiedzi na serwerze sieci Web i nie masz wyboru, ale tymczasowo wyłączyć kontrole integralności do momentu rozwiązania problemu podstawowego.

Aby wyłączyć kontrole integralności, dodaj następujące elementy do grupy właściwości w Blazor WebAssembly pliku projektu aplikacji (.csproj):

<BlazorCacheBootResources>false</BlazorCacheBootResources>

BlazorCacheBootResources również wyłącza domyślne zachowanie Blazor polegające na buforowaniu .dll, .wasm i innych plików na podstawie skrótów SHA-256, ponieważ właściwość wskazuje, że na poprawność skrótów SHA-256 nie można polegać. Nawet w przypadku tego ustawienia normalna pamięć podręczna HTTP przeglądarki może nadal przechowywać w pamięci podręcznej te pliki, ale to, czy tak się stanie, zależy od konfiguracji serwera internetowego i cache-control nagłówków, które wysyła.

Nie można podać wyczerpującej listy scenariuszy, w których jest wymagane wyłączenie sprawdzania integralności. Serwery mogą odpowiadać na żądanie w dowolny sposób poza zakresem Blazor struktury. Platforma udostępnia BlazorCacheBootResources ustawienie umożliwiające uruchamianie aplikacji kosztem utraty gwarancji integralności, którą aplikacja może zapewnić. Ponownie nie zalecamy wyłączania sprawdzania integralności, zwłaszcza w przypadku wdrożeń produkcyjnych. Deweloperzy powinni dążyć do rozwiązania podstawowego problemu integralności, który powoduje niepowodzenie sprawdzania integralności.

Oto kilka ogólnych przypadków, które mogą powodować problemy z integralnością:

• Uruchamianie przy użyciu protokołu HTTP, w którym nie można sprawdzić integralności.
• Jeśli proces wdrażania modyfikuje pliki po opublikowaniu w jakikolwiek sposób.
• Jeśli host modyfikuje pliki w jakikolwiek sposób.

Wyłączenie sprawdzania integralności dla aplikacji internetowych (PWA)

BlazorSzablon progresywnej aplikacji internetowej (PWA) zawiera sugerowany service-worker.published.js plik, który jest odpowiedzialny za pobieranie i przechowywanie plików aplikacji do użytku w trybie offline. Jest to oddzielny proces od normalnego mechanizmu uruchamiania aplikacji i ma własną oddzielną logikę sprawdzania integralności.

service-worker.published.js Wewnątrz pliku znajduje się następujący wiersz:

.map(asset => new Request(asset.url, { integrity: asset.hash }));

Aby wyłączyć sprawdzanie integralności, usuń integrity parametr, zmieniając wiersz na następujący:

.map(asset => new Request(asset.url));

Ponownie wyłączenie sprawdzania integralności oznacza utratę gwarancji bezpieczeństwa oferowanych przez kontrolę integralności. Istnieje na przykład ryzyko, że jeśli przeglądarka użytkownika buforuje aplikację w dokładnym momencie wdrożenia nowej wersji, może buforować niektóre pliki ze starego wdrożenia i niektóre z nowego wdrożenia. W takim przypadku aplikacja zostanie zablokowana w stanie uszkodzonym do momentu wdrożenia kolejnej aktualizacji.