次の方法で共有

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

  • [アーティクル]

Note

これは、この記事の最新バージョンではありません。 現在のリリースについては、この記事の .NET 9 バージョンを参照してください。

警告

このバージョンの ASP.NET Core はサポート対象から除外されました。 詳細については、「.NET および .NET Core サポート ポリシー」を参照してください。 現在のリリースについては、この記事の .NET 8 バージョンを参照してください。

重要

この情報はリリース前の製品に関する事項であり、正式版がリリースされるまでに大幅に変更される可能性があります。 Microsoft はここに示されている情報について、明示か黙示かを問わず、一切保証しません。

現在のリリースについては、この記事の .NET 9 バージョンを参照してください。

Visual Studio には、ASP.NET Core バックエンドを持つ Angular、React、Vue などの JavaScript フレームワークに基づいてシングルページ アプリ (SPA) を作成するためのプロジェクト テンプレートが用意されています。 これらのテンプレートでは、次のことを行います。

  • フロントエンド プロジェクトとバックエンド プロジェクトを含む Visual Studio ソリューションを作成します。
  • JavaScript には Visual Studio プロジェクトの種類を使用し、フロントエンドには TypeScript (.esproj) を使用します。
  • バックエンドには ASP.NET Core プロジェクトを使用します。

Visual Studio テンプレートを使って作成されたプロジェクトは、Windows、Linux、macOS のコマンド ラインから実行できます。 アプリを実行するには、dotnet run --launch-profile https を使用してサーバー プロジェクトを実行します。 サーバー プロジェクトを実行すると、フロントエンドの JavaScript 開発サーバーが自動的に起動します。 現在、https 起動プロファイルが必要です。

Visual Studio チュートリアル

Angular プロジェクトを初めて使う場合は、Visual Studio ドキュメントの Angular を使用した ASP.NET Core アプリの作成に関するチュートリアルに従ってください。

詳細については、「Visual Studio の JavaScript および TypeScript」を参照してください

ASP.NET Core SPA テンプレート

Visual Studio には、JavaScript または TypeScript フロントエンドを使用して ASP.NET Core アプリを構築するためのテンプレートが含まれています。 これらのテンプレートは、ASP.NET と Web 開発ワークロードがインストールされている Visual Studio 2022 バージョン 17.8 以降で使用できます。

JavaScript または TypeScript フロントエンドを使用して ASP.NET Core アプリを構築するための Visual Studio テンプレートには、次の利点があります。

  • フロントエンドとバックエンドのプロジェクト分離をクリーンにする。
  • 最新のフロントエンド フレームワーク バージョンを最新の状態に保つ。
  • Vite など、最新のフロントエンド フレームワーク コマンドライン ツールと統合する。
  • JavaScript と TypeScript の両方のテンプレート (Angular に対しては TypeScript のみ)。
  • 豊富な JavaScript と TypeScript コードの編集エクスペリエンス。
  • JavaScript ビルド ツールを .NET ビルドと統合する。
  • npm 依存関係管理 UI。
  • Visual Studio Code のデバッグと起動の構成と互換性がある。
  • JavaScript テスト フレームワークを使用して、テスト エクスプローラーでフロントエンド単体テストを実行する。

レガシ ASP.NET Core SPA テンプレート

以前のバージョンの .NET SDK には、ASP.NET Core を使用して SPA アプリを構築するためのレガシ テンプレートが含まれていました。 これらの以前のテンプレートに関するドキュメントについては、ASP.NET Core 7.0 バージョンの SPA の概要と Angular および React に関する記事を参照してください。

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 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 がクライアント アプリを毎回リビルドするまで待つ必要はなくなります。

プロキシが起動されると、ターゲット URL とポートは、.NET によって設定された環境変数、 ASPNETCORE_URLS と ASPNETCORE_HTTPS_PORTS から推論されます。 URL または HTTPS ポートを設定するには、環境変数のいずれかを使用するか、proxy.conf.json の値を変更します。

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 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 がクライアント アプリを毎回リビルドするまで待つ必要はなくなります。

プロキシが起動されると、ターゲット URL とポートは、.NET によって設定された環境変数、 ASPNETCORE_URLS と ASPNETCORE_HTTPS_PORTS から推論されます。 URL または HTTPS ポートを設定するには、環境変数のいずれかを使用するか、proxy.conf.json の値を変更します。

.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 をご覧ください。

その他のリソース