WebSurfer's Home

トップ > Blog 1   |   Login
Filter by APML

開発環境で Kestrel 利用

by WebSurfer 25. September 2020 10:55

先の記事「ASP.NET Core アプリの Web サーバー」に書きましたが、Visual Studio から ASP.NET Core アプリを実行するとデフォルトでは IIS Express を使用するインプロセスホスティングモデルになります。

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

それを以下のように Kestrel をエッジサーバーとして使うようにするにはどうすれば良いかということを書きます。

Kestrel

実は最近まで知らなかったのですが、Visual Studio のツールバーにあるドロップダウンの選択で容易に変更できるそうです。

ドロップダウンの選択

デフォルトでは IIS Express が選択されています。その状態で Visual Studio から[デバッグ(D)]⇒[デバッグの開始(S)](または[デバッグなしで開始(H)]) でアプリを起動するとIIS Express を使用するインプロセスホスティングモデルで動きます。

ドロップダウンの選択をプロジェクト名(上の画像の例では MvcCoreApp)に変更して Visual Studio からアプリを起動すると以下のように dotnet run コマンドによってアプリが Kestrel で実行され、

dotnet run コマンド

処理された応答が自動的にブラウザに表示されます(自動的にブラウザに表示されるのは Visual Studio を使った場合です。下の注記を見てください)。

Chrome で表示

(注: dotnet run コマンドはアプリを実行するだけです。ブラウザに表示するにはブラウザを立ち上げてアドレスバーに dotnet run コマンドで表示される Now listenung on: にある URL(上の画像では https://localhost:5001 または http://localhost:5000)を入力して Kestrel に要求をかける必要があります。Visual Studio はブラウザの立ち上げと表示まで自動的に実行してくれます。さらに、HTTPS 通信に使う開発用のサーバー証明書も自動的に発行してくれます)

ドロップダウンの選択の変更によって何がどう変わるかの詳しい説明は Microsoft のドキュメント「ASP.NET Core で複数の環境を使用する」の「開発と launchSettings.json」のセクションに書いてあります。

簡単に言うと、Visual Studio のドロップダウンの選択によって launchSettings.json の profiles を IIS Express かプロジェクト名(上の画像の例では MvcCoreApp)のどちらかに切り替えることができ、それぞれの "commandName" キーの設定に応じて IIS Express を使用するか Kestrel を使用するかを指定できるそうです。

ちなみに、"commandName" キーに設定できるのは IISExpress, IIS, Project のいずれかということです。

なお、launchSettings.json が使えるのはローカルの開発マシンだけです。運用環境にデプロイされることはありません。なので、上記は開発環境だけでの話ですので注意してください。

開発環境でアウトプロセスホスティング構成(Kestrel を Web サーバー、IIS Express をリバースプロキシとして使う)とするのはどうすればいいかは不明です。Microsoft のドキュメント「ASP.NET Core モジュール」にプロジェクトファイルで AspNetCoreHostingModel プロパティの値を OutOfProcess に設定すると書いてあるのを見つけましたが未検証・未確認です。今後の検討課題ということで・・・

Tags: ,

CORE

LocalDB の照合順序

by WebSurfer 24. September 2020 11:28

Microsoft LocalDB の照合順序はデフォルトで SQL_Latin1_General_CP1_CI_AS になるそうです。今更ながらですが調べてみたらそうなってました。

LocalDB の照合順序

Microsoft の Blog の記事「[SQL Azure] Unicode型列(NCHAR/NVARCHAR) に格納されるデータが “?” になる」によると、SQL Azure も同じだそうです。

なので、その記事にも書いてありますが、以下のような N プレフィックスを使わない SQL では文字化けします。

INSERT INTO [Table] ([Name]) VALUES ('あいうえお')

知ってました? 何をいまさらと言われそうですけど。(汗)

SQL 文をパラメータ化し ADO.NET + SqlClient を利用して INSERT, UPDATE 操作を行えば、内部的に N プレフィックスが付与された SQL 文に変換されて実行され、文字化けの問題は起こらないので、気が付かないかもしれません。(詳しくは先の記事「パラメータ化の副次的な効用」参照)

Visual Studio を使って ASP.NET プロジェクトを作る際[個別のユーザーアカウント]を選ぶと、ASP.NET Identity のユーザー情報のストアはデフォルトで LocalDB を使う設定となり、EF Code First で生成されるデータベースの照合順序も同じく SQL_Latin1_General_CP1_CI_AS になります。

自分でモデルを定義してそれをベースに EF Code First でデータベースを生成する場合も、接続文字列で LocalDB に接続する設定がされていると当然 LocalDB にデータベースが生成されますが、同様に照合順序は SQL_Latin1_General_CP1_CI_AS になります。

ASP.NET MVC アプリでは Linq to Entities を使って DbContext クラスを継承したコンテキストクラスを操作してデータベースとのやり取りを行うケースが多いですが、そういう場合も内部的に N プレフィックスが付与された SQL 文に変換されて実行されるようで、文字化けの問題は起こらなかったです。

Tags: ,

SQL Server

環境別の appsettings.json

by WebSurfer 23. September 2020 12:10

開発環境と運用環境では、通常、接続文字列やエラー表示などが異なります。.NET Framework 版の ASP.NET Web アプリではそれらの設定は web.config ファイルに含まれており、運用環境にデプロイする際は該当部分を書き換える必要があります。

Visual Studio で開発を行う場合は、運用環境にデプロイする際書き換える部分をあらかじめ Web.Release.config というファイルに作っておき、Visual Studio の発行ツールを使ってデプロイ時に書き換えるということが可能です。

Web.Release.config

上の画像は Visual Studio Community 2019 のテンプレートを使って作成した ASP.NET Web Forms アプリで自動生成される Web.Release.config です。接続文字列とエラー表示の設定を書き換えるためのひな型が含まれています。

しかし、Core 版には .NET Framework 版と同じ機能はなさそうです。では、どうするかですが、以下の Microsoft のドキュメントに説明がありました(日本語版は翻訳がダメなので意味が分からないときは英語版を見てください)。

ASP.NET Core の構成

ASP.NET Core で複数の環境を使用する

appsettings.json に加えて、必要に応じて appsettings.Development.json, appsettings.Staging.json, appsettings.Production.json を追加し、それにそれぞれの環境専用の接続文字列などの設定を書きます。(注: Visual Studio のテンプレートを使うと appsettings.json と appsettings.Development.json は自動的に作成されプロジェクトに含まれているはずです)

appsettings.json

そして、例えば接続文字列を環境によって変えたい場合、appsettings.Development.json, appsettings.Staging.json, appsettings.Production.json にそれぞれの環境の接続文字列を書けば、環境変数 ASPNETCORE_ENVIRONMENT の値 (Development, Staging, Production のいずれか)によってファイルを選んでそれから接続文字列を取得してきます。

結果は appsettings.json の設定プラス appsettings.環境.json の設定になります。appsettings.json の設定を丸ごと appsettings.環境.json の設定に置き換えるということはしませが、設定がダブった場合(同じ名前のキーがあった場合)は、上に紹介した記事「ASP.NET Core の構成」に書いてある通り、appsettings.json の方をオーバーライドします。

例えば、開発環境においては、appsettings.Development.json 構成が appsettings.json の値を上書きします。運用環境では、appsettings.Production.json 構成が appsettings.json の値を上書きします。

なお、環境変数 ASPNETCORE_ENVIRONMENT が設定されてない場合は、上に紹介した記事「ASP.NET Core で複数の環境を使用する」に書いてあるように、デフォルトで Production になることに注意してください。

では、環境変数 ASPNETCORE_ENVIRONMENT をどのように設定するかですが・・・

開発環境では Visual Studio のテンプレートを使ってプロジェクトを作ると自動的に生成される launchSettings.json ファイルに "Development" と設定されています。

launchSettings.json

(注: 上の画像で赤枠で囲った方は Visual Studio から実行した場合デフォルトになる IIS Express を使ってインプロセスホスティングで実行する場合の設定です。下の方は Kestrel で実行する場合の設定です)

"Development" を "Staging", "Production" に変更して試してみると、上に書いた通り、取得してくる先の appsettings.環境.json が異なるのが分かるはずです。

運用環境では launchSettings.json ファイルは使いません。デプロイもされません。ではどうするかですが、そもそも環境変数なので、上に紹介した記事「ASP.NET Core で複数の環境を使用する」の「環境を設定する」のセクションに書いてあるようにして設定できるそうです。

または、ASPNETCORE_ENVIRONMENT が設定されてなければデフォルトで Production なので何も設定しないということでも良いかもしれません。

上に書いた appsettings.json の設定で接続文字列は環境によって書き換えできますが、エラー表示の設定の変更はできないので注意してください。それは Startup.cs の Configure メソッドで行います(HTTP 要求を処理するパイプラインを構成するためのミドルウェアの一部として登録)。

Visual Studio のテンプレートを使ってプロジェクトを作成すると、Startup.cs ファイルに以下のような Configure メソッドが自動的に生成されるはずです(日本語のコメントは自分が追加したものです)。

Startup.cs

環境変数 ASPNETCORE_ENVIRONMENT が Development に設定されていると env.IsDevelopment() が true になって、開発用の詳細エラーページが表示されるようになります。

Tags: , , ,

CORE

About this blog

2010年5月にこのブログを立ち上げました。その後 ブログ2 を追加し、ここは ASP.NET 関係のトピックス、ブログ2はそれ以外のトピックスに分けました。

Calendar

<<  November 2020  >>
MoTuWeThFrSaSu
2627282930311
2345678
9101112131415
16171819202122
23242526272829
30123456

View posts in large calendar