ASP.NET Core Blazor WebAssembly のホストと展開

この記事では、Blazor WebAssembly アプリをホストおよび展開する方法について説明します。

Blazor WebAssembly ホスティング モデルを使用する場合は以下のようになります。

• Blazor アプリ、その依存関係、.NET ランタイムが並行してブラウザーにダウンロードされます。
• アプリがブラウザー UI スレッド上で直接実行されます。

この記事は、Blazor アプリが静的ホスティング Web サーバーまたはサービスに配置されるデプロイ シナリオに関するものです。.NET は Blazor アプリの提供には使用されません。 この戦略については、IIS、Azure サービス、Apache、Nginx、GitHub Pages に関するこのノードの スタンドアロン デプロイ セクションとその他の記事で説明されています。

サブドメインと IIS サブアプリケーションのホスト

サブドメインのホストでは、アプリの特別な構成は必要ありません。 サブドメインでアプリをホストするために、アプリのベースパス（ タグの ）を構成する必要はありません。

IIS サブアプリケーションのホストでは、アプリのベース パスを設定する "必要があります"。 IIS サブアプリケーションのホストに関する詳細なガイダンスとクロスリンクについては、「ASP.NET Core Blazor のホストと展開」をご覧ください。

一部のモバイル デバイス ブラウザーの最大ヒープ サイズを小さくする

クライアント (Blazor またはスタンドアロン .Client アプリの Blazor Web App プロジェクト) で実行され、モバイル デバイス ブラウザー (特に iOS 上の Safari) を対象とする Blazor WebAssembly アプリをビルドする際には、MSBuild プロパティ EmccMaximumHeapSize を使用してアプリの最大メモリを減らすことが必要になる場合があります。 既定値は 2,147,483,648 バイトで、サイズが大きすぎる可能性があり、ブラウザーが許可できない状態でアプリがさらにメモリを割り当てようとすると、アプリがクラッシュする可能性があります。 次の例では、Program ファイルで値を 268,435,456 バイトに設定します。

<EmccMaximumHeapSize>268435456</EmccMaximumHeapSize>

Mono/WebAssembly MSBuild プロパティとターゲットについて詳しくは、WasmApp.Common.targets (dotnet/runtime GitHub リポジトリ) をご覧ください。

.NET アセンブリの Webcil パッケージ形式

Webcil は、制限の厳しいネットワーク環境で Blazor WebAssembly を使用できるように設計された、.NET アセンブリの Web 対応パッケージ形式です。 Webcil ファイルでは標準の WebAssembly ラッパーが使われます。アセンブリは、標準の .wasm ファイル拡張子を使用する WebAssembly ファイルとして配置されます。

Webcil は、Blazor WebAssembly アプリを公開するときの既定のパッケージ形式です。 Webcil の使用を無効にするには、アプリのプロジェクト ファイルで次の MSBuild プロパティを設定します。

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

ブート リソースの読み込み方法をカスタマイズする

loadBootResource API を使用してブート リソースの読み込み方法をカスタマイズします。 詳しくは、「ASP.NET Core Blazor の起動」をご覧ください。

圧縮

Blazor WebAssembly アプリが公開されると、公開中に出力が静的に圧縮されてアプリのサイズが縮小され、実行時の圧縮に必要なオーバーヘッドがなくなります。 次の圧縮アルゴリズムが使用されます。

• Brotli (最高レベル)
• Gzip

Blazor は、適切な圧縮ファイルにサービスを提供するため、ホストに依存します。 Blazor WebAssembly スタンドアロン アプリをホストするとき、静的に圧縮されたファイルにサービスが提供されるよう、追加の作業が必要になることがあります。

• IIS の web.config の圧縮構成については、IIS の「Brotli と Gzip の圧縮」セクションを参照してください。
• 静的に圧縮されたファイル コンテント ネゴシエーションをサポートしない静的ホスティング ソリューションでホストする場合は、Brotli 圧縮ファイルをフェッチしてデコードするようにアプリを構成することを検討してください。

google/brotli GitHub リポジトリから、JavaScript Brotli デコーダーを入手します。 縮小されたデコーダー ファイルは、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

正しいルーティングのために URL を書き換える

Blazor WebAssembly アプリ内のページ コンポーネントに対するルーティング要求は、Blazor Server アプリでのルーティング要求のように単純なものではありません。 次の 2 つのコンポーネントがある Blazor WebAssembly アプリについて考えてみます。

• Main.razor:アプリのルートで読み込まれ、About コンポーネントへのリンク (href="About") が含まれています。
• About.razor: About コンポーネント。

アプリの既定のドキュメントがブラウザーのアドレス バー (例: https://www.contoso.com/) を使用して要求された場合:

1. ブラウザーにより要求が送信されます。
2. 既定のページ (通常は index.html) が返されます。
3. index.html によりアプリがブートストラップされます。
4. Router コンポーネントが読み込まれて、RazorMain コンポーネントがレンダリングされます。

Main ページでは、About コンポーネントへのリンクの選択がクライアント上で動作します。Blazor のルーターにより、インターネット上で www.contoso.com に About を求めるブラウザーの要求が停止され、レンダリングされた About コンポーネント自体が提供されるためです。 " Blazor WebAssembly アプリ内にある" 内部エンドポイントへの要求は、すべて同じように動作します。要求によって、サーバーにホストされているインターネット上のリソースに対するブラウザーベースの要求がトリガーされることはありません。 要求は、ルーターによって内部的に処理されます。

ブラウザーのアドレス バーを使用して www.contoso.com/About の要求が行われた場合、その要求は失敗します。 アプリのインターネット ホスト上にそのようなリソースは存在しないため、"404 見つかりません" という応答が返されます。

ブラウザーではクライアント側ページの要求がインターネットベースのホストに対して行われるため、Web サーバーとホスティング サービスでは、サーバー上に物理的に存在しないリソースに対する index.html ページへのすべての要求を、書き換える必要があります。 index.html が返されると、アプリの Blazor ルーターがそれを受け取り、正しいリソースで応答します。

IIS サーバーに展開する場合は、アプリで発行される web.config ファイルで URL Rewrite Module を使用できます。 詳細については、「IIS を使用 したコア Blazor WebAssembly ASP.NET ホストおよび展開する」を参照してください。

スタンドアロン展開

"スタンドアロン デプロイ" により、Blazor WebAssembly アプリが、クライアントによって直接要求される静的ファイルのセットとして提供されます。 任意の静的ファイル サーバーで Blazor アプリを提供できます。

スタンドアロン展開資産は、 /bin/Release/{TARGET FRAMEWORK}/publish/wwwroot フォルダーまたは bin/Release/{TARGET FRAMEWORK}/browser-wasm/publish フォルダーに発行されます。このフォルダーには、 {TARGET FRAMEWORK} プレースホルダーがターゲット フレームワークです。

Azure App Service

Blazor WebAssembly アプリは、IIS でアプリをホストする Windows 上の Azure App Services にデプロイできます。

スタンドアロンの Blazor WebAssembly アプリを Azure App Service for Linux にデプロイすることは、現在サポートされていません。 スタンドアロンの Blazor WebAssembly アプリは、このシナリオをサポートしている Azure Static Web Apps を使ってホストすることをお勧めします。

Docker によるスタンドアロン

スタンドアロン Blazor WebAssembly アプリは、静的ファイル サーバーによってホストされる静的ファイルのセットとして公開されます。

Docker でアプリをホストするには、次のようにします。

• Nginx や Apache など、Web サーバーがサポートされている Docker コンテナーを選択します。
• 静的ファイルを提供するために、Web サーバーで定義されている場所フォルダーに publish フォルダー資産をコピーします。
• 必要に応じて追加の構成を適用して、Blazor WebAssembly アプリを提供します。

構成のガイダンスについては、次のリソースを参照してください。

• Nginx または Apache の記事
• Docker ドキュメント

ホストの構成値

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 コアBlazor アプリ ベース パス」を参照してください。

Von Bedeutung

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 コアBlazor アプリ ベース パス」を参照してください。

URL

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

トリマーを構成する

Blazor では、出力アセンブリから不要な中間言語 (IL) を削除するために、IL トリミング設定が各リリース ビルド上で実行されます。 詳しくは、「ASP.NET Core Blazor 用のトリマーを構成する」をご覧ください。

以前の展開の破損

通常は展開時に、次のようになります。

• 変更されたファイルのみが置き換えられます。通常は、展開が高速になります。
• 新しい展開の一部ではない既存のファイルは、新しい展開で使用するために残されています。

まれなケースとして、以前の展開の残留ファイルによって新しい展開が破損することがあります。 既存の展開 (または、展開前にローカルで発行されたアプリ) を完全に削除すると、展開が破損している問題が解決される場合があります。 多くの場合、既存の展開を一度削除するだけで問題を解決できます。これには、DevOps のビルドと配置のパイプラインが含まれます。

DevOps のビルドと配置のパイプラインが使用されているときに、以前の展開をクリアする必要があると判断した場合は、ビルド パイプラインにステップを一時的に追加して、破損の正確な原因をトラブルシューティングするまで、新しく展開するごとに前の展開を削除することができます。