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

更新された Angular プロジェクト テンプレートは、Angular と Angular CLI を使用してリッチなクライアント側ユーザー インターフェイス (UI) を実装する ASP.NET Core アプリのための便利な開始点を提供します。The updated Angular project template provides a convenient starting point for ASP.NET Core apps using Angular and the Angular CLI to implement a rich, client-side user interface (UI).

このテンプレートは、API バックエンドとして機能する ASP.NET Core プロジェクトと、UI として機能する Angular CLI プロジェクトの作成に相当します。The template is equivalent to creating an ASP.NET Core project to act as an API backend and an Angular CLI project to act as a UI. このテンプレートは、1 つのアプリ プロジェクトの中で、両方のプロジェクトの種類をホストするという利便性を提供します。The template offers the convenience of hosting both project types in a single app project. その結果、アプリ プロジェクトを 1 つのユニットとしてビルドして発行できます。Consequently, the app project can be built and published as a single unit.

新しいアプリを作成するCreate a new app

ASP.NET Core 2.1 がインストールされている場合は、Angular プロジェクト テンプレートをインストールする必要はありません。If you have ASP.NET Core 2.1 installed, there's no need to install the Angular project template.

コマンド プロンプトで dotnet new angular コマンドを使用して、空のディレクトリの中に新しいプロジェクトを作成します。Create a new project from a command prompt using the command dotnet new angular in an empty directory. たとえば、次のコマンドは、my-new-app ディレクトリにアプリを作成し、そのディレクトリに切り替えます。For example, the following commands create the app in a my-new-app directory and switch to that directory:

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

Visual Studio または .NET Core CLI からアプリを実行します。Run the app from either Visual Studio or the .NET Core CLI:

生成された .csproj ファイルを開き、そこから通常の方法でアプリを実行します。Open the generated .csproj file, and run the app as normal from there.

ビルド プロセスは、初回の実行で npm の依存関係を復元します。これには数分かかる可能性があります。The build process restores npm dependencies on the first run, which can take several minutes. 以降のビルドは非常に高速になります。Subsequent builds are much faster.

プロジェクト テンプレートは、ASP.NET Core アプリと Angular アプリを作成します。The project template creates an ASP.NET Core app and an Angular app. ASP.NET Core アプリは、データ アクセス、承認、およびその他のサーバー側の操作で使用することを目的としています。The ASP.NET Core app is intended to be used for data access, authorization, and other server-side concerns. ClientApp サブディレクトリ内の Angular アプリは、UI に関するすべての 操作で使用することを目的としています。The Angular app, residing in the ClientApp subdirectory, is intended to be used for all UI concerns.

ページ、画像、スタイル、モジュールなどを追加するAdd pages, images, styles, modules, etc.

ClientApp ディレクトリには、標準的な Angular CLI アプリが含まれます。The ClientApp directory contains a standard Angular CLI app. 詳細については、公式の Angular ドキュメントを参照してください。See the official Angular documentation for more information.

このテンプレートによって作成される Angular アプリと Angular CLI 自体によって (ng new で) 作成されるアプリにはわずかな違いがありますが、アプリの機能は変わりません。There are slight differences between the Angular app created by this template and the one created by Angular CLI itself (via ng new); however, the app's capabilities are unchanged. テンプレートによって作成されるアプリには、ブートストラップベースのレイアウトと基本的なルーティングの例が含まれます。The app created by the template contains a Bootstrap-based layout and a basic routing example.

ng コマンドを実行するRun ng commands

コマンド プロンプトで、ClientApp サブディレクトリに切り替えます。In a command prompt, switch to the ClientApp subdirectory:

cd ClientApp

ng ツールがグローバルにインストールされている場合は、そのコマンドのすべてを実行できます。If you have the ng tool installed globally, you can run any of its commands. たとえば、ng lintng test、またはその他の Angular CLI コマンド を実行できます。For example, you can run ng lint, ng test, or any of the other Angular CLI commands. ただし、ng serve を実行する必要はありません。これは、アプリのサーバー側とクライアント側の両方に関わる部分は、ASP.NET Core アプリが処理するためです。There's no need to run ng serve though, because your ASP.NET Core app deals with serving both server-side and client-side parts of your app. 内部的には、それは、開発時に ng serve を使用します。Internally, it uses ng serve in development.

ng ツールがインストールされていない場合は、代わりに npm run ng を実行します。If you don't have the ng tool installed, run npm run ng instead. たとえば、npm run ng lint または npm run ng test を実行できます。For example, you can run npm run ng lint or npm run ng test.

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

サードパーティ製の npm パッケージをインストールするには、ClientApp サブディレクトリでコマンド プロンプトを使用します。To install third-party npm packages, use a command prompt in the ClientApp subdirectory. 次に例を示します。For example:

cd ClientApp
npm install --save <package_name>

発行と配置Publish and deploy

開発中、アプリは、開発者に便利なように最適化されたモードで実行されます。In development, the app runs in a mode optimized for developer convenience. たとえば、JavaScript バンドルには、ソース マップが含まれます (デバッグ時に元の TypeScript コードを確認できるようにするためです)。For example, JavaScript bundles include source maps (so that when debugging, you can see your original TypeScript code). アプリは、ディスク上の TypeScript、HTML および CSS ファイルの変更を監視し、これらのファイルの変更が発生した場合は、再コンパイルと再読み込みを自動的に実行します。The app watches for TypeScript, HTML, and CSS file changes on disk and automatically recompiles and reloads when it sees those files change.

運用時は、パフォーマンスが最適化されたバージョンのアプリが提供されます。In production, serve a version of your app that's optimized for performance. これは、自動的に実行されるように構成されています。This is configured to happen automatically. 発行すると、ビルド構成によって、クライアント側コードの縮小された Ahead Of Time (AoT) コンパイルが行われたビルドが生成されます。When you publish, the build configuration emits a minified, ahead-of-time (AoT) compiled build of your client-side code. 開発ビルドとは異なり、運用ビルドは、サーバーへの Node.js のインストールを必要としません (サーバー側のレンダリングを有効にしている場合は除きます (SSR))。Unlike the development build, the production build doesn't require Node.js to be installed on the server (unless you have enabled server-side rendering (SSR)).

標準的な ASP.NET Core のホストと展開方法を使用できます。You can use standard ASP.NET Core hosting and deployment methods.

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

ASP.NET Core アプリが開発モードで起動された場合、プロジェクトは、Angular CLI サーバーの独自のインスタンスをバックグラウンドで開始するように構成されます。The project is configured to start its own instance of the Angular CLI server in the background when the ASP.NET Core app starts in development mode. これが便利なのは、別のサーバーを手動で実行する必要がないためです。This is convenient because you don't have to run a separate server manually.

この既定の設定には欠点があります。There's a drawback to this default setup. C# コードを変更し、ASP.NET Core アプリを再起動する必要がある場合、Angular CLI サーバーが毎回再起動します。Each time you modify your C# code and your ASP.NET Core app needs to restart, the Angular CLI server restarts. 再起動には、約 10 秒必要です。Around 10 seconds is required to start back up. C# コードを何度も編集するが、Angular CLI が再起動するまで待ちたくない場合は、ASP.NET Core プロセスから独立した Angular CLI サーバーを外部で実行します。If you're making frequent C# code edits and don't want to wait for Angular CLI to restart, run the Angular CLI server externally, independently of the ASP.NET Core process. 次の手順に従います。To do so:

  1. コマンド プロンプトで、ClientApp サブディレクトリに切り替え、Angular CLI 開発サーバーを起動します。In a command prompt, switch to the ClientApp subdirectory, and launch the Angular CLI development server:

    cd ClientApp
    npm start
    

    重要

    Angular CLI 開発サーバーを起動するには、ng serve ではなく npm start を使用して、package.json の構成が使用されるようにします。Use npm start to launch the Angular CLI development server, not ng serve, so that the configuration in package.json is respected. Angular CLI サーバーに追加パラメーターを渡すには、package.json ファイルの関連する scripts 行にそれらを追加します。To pass additional parameters to the Angular CLI server, add them to the relevant scripts line in your package.json file.

  2. 独自のインスタンスを起動する代わりに外部の Angular CLI インスタンスを使用するように ASP.NET Core アプリケーションを変更します。Modify your ASP.NET Core app to use the external Angular CLI instance instead of launching one of its own. Startup クラスで、spa.UseAngularCliServer の呼び出しを以下に置き換えます。In your Startup class, replace the spa.UseAngularCliServer invocation with the following:

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

ASP.NET Core アプリの起動時に Angular CLI サーバーが起動されなくなります。When you start your ASP.NET Core app, it won't launch an Angular CLI server. 代わりに、手動で開始したインスタンスが使用されます。The instance you started manually is used instead. これにより、起動と再起動を高速化できます。This enables it to start and restart faster. Angular CLI がクライアント アプリを毎回リビルドするまで待つ必要はなくなります。It's no longer waiting for Angular CLI to rebuild your client app each time.

.NET コードから TypeScript コードに データを渡すPass data from .NET code into TypeScript code

SSR 中は、要求ごとのデータを ASP.NET Core アプリから Angular アプリに渡すことができます。During SSR, you might want to pass per-request data from your ASP.NET Core app into your Angular app. たとえば、cookie 情報やデータベースから読み取ったデータを渡すことができます。For example, you could pass cookie information or something read from a database. これを行うには、Startup クラスを編集します。To do this, edit your Startup class. UseSpaPrerendering のコールバックに、次のような options.SupplyData の値を設定します。In the callback for UseSpaPrerendering, set a value for options.SupplyData such as the following:

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

SupplyData コールバックでは、任意の要求ごとの JSON でシリアル可能なデータ (文字列、ブール値、数値など) を渡すことができます。The SupplyData callback lets you pass arbitrary, per-request, JSON-serializable data (for example, strings, booleans, or numbers). main.server.ts コードは、これを params.data として受け取ります。Your main.server.ts code receives this as params.data. たとえば、上記のコード サンプルは、ブール値を params.data.isHttpsRequest として createServerRenderer コールバックに渡しています。For example, the preceding code sample passes a boolean value as params.data.isHttpsRequest into the createServerRenderer callback. Angular でサポートされている方法で、アプリの他の部分にこれを渡すことができます。You can pass this to other parts of your app in any way supported by Angular. たとえば、main.server.ts が、BASE_URL 値をコンストラクターが受け取ることを宣言されているコンポーネントにその値を渡す方法を参照してください。For example, see how main.server.ts passes the BASE_URL value to any component whose constructor is declared to receive it.

SSR の欠点Drawbacks of SSR

すべてのアプリが SSR から利益を得られるわけではありません。Not all apps benefit from SSR. 主な利益は、見かけ上のパフォーマンスです。The primary benefit is perceived performance. JavaScript バンドルのフェッチまたは解析にしばらく時間がかかる場合でも、低速のネットワーク接続または低速のモバイル デバイスでアプリに到達したユーザーに、初期 UI がすぐに表示されます。Visitors reaching your app over a slow network connection or on slow mobile devices see the initial UI quickly, even if it takes a while to fetch or parse the JavaScript bundles. ただし、多くの SPA は、主に高速の社内ネットワーク コンピューターで使用されているため、アプリはほぼ瞬時に表示されます。However, many SPAs are mainly used over fast, internal company networks on fast computers where the app appears almost instantly.

同時に、SSR の有効化には重大な欠点があります。At the same time, there are significant drawbacks to enabling SSR. それは、開発プロセスの複雑さを深めます。It adds complexity to your development process. ASP.NET Core から呼び出される Node.js 環境の中で、クライアント側とサーバー側 という 2 つの異なる環境でコードを実行する必要があります。Your code must run in two different environments: client-side and server-side (in a Node.js environment invoked from ASP.NET Core). 考慮すべき点を次に示します。Here are some things to bear in mind:

  • SSR では、運用サーバー上に Node.js をインストールする必要があります。SSR requires a Node.js installation on your production servers. これは、Azure App Services などの一部のデプロイ シナリオでは自動的に実行されますが、Azure Service Fabric などの他のシナリオではそうではありません。This is automatically the case for some deployment scenarios, such as Azure App Services, but not for others, such as Azure Service Fabric.

  • BuildServerSideRenderer ビルド フラグを有効にすると、node_modules ディレクトリが発行されます。Enabling the BuildServerSideRenderer build flag causes your node_modules directory to publish. このフォルダーには、20,000 以上のファイルが含まれているため、配置時間が増加します。This folder contains 20,000+ files, which increases deployment time.

  • Node.js 環境でコードを実行するために、windowlocalStorage などのブラウザー固有の JavaScript API の存在に頼ることはできません。To run your code in a Node.js environment, it can't rely on the existence of browser-specific JavaScript APIs such as window or localStorage. コード (または参照された一部のサードパーティ製ライブラリ) がこれらの API を使用しようとすると、SSR 中にエラーが発生します。If your code (or some third-party library you reference) tries to use these APIs, you'll get an error during SSR. たとえば、jQuery は多くの場所でブラウザー固有の API を参照するため、それを使用しないでください。For example, don't use jQuery because it references browser-specific APIs in many places. エラーを防ぐには、SSR を有効にしないか、ブラウザー固有の API またはライブラリを使用しないようにする必要があります。To prevent errors, you must either avoid SSR or avoid browser-specific APIs or libraries. SSR 中に呼び出されることがないように、このような API への呼び出しをチェックしてラップできます。You can wrap any calls to such APIs in checks to ensure they aren't invoked during SSR. たとえば、JavaScript または TypeScript コードで、次のようなチェックを使用します。For example, use a check such as the following in JavaScript or TypeScript code:

    if (typeof window !== 'undefined') {
        // Call browser-specific APIs here
    }
    

その他の技術情報Additional resources