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

W tym artykule wyjaśniono, jak hostować i wdrażać aplikacje Blazor WebAssembly.

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.

Ten artykuł dotyczy scenariusza wdrażania, w którym Blazor aplikacja jest umieszczana na statycznym serwerze internetowym lub usłudze hostingu, platforma .NET nie jest używana do obsługi Blazor aplikacji. Ta strategia jest omówiona w sekcji Wdrażanie autonomiczne oraz w innych artykułach w tym węźle dla usług IIS, Azure, Apache, Nginx i GitHub Pages.

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

Podczas tworzenia aplikacji Blazor działającej po stronie klienta (czy to jako projekt .Client aplikacji lub jako autonomiczna aplikacja Blazor Web App) i ukierunkowanej na przeglądarki urządzeń mobilnych, szczególnie Safari na iOS, może być konieczne zmniejszenie maksymalnej ilości pamięci dla aplikacji za pomocą właściwości Blazor WebAssembly MSBuild. Wartość domyślna to 2 147 483 648 bajtów, co może być zbyt duże i powoduje awarię aplikacji, jeśli aplikacja próbuje przydzielić więcej pamięci, a przeglądarka nie udzieliła jej. Poniższy przykład ustawia wartość na 268 435 456 bajtów w Program pliku:

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

Format pakietów webcil dla zestawów platformy .NET

Webcil to przyjazny dla sieci format pakowania asemblii .NET, zaprojektowany do umożliwienia użycia Blazor WebAssembly w restrykcyjnych środowiskach sieciowych. Pliki webcil używają standardowego opakowania WebAssembly, w którym zestawy są wdrażane jako pliki WebAssembly, używające standardowego rozszerzenia pliku .wasm.

Webcil jest domyślnym formatem pakowania przy publikowaniu aplikacji Blazor WebAssembly. Aby wyłączyć używanie elementu Webcil, ustaw następującą właściwość MSBuild w pliku projektu aplikacji:

<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

Blazor korzysta z hosta w celu obsługi odpowiednich skompresowanych plików. W przypadku hostowania aplikacji autonomicznej Blazor WebAssembly może być wymagana dodatkowa praca w celu zapewnienia obsługi statycznie skompresowanych plików:

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

Uwaga

Jeśli minimalna wersja skryptu decode.js (decode.min.js) zakończy się niepowodzeniem, spróbuj zamiast tego użyć niezminyfikowanej wersji (decode.js).

Zaktualizuj aplikację, aby korzystała z dekodera.

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

<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 utrzymania aktualności pamięci podręcznej przeglądarki.

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>

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

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

Aby wyłączyć kompresję CompressionEnabled , dodaj właściwość MSBuild do pliku projektu aplikacji i ustaw wartość na false:

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

Można przekazać właściwość CompressionEnabled do polecenia dotnet publish przy użyciu następującej składni w powłoce poleceń.

dotnet publish -p:CompressionEnabled=false

Ponowne zapisywanie adresów URL w celu poprawnego routingu

Trasowanie żądań dotyczących składników strony w aplikacji Blazor WebAssembly nie jest tak proste jak trasowanie żądań w aplikacji Blazor Server. 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 Hostowanie i wdrażanie ASP.NET Core z IISBlazor WebAssembly.

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, gdzie symbol zastępczy {TARGET FRAMEWORK} jest platformą docelową.

Azure App Service

Blazor WebAssembly aplikacje można wdrażać w usłudze Azure App Services w systemie Windows, która hostuje aplikację w usługach 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.

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:

• Artykuły dotyczące serwera Nginx lub Apache
• 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 przy lokalnym uruchamianiu 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 ASP.NET CoreBlazor.

Ważne

W przeciwieństwie do ścieżki podanej do href tagu <base>, nie dołączaj ukośnika końcowego (/) w przypadku przekazywaniu wartości argumentu --pathbase. Jeśli ścieżka podstawowa aplikacji jest podana w tagu <base> jako <base href="/CoolApp/"> (zawiera ukośnik końcowy), przekaż wartość argumentu wiersza polecenia jako --pathbase=/CoolApp (bez końcowego ukośnika).

• Przekaż argument przy lokalnym uruchamianiu aplikacji w wierszu polecenia. W katalogu aplikacji wykonaj następujące polecenie:

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

• Dodaj wpis do pliku aplikacji launchSettings.json 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>Debugowanie>Argumenty aplikacji. Ustawienie argumentu na stronie właściwości programu Visual Studio powoduje dodanie argumentu launchSettings.json do pliku.

  --pathbase=/relative-URL-path
  

Aby uzyskać więcej informacji, zobacz ścieżka podstawowa aplikacji ASP.NET CoreBlazor.

Adresy URL

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

• Przekaż argument przy lokalnym uruchamianiu aplikacji w wierszu 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 użyciem debugera 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>Debugowanie>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
  

Konfigurowanie elementu przycinającego

Blazor wykonuje przycinanie Języka Pośredniego (IL) dla każdej kompilacji Release, aby usunąć niepotrzebny IL z zestawów wyjściowych. Aby uzyskać więcej informacji, zobacz Configure the Trimmer for ASP.NET Core (Konfigurowanie programu Trimmer dla platformy ASP.NET Core Blazor).

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.