WebSurfer's Home

トップ > Blog 1   |   ログイン
APMLフィルター

ASP.NET Core アプリの Web サーバー

by WebSurfer 2020年6月29日 15:43

ASP.NET Core 3.1 の Web アプリをホストするのに利用できる Web サーバーは何で、どのような構成になるかということを調べたので、備忘録として書いておきます。

(1) 開発環境

ASP.NET Core 3.1 の Web アプリを Visual Studio Community 2019 のテンプレートを利用して作成し、ツールバーの[デバッグ(D)]⇒[デバッグの開始(S)](または[デバッグなしで開始(H)]) で Visual Studio からアプリを実行すると IIS Express が起動されますので、デフォルトでは IIS Express が使われているのは間違いなさそうです。(注: 2021/11/9 にリリースされた Visual Studio 2022 .NET 6.0 プロジェクトではデフォルトでは Kestrel に変わっているようです)

IIS Express

Microsoft のドキュメント「ASP.NET Core での Web サーバーの実装」によると、IIS または IIS Express を使用するとインプロセス ホスティング モデルまたはアウトプロセス ホスティング モデルのどちらかで実行されるそうです。(下図参照・・・Microsoft のドキュメントから借用しました)

インプロセス ホスティング

インプロセス ホスティング モデル

アウトプロセス ホスティング

アウトプロセス ホスティング モデル

Visual Studio 2019 から実行した場合どちらで動いているかですがデフォルトでは「インプロセス ホスティング モデル」と思われます。

そのものズバリを書いた Microsoft の文書は見つからなかったので、関係する資料や Visual Studio のテンプレートで作ったアプリの内容を調べての想像が入ってますが、自信度は 90% ぐらいあります。根拠は以下の通りです。

根拠 0 (2021/5/25 追記)

後で気が付いたのですが、下記が根拠としては一番確かなようです。下の「根拠 1」~「根拠 3」はせっかく書いたので残しておきますが、見てもらわわなくても良さそうです。(笑)

Visual Studio 2019 のツールバーにあるドロップダウンはデフォルトでは以下のように IIS Express が選択されています。(注: 2021/11/9 にリリースされた Visual Studio 2022 では、デフォルトではプロジェクト名 MvcCore5App2 が選択されており、そのまま実行するとアプリは Kestrel で実行されます。選択によってどう変わるかの詳細は別の記事「開発環境で Kestrel 利用 (CORE)」を見てください)

ドロップダウンの選択

上の画像のドロップダウンで IIS Express が選択された状態で、Visual Studio 2019 のソリューションエクスプローラーからプロジェクトのプロパティを開き、[デバッグ]タブの Web サーバーの設定で[ホスティングモデル]を見るとデフォルトの選択が「(規定値) インプロセス」になっています。

Web サーバーの設定

というわけで、開発環境で Visual Studio 2019 を使ってデフォルト設定のまま ASP.NET Core アプリを実行すれば「インプロセス ホスティング モデル」で動くということに間違いなさそうです。

また、上の画像のドロップダウンで「アウトプロセス」を選択して実行すると「アウトプロセス ホスティング モデル」で動くのも間違いなさそうです。

根拠 1

Microsoft のドキュメント「IIS を使用した Windows での ASP.NET Core のホスト」には、以下のように、デフォルトでは「インプロセス ホスティング モデル」を使うと思える説明があります。

"既存のアプリではインプロセス ホスティングがオプトインされています。ASP.NET Core Web テンプレートでは、インプロセス ホスティング モデルが使用されます。"

"CreateDefaultBuilder では、UseIIS メソッドを呼び出し、CoreCLR を起動して IIS ワーカー プロセス(w3wp.exe または iisexpress.exe) 内のアプリをホストすることで、IServer インスタンスを追加します。"

"CreateHostBuilder (Program.cs) でホストを構築する場合は、CreateDefaultBuilder を呼び出して IIS 統合を有効にします。"

実際にテンプレートを使って作成したアプリの Program.cs は以下のようになっています。

namespace RazorApp
{
    public class Program
    {
        public static void Main(string[] args)
        {
            CreateHostBuilder(args).Build().Run();
        }

        public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder =>
                {
                    webBuilder.UseStartup<Startup>();
                });
    }
}

根拠 2

さらに、開発環境で IIS Express が使用する applicationHost.config に以下の設定があります。(場所に注意。IIS 用とは違います。詳しくは先の記事「ApplicationHost.config の場所」を見てください)

<system.webServer>
  <!-- 中略 -->
  <handlers>
    <add name="aspNetCore" path="*" verb="*"
      modules="AspNetCoreModuleV2"
      resourceType="Unspecified" />
  </handlers>
  <aspNetCore processPath="%LAUNCHER_PATH%"
    arguments="%LAUNCHER_ARGS%" stdoutLogEnabled="false"
    hostingModel="InProcess" startupTimeLimit="3600"
    requestTimeout="23:00:00" />
  <!-- 中略 -->
</system.webServer>

aspNetCore という名前の HTTP ハンドラが追加され、全ての要求に AspNetCoreModuleV2 ハンドラを使うよう設定されています。AspNetCoreModuleV2 というのは「ASP.NET Core モジュール」らしいです。

また、aspNetCore 要素に hostingModel="InProcess" とあり、「インプロセス ホスティング モデル」が指定されています。

ちなみに上の設定は IIS 用の applicationHost.config には含まれません。

根拠 3

Microsoft のドキュメント「ASP.NET Core モジュール」によると、"アウトプロセス ホスティング用にアプリを構成するには、プロジェクトファイル ( .csproj) で、<AspNetCoreHostingModel> プロパティの値を OutOfProcess に設定します" とのことです。

テンプレートで作ったアプリのプロジェクトファイルにはそのような設定はなく、デフォルトは InPorcess とのことなので、デフォルトでは「インプロセス ホスティング モデル」になるはずです。


ただし、別の Microsoft のドキュメント「ASP.NET Core への Kestrel Web サーバーの実装」には以下の記述があるのが気になります。

"ASP.NET Core プロジェクト テンプレートは既定では Kestrel を使用します。 Program.cs では、ConfigureWebHostDefaults メソッドにより UseKestrel が呼び出されます。"

これが自信度が 90% にとどまっている理由です。(笑)

上に述べた「ASP.NET Core への Kestrel Web サーバーの実装」の記述の他にも分からない点がいろいろあります。それらは以下の通りですが今後の調査課題ということで・・・

  • ASP.NET Core モジュールというのは、チュートリアル「IIS に ASP.NET Core アプリを発行する」のリンク先「現在の .NET Core ホスティング バンドルのインストーラー (直接ダウンロード)」からダウンロードされる dotnet-hosting-3.1.x-win.exe に含まれる Microsoft .NET Core 3.1.x - Windows Server Hosting のことだと思われる。でも、それをインストールする前から Visual Studio からアプリを実行できた。Visual Studio 2019 をインストールした時点で含まれていた?
  • IIS Express と IISHttpServer の間の設定は何もしてないがそれで動くのは何故? Microsoft のドキュメント「IIS を使用した Windows での ASP.NET Core のホスト」によると、ASP.NET Core モジュールがアプリ���初期化を実行(Loads the CoreCLR と Calls Program.Main)すると書いてある。それだけで十分なのか?
  • そもそも、デフォルトで IIS Express を使うように設定される理由は何?
  • 開発環境で IIS Express リバースプロキシとして使わないで Kestrel に直接アクセスするように設定することはできるか?(2020/9/28 追記: できるようです。詳しくは別の記事「開発環境で Kestrel 利用」を見てください)

(2) 運用環境

運用環境での Web serverについては、Microsoft のドキュメント「ASP.NET Core での Web サーバーの実装」がまとまっていて概要を理解するのに分かりやすいと思いました。

Linux 系の OS の場合は、上で紹介したドキュメントによると、要するに Nginx とか Apache をリバースプロキシに使って、Kestrel で ASP.NET Core アプリをホストするということのようです。Linux 系の OS は自分は触ったこともないので、残念ながらそれ以上詳しい話はできないです。

Windows OS の場合は、ASP.NET Core に付属している以下のサーバーを利用できるそうです。

  • Kestrel
  • IISHttpServer
  • HTTP.sys (旧称 WebListener)

運用環境で IIS によってホストする場合の説明は、Microsoft のドキュメント「IIS を使用した Windows での ASP.NET Core のホスト」が詳しいので、それを見てください。

上にも書きましたが、「インプロセス ホスティング」と「アウトプロセス ホスティング」という 2 つのモデルがあって、前者には IISHttpServer が、後者には Kestrel が使用されるそうです。

他に、HTTP.sys(IIS の HTTP Protocol Stack HTTP.sys とは違うもののようです)を使うというオプションもあるそうです。自分は勉強不足で多くは語れませんので、Microsoft のドキュメント「ASP.NET Core での HTTP.sys Web サーバーの実装」を見てください。

OS が Windows 10 Pro 64-bit の PC のローカル IIS に ASP.NET Core 3.1 アプリを発行するのは実際にやってみました。

その手順は Microsoft のチュートリアル「IIS に ASP.NET Core アプリを発行する」の通りですが、概略を以下に書いておきます。結果「インプロセス ホスティング モデル」になっていると思います。

  1. C:\WebSites2019 というフォルダ下に AspNetCoreWebSite という名前のフォルダを作成。
  2. IIS Manager を起動してそのフォルダをサイトに設定。
  3. サイトバインド設定は、種類: http, IP アドレス: 未使用の IP アドレスすべて, ポート: 80, ホスト名: www.aspnetcorewebsite.com とした。
  4. hosts ファイルに 127.0.0.1 www.aspnetcorewebsite.com と設定。
  5. VS2019 のテンプレートで自動生成される Startup.cs に HTTPS 通信を実行させるミドルウェアを適用するコード app.UseHsts(); と app.UseHttpsRedirection(); が含まれている。自分の PC のローカル IIS では HTTPS で通信できないので、そのあたりの設定を変更する必要があるかと思ったが、実際試すとそうでもなかった。 Microsoft のドキュメント Enforce HTTPS in ASP.NET Core にポートを設定しないとリダイレクトされないというようなことが書いてある。そのため?
  6. Microsoft のドキュメント「IIS を使用した Windows での ASP.NET Core のホスト」に "IIS サーバーのオプションを構成するには、IISServerOptions 用のサービス構成を ConfigureServices に含めます" と書いてあるが、テンプレートで作ったアプリにはその設定はない。設定しなければデフォルトが使われるので問題なさそう。
  7. チュートリアルの「アプリを発行および配置する」セクションに従って、上のステップで作成した C:\WebSites2019\AspNetCoreWebSite フォルダにプロジェクトを発行。IIS Manager で見た結果は下の画像のようになる。

IIS に発行された Razor ページ

  1. 以上の設定でブラウザから http://www.aspnetcorewebsite.com/ を要求すると Razor ページが表示される。 ワーカープロセスに C:\WebSites2019\AspNetCoreWebSite フォルダへの権限は何も与える必要はなかった。
  2. web.config は元のプロジェクトには含まれないが、自動生成されて配置される。aspNetCore という名前の HTTP ハンドラが追加され、全ての要求に AspNetCoreModuleV2 ハンドラを使うよう設定されている。AspNetCoreModuleV2 というのは「ASP.NET Core モジュール」らしい。
<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <location path="." inheritInChildApplications="false">
    <system.webServer>
      <handlers>
        <add name="aspNetCore" path="*" verb="*" 
          modules="AspNetCoreModuleV2" 
          resourceType="Unspecified" />
      </handlers>
      <aspNetCore processPath="dotnet" 
        arguments=".\RazorApp.dll" stdoutLogEnabled="false" 
        stdoutLogFile=".\logs\stdout" 
        hostingModel="inprocess" />
    </system.webServer>
  </location>
</configuration>
<!--ProjectGuid: 8db7ea97-35b2-4168-81d5-7c68974ce862-->

Tags: , , ,

CORE

「常にコピーする」の意味

by WebSurfer 2018年9月29日 13:32

下の画像の「常にコピーする」の「常に」の意味が、Visual Studio 2010 と Visual Studio 2015(以下、VS2010、VS2015 と書きます)では違っているという話を書きます。

出力ディレクトリにコピー

どう違うかと言うと、VS2010 ではソースコードを変更してリビルドしてから実行した場合にコピーされますが、VS2015 ではソースコードは一切変更しなくても実行するたびコピーされます。SQL Server Express のユーザーインスタンスだけでなく LocalDB の場合も同じです。

それを知らないと上記の機能を利用したアプリの開発の際、期待した結果にならなくて焦るかもしれません。何を隠そう自分がそうだったのですが。(笑) どういうことだったかと言うと以下の通りです。

開発中のアプリで DB に INSERT, DELETE, UPDATE 等の操作をしてから一旦アプリを閉じた後、DB に反映された結果を見るために、再度アプリを実行して DB の内容を表示するということがあると思います。

そういう場合、VS2010 では編集結果が表示されますが、VS2015 では編集前の元のファイルがコピーされてそれを見ることになるので、アプリが期待通り動いてないと勘違いして焦るということです。(笑)

話としては以上なのですが、それだけではブログの記事としては書き足りない気がしましたので、少し追加情報を書いておきます。

普通に SQL Server に接続してアプリを開発しようとすると、SQL Server の既定のインスタンス(または、名前付きインスタンス)に接続することになります。

既定のインスタンス(または、名前付きインスタンス)を使えるようにするには SQL Server 側の設定がいろいろ面倒ですし、そこがクリアできても Visual Studio の Express 版からでは接続できないという問題もありました。

なので、SQL Server の Express 版のユーザーインスタンスや LocalDB を使って、アプリを起動する都度 .mdf ファイルをアタッチして接続するというファイルベースの開発を行う機能が提供されています。

その際「出力ディレクトリにコピー」の設定で、出力ディレクトリに .mdf ファイルをコピーを作成してそれをアタッチする設定にすることができます。

出力ディレクトリとは Windows Forms アプリの場合は .exe ファイルが出力されるフォルダ、ASP.NET Web アプリの場合は App_Data フォルダになります。接続文字列では |DataDirectory| と指定されます。

その「出力ディレクトリにコピー」のデフォルトが「常にコピーする」になります。

「常にコピーする」の他に「コピーしない」「新しい場合はコピーする」というオプションがあります。詳しくは、@IT の記事「Visual Studio 2005でデータベースの更新が反映されない場合には?」を見てください。

VS2005 は上の記事によると「再度アプリケーションをデバッグ実行すると、そのDBファイルは上書きされてしまう」とのことです。VS2008、VS2013、VS2017 等ではどうなるか不明です。

Tags: ,

DevelopmentTools

Visual Studio で Edge 利用

by WebSurfer 2017年2月18日 14:26

先日買った Windows 10 Pro 64-bit のノート PC に旧マシンから開発環境を移していますが、Visual Studio で開発中の Web アプリを Edge で開けないという問題に遭遇しました。一応解決したので、自分が行った解決方法を備忘録として書いておきます。

Windows 10 には Microsoft Edge という新しいブラウザが標準として搭載されています。

その Edge を使うと、Visual Studio から開発中の Web アプリを開けないだけでなく、Edge を単独で立ち上げてアドレスバーにローカル IIS で動くように設定した Web アプリの URL を入力しても表示されません。

ググって調べてみると、Edge はセキュリティが厳しくなって、ローカルホスト(ホスト名に関係なく IP アドレス 127.0.0.1 がアクセス先のホスト)へのアクセスが制限されているそうです。

解決策として、Edge のアドレスバーに about:flags と入力して表示される「開発者向け設定」で[ローカルホスト ループバックを許可する]にチェックを入れて Edge を再起動するという記事がいくつか見つかりました。

��ーカルホストループバックの許可

で、早速自分もやってみました・・・が、ダメでした。(涙) 依然として Edge はローカルホストにはアクセスできません。当然 Visual Studio からローカルホストの Web アプリを開くこともできません。

さらにググって調べてみると、コントロールパネルから開く「インターネットオプション」で、ローカルイントラネットゾーンに含めるサイトの定義を変更するという記事を見つけました。

イントラネット Web サイトの設定

具体的には上の画像のように、[セキュリティ]タブ ⇒[ローカルイントラネット]⇒[サイト(S)]で表示される「ローカルイントラネット」ダイアログで[ほかのゾーンに指定されてないローカル (イントラネット) のサイトをすべて含める(Z)]のチェックを外します。

結果、Visual Studio 2010 / 2015 ともローカルホストの Web アプリを Edge で開くことができるようになりました。もちろん Edge を単独で立ち上げてアドレスバーにローカルホストの URL を入力しても表示できます。

Edge でのローカルホストサイト表示

上の画像は、Visual Studio 2015 のテンプレートを使って自動生成させたインターネット用 Web サイトアプリケーションです。

ローカル IIS 上でホスト名 websiteproject.com で動くように設定し、hosts ファイルでそのホスト名の IP アドレスを 127.0.0.1 に設定し、Visual Studio 2015 でサイトを開いて実行させています。

(ググって調べた記事の中に CheckNetIsolation.exe コマンドを使って設定するというものがいくつかありました。Edge のアドレスバーに about:flags として設定できなかった古いバージョンではそれを使っていたようです。なお、CheckNetIsolation.exe コマンドが「インターネットオプション」の変更まで行ってくれるかどうかは分かりません)

Tags: , ,

DevelopmentTools

About this blog

2010年5月にこのブログを立ち上げました。主に ASP.NET Web アプリ関係の記事です。

Calendar

<<  2024年3月  >>
252627282912
3456789
10111213141516
17181920212223
24252627282930
31123456

View posts in large calendar