• [アーティクル]

September 2017

Volume 32 Number 9

ASP.NET Core - ASP.NET Core 2.0 入門

Mike Rousos | September 2017

ASP.NET Core を使うと、高速でポータブルなクロス プラットフォームの Web アプリケーションを簡単に作成できます。今回は、シンプルな ASP.NET Core Web サイトの開発手順を紹介し、プロジェクトの各ファイルが果たす役割を説明します。それと並行して、ASP.NET Core の重要な概念についても説明します。ASP.NET Core 1.0 および 1.1 を利用している開発者が 2.0 へ移行する際に参考にできるよう、ASP.NET Core 2.0 での変更点を中心に説明します。

ASP.NET Core プロジェクトの作成

ASP.NET Core プロジェクトは、Visual Studio または .NET Core コマンド ライン インターフェイス (.NET CLI) のどちらかを使用してテンプレートを基に作成できます。最高峰のデバッグ機能、Docker との統合、その他さまざまな機能を備えている Visual Studio 2017 は、優れた .NET Core 開発エクスペリエンスを提供しますが、このチュートリアルでは、Mac や Linux 開発コンピューターで作業する開発者がいることを考えて、.NET CLI と Visual Studio Code を使います。

新しい .NET Core プロジェクトを作成するには、「dotnet new」コマンドを使用します。引数を付けずに「dotnet new」を実行すると、利用できるプロジェクト テンプレートの一覧が表示されます (図 1 参照)。以前のバージョンの .NET CLI をお使いなら、バージョン 2.0 でいくつか新しいテンプレートが提供されていることにお気付きになるでしょう。

Visual Studio .NET Core の新しいプロジェクト テンプレート

図 1 Visual Studio .NET Core の新しいプロジェクト テンプレート

Angular および React.js SPA テンプレート: これらのテンプレートからは、フロント エンドが (Angular 4 または React.js を使用する) 単一ページのアプリケーションとなる ASP.NET Core アプリケーションを作成します。これらのテンプレートには、フロント エンドおよびバック エンド アプリケーションの両方と、フロント エンドをビルドするための Webpack 構成 (および、ASP .NET Core プロジェクトがビルドされるたびに、Webpack ビルドを開始するための csproj の変更) が含まれます。

Razor ページを含む SP.NET Core Web アプリ: Razor ページは ASP.NET Core 2.0 の新機能で、要求を直接 (コントローラー不要で) 処理できるページを作成できます。Razor ページは、ページベースのプログラミング モデルが適したシナリオで活用できます。

このチュートリアルでは、まず、「dotnet new razor」を実行して、Razor ページ テンプレートを使用します。プロジェクトが作成されるとすぐに、「dotnet run」を実行して、プロジェクトを実行できるようになります。以前のバージョンの .NET Core では、「dotnet restore」を最初に実行して、必要な NuGet パッケージをインストールする必要がありました。しかし、.NET Core 2.0 からは、restore コマンドは、それに依存する CLI コマンドによって自動的に実行されるようになりました。テンプレート Web site サイトをテストしてみてください。「dotnet run」を実行すると、アプリがリッスンしている URL (おそらく http://localhost:5000) に移動します。そして Web アプリがレンダリングされます (図 2 参照)。

実行中のシンプルな ASP.NET Core アプリ

図 2 実行中のシンプルな ASP.NET Core アプリ

これだけで、初めての ASP.NET Core 2.0 アプリが起動されます。 これでシンプルな Web アプリを実行できたので、ASP.NET Core のしくみをより深く理解できるように、プロジェクトのコンテンツを見ていきましょう。

依存関係、ソース、およびリソース

まずはプロジェクト ファイルの .csproj ファイルについて説明します。このファイルによって、依存するパッケージや対象にする .NET Core のバージョンなど、プロジェクトをビルドするための指示を MSBuild に伝えます。過去に .csproj ファイルをご覧になったことがあれば、このプロジェクト ファイルがはるかに小さいことがわかります。.csproj ファイルをさらに短く、判読できるものにするために、多大な努力がなされています。プロジェクト ファイルを縮小するための変更で特に目に付くのは、ソース ファイルを明示的にリスト アップする必要がなくなったことです。.NET Core SDK が自動的にプロジェクト ファイルの近隣の .cs ファイル、または、.csproj のディレクトリ以下のディレクトリにある .cs ファイルをコンパイルします。同様に、.resx ファイルが検出された場合は、リソースとして埋め込みます。これらの .cs ファイルの全部をコンパイルしたくない場合は、Compile ItemGroup から削除するか、EnableDefaultCompileItems プロパティを false に設定して、既定のコンパイル項目を完全に無効にします。

アプリが実行される .NET バージョンは、<TargetFramework> 要素によって指定します。この要素は、ASP.NET Core 2.0 の新機能と、大幅に拡張された .NET Core 2.0 のセキュリティ構成を利用するために、netcoreapp2.0 に設定されています。

.csproj ファイルの中央にある <PackageReference> 要素は、プロジェクトが依存する NuGet パッケージを指定します。ASP.NET Core 2.0 の場合、既定では 1つのメタパッケージ (Microsoft.AspNetCore.All) のみが指定されています。このパッケージには、その他すべての Microsoft.AspNetCore パッケージが含まれているため、参照は 1 つで済みます。このパッケージのおかげで、以前のバージョンと比べて ASP.NET Core 2.0 プロジェクト ファイルは大幅に縮小されています。別の NuGet 依存関係は、<PackageReference> 要素を追加するか、Visual Studio NuGet パッケージ管理 UI または .NET CLI 「dotnet add」コマンドを使用して追加します。

SPA テンプレート (angular、react、または reactredux) を使用する場合は、プロジェクトのビルド時に Webpack が確実に実行されるように、カスタムのターゲットも .csproj に定義します。

Web ホストの作成と実行

program.cs は、アプリケーションのエントリ ポイントを表します。ASP.NET Core アプリはコンソール アプリケーションのため、コンソール アプリのご多分に洩れず、アプリの実行時に開始される Main メソッドがあります。

ASP.NET Core 2.0 テンプレートの Main メソッドの内容はとてもシンプルで、IWebHost オブジェクトを作成して、このオブジェクトに対して Run を呼び出します。

以前、ASP.NET Core 1.0 を使用したことがあれば、以前のテンプレートを基にした program.cs と比べてこのファイルがシンプルになっているのがわかります。この理由は、新しい WebHost.CreateDefaultBuilder メソッドです。以前の ASP.NET Core アプリの Main メソッドでは、IWebHost インスタンスを作成するために、WebHostBuilder の構成が必要でした。この構成には、Web サーバーの指定、コンテンツのルート パスの設定、IIS の統合の有効化などの手順が含まれていました。

新しい CreateDefaultBuilder メソッドでは、最も一般的な構成を既に施した、すぐに使用できる IWebHost を作成することで、作業を簡略化しています。また、CreateDefaultBuilder が対応するのは、前述の項目の指定だけではありません。以前は Startup.cs によって処理していたセットアップ作業の一部 (構成情報のセットアップや既定のログ プロバイダーの登録) にも対応します。ASP.NET Core はオープン ソースのため、CreateDefaultBuilder の処理についての詳しい情報はすべて確認できます。ご興味があれば GitHub (bit.ly/2uR1Dar、英語) でソースをご覧ください。

ここからは、CreateDefaultBuilder で最も重要な呼び出しと、その目的について見ていきます。それらの呼び出しはすべて (CreateDefaultBuilder によって) 自動で作成されますが、背後で実行される処理を理解しておいて損はありません。

UseKestrel はアプリケーションが Kestrel を使用することを指定します。Kestrel は libuv ベースのクロス プラットフォーム Web サーバーです。ここでのもう 1 つのオプションは Web サーバーに HttpSys を使用するためのものです (UseHttpSys)。HttpSys は Windows (Windows 7/2008 R2 以降) でしかサポートされませんが、Windows 認証を利用でき、インターネットに直接公開して実行しても安全です (一方 Kestrel は、インターネットからの要求を受信する場合、IIS、Nginx、Apache などのリバース プロキシーの後ろに置く必要があります)。

UseContentRoot は、アプリケーションのルート ディレクトリを指定します。ASP.NET Core は、そのディレクトリで構成ファイルなどサイト全体に影響するコンテンツを検索します。これは Web ルート (静的ファイルが提供されるルート) とは異なることに注意していください。ただし、既定では、Web ルートはコンテンツ ルートを基に設定されます ([ContentRoot]/wwwroot)。

ConfigureAppConfiguration は、アプリケーションが実行時に設定を読み取るときに使う構成オブジェクトを作成します。CreateDefaultBuilder から呼び出されると、appsettings.json ファイル、環境固有の .json ファイル (存在する場合)、環境変数、およびコマンドライン引数からアプリケーション構成設定を読み取ります。開発環境では、ユーザー シークレットも使用します。このメソッドは ASP.NET Core 2.0 の新しいメソッドです。後ほど詳しく説明します。

ConfigureLogging はアプリケーションのログを設定します。CreateDefaultBuilder から呼び出されると、コンソールおよびデバッグ ログ プロバイダーが追加されます。ConfigureAppConfiguration と同様、これも新しいメソッドで、後ほど詳しく説明します。

UseIISIntegration は、IIS 内で実行するアプリケーションを構成します。ただし、UseKestrel はやはり必要であることに注意してください。IIS はリバース プロキシとなるため、Kestrel がホストとして使用されることに変わりありません。また、UseIISIntegration は、アプリケーションが IIS の背後で実行される場合は何の効果もないため、アプリケーションが IIS 以外のシナリオで実行される場合でも、問題なく呼び出すことができます。

たいていは、Create­DefaultBuilder が提供する既定の構成で十分です。この呼び出し以外で必要になるのは、UseStartup<T> を呼び出して、アプリケーションのスタートアップ クラスを指定することだけです。この "T" はスタートアップの種類を表します。

CreateDefaultBuilder では実際のシナリオのニーズを満たせない場合は、IWebHost の作成方法を自由にカスタマイズしてください。わずかな変更で済む場合は、CreateDefault­Builder を呼び出して、返された WebHostBuilder を変更します (たとえば構成ソースを追加するなら、おそらく、再度 ConfigureAppConfiguration を呼び出します)。IWebHost を大幅に変更する必要がある場合は、CreateDefaultBuilder の呼び出しを完全に省略して、ASP.NET Core 1.0 または 1.1 で作業するときのように、WebHostBuilder 自体を作成します。この方法を選択する場合でも、新しい ConfigureAppConfiguration メソッドと ConfigureLogging メソッドを活用できます。Web ホスト構成の詳細については、bit.ly/2uuSwwM (英語) を参照してください。

ASP.NET Core 環境

CreateDefaultBuilder が実行するアクションのいくつかは、ASP.NET Core アプリケーションが実行されている環境に依存します。環境の概念は 2.0 以前にもありましたが、頻繁に出てくる概念なので、簡単に見直しておきます。

ASP.NET Core では、アプリケーションを実行する環境を、ASPNETCORE_ENVIRONMENT 環境変数で示します。これは好きな値に設定できますが、通常は、Development、Staging、および Production を使用します。したがって、「dotnet run」の呼び出し前にASPNETCORE_ENVIRONMENT 変数を Development に設定した場合 (またはこの変数を launchSettings.json ファイルに設定した場合)、アプリケーションは (変数を設定しなかった場合に既定値となる Production モードではなく) Development モードで実行されます。この値はいくつかの ASP.NET Core 機能 (後ほど、構成とログについて説明するときに言及します) によって、実行時の動作を変更するために使用されます。また、IHostingEnvironment サービスを使用して、独自のコードからアクセスすることもできます。ASP.NET Core 環境の詳細については、ASP.NET Core のドキュメント (bit.ly/2eICDMF、英語) を参照してください。

ASP.NET Core の構成

ASP.NET Core は、Microsoft.Extensions.Configuration パッケージの IConfiguration インターフェイスを使用して、実行時の構成設定を提供します。前に説明したとおり、CreateDefaultBuilder は.json ファイルと環境変数から設定を読み取ります。ただし、構成システムは拡張可能で、さまざまなプロバイダー (.json ファイル、.xml ファイル、.ini ファイル、環境変数、Azure Key Vault など) から構成情報を読み取ることができます。

IConfiguration オブジェクトと IConfigurationBuilder オブジェクトを操作するときは、プロバイダーを追加する順序が重要です。順序が後のプロバイダーが先のプロバイダーの設定をオーバーライドする可能性があるため、基本の共通プロバイダーを先に追加して、その後で一部の設定をオーバーライドする可能性がある環境固有のプロバイダーを追加するとよいでしょう。

ASP.NET Core の構成設定は階層型です。たとえば、作成した新しいプロジェクトでは、appsettings.json (図 3 参照) にトップレベルの Logging 要素と、それ以下のサブ設定が含まれています。これらの設定では、ログに記録するメッセージの最小優先度 ("LogLevel" 設定) と、メッセージがログに記録された時点のアプリの論理スコープを記録するかどうか ("IncludeScopes") が指定されています。このような入れ子になった設定を取得するには、IConfiguration.GetSection メソッドを使用して構成の特定の 1 セクションを取得するか、特定の設定の完全なパスを、コロンで区切って指定します。そこで、プロジェクトの Include­Scopes の値を取得すると、次のようになります。

図 3 ASP.NET Core 設定ファイル

{
  "Logging": {
    "IncludeScopes": false,
    "Debug": {
      "LogLevel": {
        "Default": "Warning"
      }
    },
    "Console": {
      "LogLevel": {
        "Default": "Warning"
      }
    }
  }
}

Configuration["Logging:IncludeScopes"]

環境変数を使って構成設定を定義するときは、環境変数名に階層のすべてのレベルを含めます。また、階層名はコロン (:) かアンダースコア 2 つ (__) で区切ることができます。たとえば、Logging__IncludeScopes という環境変数は、環境変数プロバイダーが設定ファイルの後に追加されている場合、図 3 のサンプル ファイルの IncludeScopes 設定をオーバーライドします。この動作は、CreateDefaultBuilder を利用する場合と同じです。

WebHost.CreateDefaultBuilder は、appsettings.json と環境固有の .json ファイルの両方から構成を読み取るため、環境が変わるとログの動作も変わります (appsettings.Development.json によって appsettings.json の LogLevel 設定は、より詳細な “Debug” レベルと “Information” レベルにオーバーライドされます)。「dotnet run」を呼び出す前に環境を Development に設定した場合、コンソールに大量のログが書き込まれます (これは、デバッグに活用できるためとても便利です)。一方、環境を Production に設定すると、警告とエラー以外はコンソール ログに記録されません (これも、コンソール ログは低速で、実稼働環境では最小限に抑える方がよいため、有用な設定です)。

ASP.NET Core 1.0 および 1.1 を使用したことがあるなら、2.0 で ConfigureAppConfiguration メソッドが新しく加わっていることにお気付きかもしれません。以前は、スタートアップの種類を作成する一環として、IConfiguration を作成するのが普通でした。新しい ConfigureAppConfiguration メソッドを使用すると、将来簡単に取得できるようにアプリケーションの依存関係の挿入 (DI) コンテナーに格納されている IConfiguration オブジェクトを更新でき、アプリケーションの有効期間の早い段階であっても構成設定を利用可能になるため、代わりの手段として有用です。

ASP.NET Core のログ

構成の設定と同様、以前のバージョンの ASP.NET Core をお使いの場合、ログの設定は Program.cs ではなく、Startup.cs で行っていたと思います。ASP.NET Core 2.0 では、IWebHost の作成中に ConfigureLogging メソッドを使ってログを設定できるようになります。

現在でもスタートアップ時にログを設定できますが (Startup.ConfigureServices で services.Add-Logging を使用)、Web ホストの作成時にログを構成することで、スタートアップの種類が合理化され、アプリのスタートアップ プロセスという早い段階でもログが利用できます。

また、構成と同様に、ASP.NET Core のログも拡張可能です。登録されるログの書き込み先のエンドポイントはプロバイダーごとに異なります。Microsoft.AspNetCore.All を参照するだけで、すぐに利用できるプロバイダーが多数あります。また、.NET 開発者コミュニティから続々とプロバイダーが提供されています。

WebHost.CreateDefaultBuilder のソース コードからわかるように、ログ プロバイダーは、ILoggingBuilder で AddDebug や AddConsole などのプロバイダー固有の拡張メソッドを呼び出して追加できます。WebHost.CreateDefaultBuilder を使用しつつ、既定のデバッグ ログやコンソール ログ以外のログ プロバイダーを登録したい場合は、CreateDefaultBuilder から返された IWebHostBuilder に対して追加で ConfigureLogging を呼び出すことで実現できます。

ログが構成され、プロバイダーが登録されると、ASP.NET Core は、受信した要求の処理作業に関するメッセージを自動的にログに記録します。依存関係の挿入により ILogger を要求することで、独自の診断メッセージをログに書き込むこともできます (これについては後ほど詳しく説明します)。メッセージをログに書き込むには、ILogger.Log と各レベルのバリエーション (LogCritical、LogInformation など) の呼び出しを使用します。

スタートアップの種類

Program.cs によってどのように Web ホストが作成されるかを説明したので、今度は Startup.cs を見ていきます。アプリが使用するスタートアップの種類は、IWebHost を作成するときに、UseStartup を呼び出して指定します。ASP.NET Core 2.0 では、(ログと構成が Program.cs で設定されるため、シンプルになったということ以外に) Startup.cs には大きな変更はありません。ただし、スタートアップの種類の 2 つの重要なメソッドは、ASP.NET Core アプリで中心的な役目を果たすため、簡単に説明します。

依存関係の挿入: スタートアップの種類の ConfigureServices メソッドは、アプリケーションの依存関係の挿入コンテナーにサービスを追加します。どの ASP.NET Core アプリにも、後で使用できるようにサービスを格納する既定の依存関係の挿入コンテナーがあります。このおかげで、サービスに依存するコンポーネントとの密結合なしで、サービスを提供することができます。今回、既に 2、3 この例を紹介しています。ConfigureAppConfiguration と ConfigureLogging のどちらも、アプリケーションで後で利用できるように、コンテナーにサービスを追加します。実行時に、ある種類のインスタンスが呼び出されると、ASP.NET Core は可能であれば、依存関係の挿入のコンテナーからオブジェクトを取得します。

たとえば、ASP.NET Core 2.0 プロジェクトの Startup クラスに、IConfiguration パラメーターを受け取るコンストラクターが含まれているとします。このコンストラクターは、IWebHost の実行が開始されるときに、自動的に呼び出されます。この呼び出しがあると、ASP.NET Core が、依存関係の挿入のコンテナーから必要な IConfiguration 引数を提供します。

別の例として、Razor ページからのメッセージをログに書き込む場合、(Startup が IConfiguration オブジェクトを要求するのと同様に) そのページのモデルのコンストラクターに渡すパラメーターとしてロガー オブジェクトを要求できます。または、cshtml 内で、次のように @inject 構文を使用します。

@using Microsoft.Extensions.Logging
@inject ILogger<Index_Page> logger

@functions {
  public void OnGet()
    {
      logger.LogInformation("Beginning GET");
    }
}

同じような方法で、IConfiguration オブジェクトや、サービスとして登録されている他の型を取得できます。この方法なら、スタートアップの種類、Razor ページ、コントローラーなどが、依存関係の挿入のコンテナーにあるサービスに緩やかに依存できます。

このセクションの冒頭で触れたように、サービスは、Startup.ConfigureServices メソッドで依存関係の挿入のコンテナーに追加されます。アプリケーションの作成に使用したプロジェクト テンプレートには、既に ConfigureServices: services.AddMvc 内に呼び出しが 1 つあります。これは、想像が付くかもしれませんが、MVC フレームワークが必要とするサービスを登録します。

Entity Framework Core も、ConfigureServices メソッドによってよく登録されるサービスの 1 種です。このサンプルでは使用していませんが、Entity Framework Core を利用するアプリケーションは、通常、services.AddDbContext への呼び出しを使用して、Entity Framework モデルの操作に必要な DbContexts を登録します。

また、(依存関係の挿入により提供されたオブジェクトに必要な有効期間に応じて) services.AddTransient、services.AddScoped、または services.Add­Singleton を呼び出して、独自の種類とサービスをここに登録することもできます。シングルトン (Singleton) として登録すると、その種類が呼び出されるたびに、サービスのインスタンスが 1 つ返されます。一方、一時 (Transient) として登録すると、要求があるたびに新しいインスタンスが作成されます。スコープ (Scoped) として追加すると、1 つの HTTP 要求を処理する間使用されるサービスのインスタンスが 1 つ作成されます。ASP.NET Core の依存関係の挿入の詳細については、bit.ly/2w7XtJI (英語) を参照してください。

HTTP 要求処理パイプラインとミドルウェア: もう 1 つの重要なスタートアップの種類のメソッドは、Configure メソッドです。これが、ASP.NET Core アプリケーションの心臓部です。ここに、アプリケーションの HTTP 要求処理パイプラインを設定します。このメソッドでは、受信 HTTP 要求に対応して応答を生成する、ミドルウェアの各種コンポーネントが登録されます。

ミドルウェアのコンポーネントは、Startup.Configure 以下の IApplicationBuilder に追加して、処理パイプラインを作成します。要求を受信すると、登録されているミドルウェアの最初のコンポーネントが呼び出されます。そのミドルウェアが必要なロジックを実行し、パイプライン内のミドルウェアの次のコンポーネントを呼び出すか、そのミドルウェアで応答を完全に処理できた場合は、(前のコンポーネントがある場合) ミドルウェアの前のコンポーネントに戻り、応答が準備できた後に必要なロジックを実行できるようにします。このミドルウェア コンポーネントの呼び出しパターンは、要求が到着した場合は上記の順序で実行され、処理された後は逆順に実行されます (図 4 参照)。

ASP.NET Core のミドルウェア処理パイプライン

図 4 ASP.NET Core のミドルウェア処理パイプライン

具体例として、図 5 はテンプレート プロジェクトの Configure メソッドを示しています。新しい要求が到着すると、要求は環境に応じて DeveloperExceptionPage ミドルウェアか ExceptionHandler ミドルウェアのどちらかに渡されます (前と同様、これは ASPNETCORE_ENVIRONMENT 環境変数を使って構成します)。これらのミドルウェア コンポーネントは、最初はアクションが少なめですが、後続のミドルウェアが実行されて、要求がミドルウェアのパイプラインから送信されるまで、要求を監視し、例外を処理します。

図 5 ASP.NET Core の Startup.Configure メソッドによってミドルウェアのパイプラインを設定

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
  if (env.IsDevelopment())
  {
    app.UseDeveloperExceptionPage();
  }
  else
  {
    app.UseExceptionHandler("/Error");
  }

  app.UseStaticFiles();

  app.UseMvc(routes =>
  {
    routes.MapRoute(
      name: "default",
      template: "{controller=Home}/{action=Index}/{id?}");
  });
}

次は、StaticFiles ミドルウェアが呼び出されます。これは、静的ファイル (画像やスタイルシートなど) を提供することで要求に対応します。このミドルウェアが対応した場合、パイプラインを停止し、直前のミドルウェア (例外ハンドラー) に制御を戻します。StaticFiles ミドルウェアが応答を提供できない場合は、次のミドルウェア コンポーネントである MVC ミドルウェアを呼び出します。このミドルウェアは、指定されているルーティング オプションに従って、要求を MVC コントローラー (または Razor ページ) へのルーティングを試みます。

ミドルウェア コンポーネントが登録される順序は、非常に重要です。UseStaticFiles が UseMvc の後に登録された場合、アプリケーションは静的ファイルを確認する前に、すべての要求の MVC コントローラーへのルーティングを試みます。これは、はっきりとわかるほどパフォーマンスが低下する可能性があります。 例外処理のミドルウェアがパイプライの後の方に追加されていると、それより前のミドルウェア コンポーネントで発生した例外を処理できません。

Razor ページ

.csproj、program.cs、startup.cs ファイルのほかに、ASP.NET Core プロジェクトにはアプリケーションの Razor ページを保持している Pages フォルダーも含まれています。ページは MVC ビューと似ていますが、要求は直接 Razor ページにルーティングでき、別途コントローラーを用意する必要はありません。そのため、ページベースのアプリケーションをシンプルにし、ビューとビュー モデルを共に保持できます。ページをサポートするモデルは、cshtml ページに直接含めるか (@functions ディレクティブ内)、別のコード ファイルに含めて、このファイルを @model ディレクティブを使って参照します。

Razor ページの詳細については、今月号の Steve Smith のコラム「Razor ページを使った簡単な ASP.NET MVC アプリ」を参照してください。

まとめ

このチュートリアルで、新しい ASP.NET Core 2.0 Web アプリケーションの作成方法を説明し、新しいプロジェクト テンプレートの内容を明らかにできていれば嬉しく思います。今回は、合理化された .csproj ファイルから、Program.cs でのアプリケーションのエントリ ポイントと Web ホスト構成、Startup.cs でのサービスとミドルウェアの登録まで、プロジェクトのコンテンツを確認しました。

ASP.NET Core でできることをさらに探求するには、その他のテンプレートをいくつか使って、新しいプロジェクトを作成してみるとよいでしょう。たとえば、Web API テンプレートや、新しい SPA テンプレートを使ってみてください。また、ASP.NET Core アプリを App Service Web アプリとして Azure に展開してみる、または、Linux または Windows Docker イメージとしてアプリケーションをパッケージ化してみるのもお勧めです。もちろん、すべてのドキュメントを網羅した docs.microsoft.com/aspnet/core もご覧ください。今回取り上げたトピックやそれ以外のトピックについて詳しい情報を提供しています。

Mike Rousosは、.NET カスタマー サクセス チームの首席ソフトウェア エンジニアです。2004 年から .NET チームの一員となり、トレース、マネージド セキュリティ、ホスティング、最も最近では .NET Core などのテクノロジに携わってきました。

この記事のレビューに協力してくれたマイクロソフト技術スタッフの Glenn Condron および Ryan Nowak に心より感謝いたします。

この記事について MSDN マガジン フォーラムで議論する