ASP.NET Coreアプリケーションをビルドして起動してみよう

いよいよ登場「ASP.NET Core 1.0」 マルチプラットフォームな.NETとは？　第2回

ASP.NET Coreの起動設定

　それでは、ASP.NET Coreアプリケーションを実行してみましょう。まず、起動前にアプリケーション起動設定を［プロジェクト］-［プロパティ］から確認しておきましょう。

Webサイトの起動設定画面と「launchSettings.json」

　GUIで設定した内容は、「launchSettings.json」に反映されます。ここでは「IIS Express（IISExpressコマンド）」と「AspNetCoreSample（Projectコマンド）」が設定されています。

ASP.NET Coreのデプロイ環境名

　ASP.NET Coreでは環境名として「Development」「Staging」「Production」の3つが予約されています。この設定を「launchSettings.json」の「ASPNETCORE_ENVIRONMENT」環境変数に設定します。

　これにより、コード中でIHostingEnvironmentクラスを用いて、例えばIsDevelopmentメソッドで環境名で判定することで、エラーページを制御したり、特別なCSSに差し替えることができます。

リスト6　デプロイ用の環境変数の使用例

if (env.IsDevelopment())
{
    app.UseDeveloperExceptionPage();
    app.UseBrowserLink();
}
else
{
    app.UseExceptionHandler("/Home/Error");
}

ASP.NET Coreアプリケーション（Kestrel）の起動

　それでは［AspNetCoreSample（プロジェクト名）］にて［ビルド実行（F5キー）］をクリックします。そうすると、ブラウザにスタート画面が表示されます（Kestrelの起動よりブラウザ起動が速い場合があるため、エラー時はリロードします）。設定したポート番号（http://localhost:5000）にてKestrelが起動していることがわかります。

ASP.NET Coreアプリケーションの実行画面

IISで起動する場合

　次に［IIS Express］にて［ビルド実行（F5キー）］をクリックします。先ほどと同じ内容がブラウザに表示されます。この場合、IIS Expressが一旦リクエストを受けた後、プロキシとしてKestrelサーバーに処理を渡しています。

タスクマネージャで、実行中のプロセスのコマンド引数を確認

　この挙動を確認するには、タスクマネージャの詳細タブでコマンドライン列を表示して、IIS Expressとdotnetコマンドを確認します。IIS Expressとdotnetコマンドの引数やプロセスIDを把握できます。

「netstat -nao」コマンドでdotnetコマンドが現在使用しているポートを確認

　Kestrelがどのポートで起動しているかは、「netstat -nao」コマンドとプロセスIDでフィルタで調査できます。

　なお、IISが起動しているKestrelサーバーに直接ブラウザでアクセスしても認証情報が足りないため「IISIntegration.IISMiddleware:Error: MS-ASPNETCORE-TOKEN does not match」というエラーが発生し、ページは表示されません。

「.NET Framework」と「.NET Core」の挙動の違い

　前編にてご説明した通り、ASP.NET Coreでは、「.NET Framework」または「.NET Core」のどちらかが選択できるようになりました。ビルド実行した際のブラウザ表示は同じですが、以下の出力ログを見ると、読み込まれている物理ファイルが異なることがわかります。

　.NET Frameworkの場合、アセンブリをGAC「C:\Windows\Microsoft.NET\assembly」や（配置先の構成を意識して同梱する）Binフォルダから読みこんでいます。

リスト6　実行時ログの抜粋（.NET Frameworkの場合）

'AspNetCoreFx.exe' (CLR v4.0.30319: AspNetCoreFx.exe): 'C:\WINDOWS\Microsoft.Net\assembly\GAC_MSIL\System.Xml.XDocument\v4.0_4.0.0.0__b03f5f7f11d50a3a\System.Xml.XDocument.dll' が読み込まれました。

'AspNetCoreFx.exe' (CLR v4.0.30319: AspNetCoreFx.exe): 'C:\CodeZine\AspNetCoreFx\bin\Debug\net461\win7-x64\Microsoft.AspNetCore.Mvc.dll' が読み込まれました。

　.NET Coreでは、.NET Coreのインストールフォルダ「C:\Program Files\dotnet\shared\Microsoft.NETCore.App\」や現ユーザーのフォルダ「C:\Users\＜ユーザー名＞\.nuget\packages\」フォルダから読みこんでいることがわかります。

リスト7　実行時ログの抜粋（.NET Coreの場合）

'dotnet.exe' (CoreCLR: clrhost): 'C:\Program Files\dotnet\shared\Microsoft.NETCore.App\1.0.0\System.Xml.XDocument.dll' が読み込まれました。

'dotnet.exe' (CoreCLR: clrhost): 'C:\Users\aoki\.nuget\packages\Microsoft.AspNetCore.Mvc\1.0.0\lib\netstandard1.6\Microsoft.AspNetCore.Mvc.dll' が読み込まれました。

　このような仕組により、.NET Coreでは、必要なコードとproject.jsonを配置することで、依存ライブラリをダウンロードしWebアプリケーションを動かす仕組みが備わっていることがわかります。

最後に

　以上、本稿ではASP.NET Coreの依存ファイルの解決方法、新しいツール、実行時の挙動等について紹介してきました。次回は、生成されたASP.NET Coreのコードの内容についてご紹介します。

参考資料

• Visual Studio - Web 開発用最新ツール: Grunt と Gulp（MSDN マガジン）
• ASP.NET Core 1.0の概要を整理する（ryuichi111stdさん）
• ASP.NET MVC 6 Tag Helper について（miso_soup3 Blog）
• ASP.NET Core で作成した Web API のドキュメントを Swagger を使って生成する（t-koyamaさん）
• ASP.NET Core アプリを Ubuntu サーバーで公開（creativewebjpさん）