ASP.NET Core で Angular プロジェクト テンプレートを使用する

  • [アーティクル]

Angular を使用した ASP.NET Core プロジェクト テンプレートは、Angular と Angular CLI を使用してリッチなクライアント側ユーザー インターフェイス (UI) を実装する ASP.NET Core アプリのための便利な開始点を提供します。

このプロジェクト テンプレートは、Web API として機能する ASP.NET Core プロジェクトと、UI として機能する Angular CLI プロジェクトを両方作成することに相当します。 このプロジェクトの組み合わせにより、単一の ASP.NET Core プロジェクトで両方のプロジェクトをホストし、1 つの単位としてビルドして発行できるようになります。

このプロジェクト テンプレートは、サーバー側のレンダリング (SSR) 用ではありません。

新しいアプリの作成

コマンド プロンプトで dotnet new angular コマンドを使用して、空のディレクトリの中に新しいプロジェクトを作成します。 たとえば、次のコマンドは、my-new-app ディレクトリにアプリを作成し、そのディレクトリに切り替えます。

dotnet new angular -o my-new-app
cd my-new-app

Visual Studio または .NET Core CLI からアプリを実行します。

生成された .csproj ファイルを開き、そこから通常の方法でアプリを実行します。

ビルド プロセスは、初回の実行で npm の依存関係を復元します。これには数分かかる可能性があります。 以降のビルドは非常に高速になります。

プロジェクト テンプレートは、ASP.NET Core アプリと Angular アプリを作成します。 ASP.NET Core アプリは、データ アクセス、承認、およびその他のサーバー側の操作で使用することを目的としています。 ClientApp サブディレクトリ内の Angular アプリは、UI に関するすべての 操作で使用することを目的としています。

ページ、画像、スタイル、モジュールなどを追加する

ClientApp ディレクトリには、標準的な Angular CLI アプリが含まれます。 詳細については、公式の Angular ドキュメントを参照してください。

このテンプレートによって作成される Angular アプリと Angular CLI 自体によって (ng new で) 作成されるアプリにはわずかな違いがありますが、アプリの機能は変わりません。 テンプレートによって作成されるアプリには、ブートストラップベースのレイアウトと基本的なルーティングの例が含まれます。

ng コマンドを実行する

コマンド プロンプトで、ClientApp サブディレクトリに切り替えます。

cd ClientApp

ng ツールがグローバルにインストールされている場合は、そのコマンドのすべてを実行できます。 たとえば、ng lint、ng test、またはその他の Angular CLI コマンド を実行できます。 ただし、ng serve を実行する必要はありません。これは、アプリのサーバー側とクライアント側の両方に関わる部分は、ASP.NET Core アプリが処理するためです。 内部的には、それは、開発時に ng serve を使用します。

ng ツールがインストールされていない場合は、代わりに npm run ng を実行します。 たとえば、npm run ng lint または npm run ng test を実行できます。

npm パッケージをインストールする

サードパーティ製の npm パッケージをインストールするには、ClientApp サブディレクトリでコマンド プロンプトを使用します。 次に例を示します。

cd ClientApp
npm install <package_name>

発行と配置

開発中、アプリは、開発者に便利なように最適化されたモードで実行されます。 たとえば、JavaScript バンドルには、ソース マップが含まれます (デバッグ時に元の TypeScript コードを確認できるようにするためです)。 アプリは、ディスク上の TypeScript、HTML および CSS ファイルの変更を監視し、これらのファイルの変更が発生した場合は、再コンパイルと再読み込みを自動的に実行します。

運用時は、パフォーマンスが最適化されたバージョンのアプリが提供されます。 これは、自動的に実行されるように構成されています。 発行すると、ビルド構成によって、クライアント側コードの縮小された Ahead Of Time (AoT) コンパイルが行われたビルドが生成されます。 開発ビルドとは異なり、運用ビルドは、サーバーへの Node.js のインストールを必要としません (サーバー側のレンダリングを有効にしている場合は除きます (SSR))。

標準的な ASP.NET Core のホストと展開方法を使用できます。

"ng serve" を個別に実行する

ASP.NET Core アプリが開発モードで起動された場合、プロジェクトは、Angular CLI サーバーの独自のインスタンスをバックグラウンドで開始するように構成されます。 これが便利なのは、別のサーバーを手動で実行する必要がないためです。

この既定の設定には欠点があります。 C# コードを変更し、ASP.NET Core アプリを再起動する必要がある場合、Angular CLI サーバーが毎回再起動します。 再起動には、約 10 秒必要です。 C# コードを何度も編集するが、Angular CLI が再起動するまで待ちたくない場合は、ASP.NET Core プロセスから独立した Angular CLI サーバーを外部で実行します。

Angular CLI サーバーを外部で実行するには、コマンド プロンプトで ClientApp サブディレクトリに切り替え、Angular CLI 開発サーバーを起動します。

cd ClientApp
npm start

ASP.NET Core アプリの起動時に Angular CLI サーバーが起動されなくなります。 代わりに、手動で開始したインスタンスが使用されます。 これにより、起動と再起動を高速化できます。 Angular CLI がクライアント アプリを毎回リビルドするまで待つ必要はなくなります。

SignalR のプロキシ ミドルウェアを構成する

詳細については、http-proxy-middleware をご覧ください。

その他のリソース

更新された Angular プロジェクト テンプレートは、Angular と Angular CLI を使用してリッチなクライアント側ユーザー インターフェイス (UI) を実装する ASP.NET Core アプリのための便利な開始点を提供します。

このテンプレートは、API バックエンドとして機能する ASP.NET Core プロジェクトと、UI として機能する Angular CLI プロジェクトの作成に相当します。 このテンプレートは、1 つのアプリ プロジェクトの中で、両方のプロジェクトの種類をホストするという利便性を提供します。 その結果、アプリ プロジェクトを 1 つのユニットとしてビルドして発行できます。

新しいアプリを作成する

コマンド プロンプトで dotnet new angular コマンドを使用して、空のディレクトリの中に新しいプロジェクトを作成します。 たとえば、次のコマンドは、my-new-app ディレクトリにアプリを作成し、そのディレクトリに切り替えます。

dotnet new angular -o my-new-app
cd my-new-app

Visual Studio または .NET Core CLI からアプリを実行します。

生成された .csproj ファイルを開き、そこから通常の方法でアプリを実行します。

ビルド プロセスは、初回の実行で npm の依存関係を復元します。これには数分かかる可能性があります。 以降のビルドは非常に高速になります。

プロジェクト テンプレートは、ASP.NET Core アプリと Angular アプリを作成します。 ASP.NET Core アプリは、データ アクセス、承認、およびその他のサーバー側の操作で使用することを目的としています。 ClientApp サブディレクトリ内の Angular アプリは、UI に関するすべての 操作で使用することを目的としています。

ページ、画像、スタイル、モジュールなどを追加する

ClientApp ディレクトリには、標準的な Angular CLI アプリが含まれます。 詳細については、公式の Angular ドキュメントを参照してください。

このテンプレートによって作成される Angular アプリと Angular CLI 自体によって (ng new で) 作成されるアプリにはわずかな違いがありますが、アプリの機能は変わりません。 テンプレートによって作成されるアプリには、ブートストラップベースのレイアウトと基本的なルーティングの例が含まれます。

ng コマンドを実行する

コマンド プロンプトで、ClientApp サブディレクトリに切り替えます。

cd ClientApp

ng ツールがグローバルにインストールされている場合は、そのコマンドのすべてを実行できます。 たとえば、ng lint、ng test、またはその他の Angular CLI コマンド を実行できます。 ただし、ng serve を実行する必要はありません。これは、アプリのサーバー側とクライアント側の両方に関わる部分は、ASP.NET Core アプリが処理するためです。 内部的には、それは、開発時に ng serve を使用します。

ng ツールがインストールされていない場合は、代わりに npm run ng を実行します。 たとえば、npm run ng lint または npm run ng test を実行できます。

npm パッケージをインストールする

サードパーティ製の npm パッケージをインストールするには、ClientApp サブディレクトリでコマンド プロンプトを使用します。 次に例を示します。

cd ClientApp
npm install --save <package_name>

発行と配置

開発中、アプリは、開発者に便利なように最適化されたモードで実行されます。 たとえば、JavaScript バンドルには、ソース マップが含まれます (デバッグ時に元の TypeScript コードを確認できるようにするためです)。 アプリは、ディスク上の TypeScript、HTML および CSS ファイルの変更を監視し、これらのファイルの変更が発生した場合は、再コンパイルと再読み込みを自動的に実行します。

運用時は、パフォーマンスが最適化されたバージョンのアプリが提供されます。 これは、自動的に実行されるように構成されています。 発行すると、ビルド構成によって、クライアント側コードの縮小された Ahead Of Time (AoT) コンパイルが行われたビルドが生成されます。 開発ビルドとは異なり、運用ビルドは、サーバーへの Node.js のインストールを必要としません (サーバー側のレンダリングを有効にしている場合は除きます (SSR))。

標準的な ASP.NET Core のホストと展開方法を使用できます。

"ng serve" を個別に実行する

ASP.NET Core アプリが開発モードで起動された場合、プロジェクトは、Angular CLI サーバーの独自のインスタンスをバックグラウンドで開始するように構成されます。 これが便利なのは、別のサーバーを手動で実行する必要がないためです。

この既定の設定には欠点があります。 C# コードを変更し、ASP.NET Core アプリを再起動する必要がある場合、Angular CLI サーバーが毎回再起動します。 再起動には、約 10 秒必要です。 C# コードを何度も編集するが、Angular CLI が再起動するまで待ちたくない場合は、ASP.NET Core プロセスから独立した Angular CLI サーバーを外部で実行します。 次の手順に従います。

  1. コマンド プロンプトで、ClientApp サブディレクトリに切り替え、Angular CLI 開発サーバーを起動します。

    cd ClientApp
npm start

    重要

    Angular CLI 開発サーバーを起動するには、ng serve ではなく、npm start を使用して、package.json の構成が使用されるようにします。 Angular CLI サーバーに追加パラメーターを渡すには、package.json ファイル内にある、関連する scripts 行にそれらを追加します。

  2. 独自のインスタンスを起動する代わりに外部の Angular CLI インスタンスを使用するように ASP.NET Core アプリケーションを変更します。 Startup クラスで、spa.UseAngularCliServer の呼び出しを以下に置き換えます。

    spa.UseProxyToSpaDevelopmentServer("http://localhost:4200");

ASP.NET Core アプリの起動時に Angular CLI サーバーが起動されなくなります。 代わりに、手動で開始したインスタンスが使用されます。 これにより、起動と再起動を高速化できます。 Angular CLI がクライアント アプリを毎回リビルドするまで待つ必要はなくなります。

.NET コードから TypeScript コードに データを渡す

SSR 中は、要求ごとのデータを ASP.NET Core アプリから Angular アプリに渡すことができます。 たとえば、cookie 情報やデータベースから読み取ったデータを渡すことができます。 これを行うには、Startup クラスを編集します。 UseSpaPrerendering のコールバックに、次のような options.SupplyData の値を設定します。

options.SupplyData = (context, data) =>
{
    // Creates a new value called isHttpsRequest that's passed to TypeScript code
    data["isHttpsRequest"] = context.Request.IsHttps;
};

SupplyData コールバックでは、任意の要求ごとの JSON でシリアル可能なデータ (文字列、ブール値、数値など) を渡すことができます。 main.server.ts コードは、これを params.data として受け取ります。 たとえば、上記のコード サンプルは、ブール値を params.data.isHttpsRequest として createServerRenderer コールバックに渡しています。 Angular でサポートされている方法で、アプリの他の部分にこれを渡すことができます。 たとえば、main.server.ts が BASE_URL 値を任意のコンポーネントに渡す方法を確認します。このコンポーネントのコンストラクターは、その値を受け取るように宣言されています。

SSR の欠点

すべてのアプリが SSR から利益を得られるわけではありません。 主な利益は、見かけ上のパフォーマンスです。 JavaScript バンドルのフェッチまたは解析にしばらく時間がかかる場合でも、低速のネットワーク接続または低速のモバイル デバイスでアプリに到達したユーザーに、初期 UI がすぐに表示されます。 ただし、多くの SPA は、主に高速の社内ネットワーク コンピューターで使用されているため、アプリはほぼ瞬時に表示されます。

同時に、SSR の有効化には重大な欠点があります。 それは、開発プロセスの複雑さを深めます。 ASP.NET Core から呼び出される Node.js 環境の中で、クライアント側とサーバー側 という 2 つの異なる環境でコードを実行する必要があります。 考慮すべき点を次に示します。

  • SSR では、運用サーバー上に Node.js をインストールする必要があります。 これは、Azure App Services などの一部のデプロイ シナリオでは自動的に実行されますが、Azure Service Fabric などの他のシナリオではそうではありません。
  • BuildServerSideRenderer ビルド フラグを有効にすると、node_modules ディレクトリが発行されます。 このフォルダーには、20,000 以上のファイルが含まれているため、配置時間が増加します。
  • Node.js 環境でコードを実行するために、window や localStorage などのブラウザー固有の JavaScript API の存在に頼ることはできません。 コード (または参照された一部のサードパーティ製ライブラリ) がこれらの API を使用しようとすると、SSR 中にエラーが発生します。 たとえば、jQuery は多くの場所でブラウザー固有の API を参照するため、それを使用しないでください。 エラーを防ぐには、SSR を有効にしないか、ブラウザー固有の API またはライブラリを使用しないようにする必要があります。 SSR 中に呼び出されることがないように、このような API への呼び出しをチェックしてラップできます。 たとえば、JavaScript または TypeScript コードで、次のようなチェックを使用します。
if (typeof window !== 'undefined') {
    // Call browser-specific APIs here
}

SignalR のプロキシ ミドルウェアを構成する

詳細については、http-proxy-middleware をご覧ください。

その他のリソース