C#、ASP.NET、TypeScript、AngularJS を中心にプログラミングに関した話題を諸々。
by @jsakamoto
検索
リンク
北海道のITコミュニティ - CLR/H 無聊を託つ
タグ
カテゴリ
最新の記事
ASP.NET Core 2..
at 2018-06-29 19:02
気が付いたら Visual ..
at 2018-05-23 22:34
Azure AD のユーザー..
at 2018-04-29 22:33
最近お気に入りの Visua..
at 2018-03-26 22:41
ASP.NET Core S..
at 2018-02-27 12:39
最新のコメント
助かりました。ありがとう..
by あああ at 21:32
いえす、F#! F#! :)
by developer-adjust at 21:46
F#はAzure Not..
by 幻のK泉さん at 18:37
> 今、Setcronj..
by developer-adjust at 08:25
今、Setcronjob..
by Kibe at 03:23
Jichym 改め yi..
by yi at 23:00
バッチファイル(.bat..
by Jichym at 01:26
なるほど、そこにテコ入れ..
by developer-adjust at 21:25
キャッシュを制御するディ..
by Hallo Brother. at 13:08
おっと、これはぬかりまし..
by developer-adjust at 23:57
記事ランキング
最新のトラックバック
안전놀이터
from 안전놀이터
asuransi jiwa
from asuransi jiwa
모바일카지노게임
from 카지노사이트쿠폰
Http://Www.B..
from Http://Www.Blo..
강남오피
from 강남오피
asuransi jiwa
from asuransi jiwa
강남오피
from 강남오피
istoriya.soi..
from istoriya.soipp..
asuransi jiwa
from asuransi jiwa
asuransi jiwa
from asuransi jiwa
以前の記事
2018年 06月
2018年 05月
2018年 04月
2018年 03月
2018年 02月
2018年 01月
2017年 12月
2017年 11月
2017年 10月
2017年 09月
2017年 08月
2017年 07月
2017年 06月
2017年 05月
2017年 04月
2017年 02月
2017年 01月
2016年 12月
2016年 11月
2016年 10月
2016年 09月
2016年 08月
2016年 07月
2016年 06月
2016年 05月
2016年 04月
2016年 03月
2016年 02月
2016年 01月
2015年 12月
2015年 11月
2015年 10月
2015年 09月
2015年 08月
2015年 07月
2015年 05月
2015年 04月
2015年 03月
2015年 02月
2015年 01月
2014年 12月
2014年 11月
2014年 10月
2014年 09月
2014年 08月
2014年 06月
2014年 04月
2014年 03月
2014年 02月
2014年 01月
2013年 12月
2013年 10月
2013年 09月
2013年 08月
2013年 07月
2013年 06月
2013年 05月
2013年 04月
2013年 03月
2013年 02月
2013年 01月
2012年 12月
2012年 11月
2012年 10月
2012年 09月
2012年 08月
2012年 07月
2012年 06月
2012年 05月
2012年 04月
2012年 03月
2012年 02月
2012年 01月
2011年 12月
2011年 11月
2011年 10月
2011年 09月
2011年 08月
2011年 07月
2011年 06月
2011年 05月
2011年 04月
2011年 03月
2011年 02月
2011年 01月
2010年 12月
2010年 11月
2010年 10月
2010年 09月
2010年 08月
2010年 07月
2010年 06月
2010年 05月
2010年 04月
2010年 03月
2010年 02月
2010年 01月
2009年 12月
2009年 10月
2009年 09月
2009年 07月
2009年 06月
2009年 05月
2009年 04月
2009年 03月
2009年 02月
2009年 01月
2008年 12月
2008年 11月
2008年 10月
2008年 09月
2008年 08月
2008年 07月
2008年 06月
2008年 05月
2008年 04月
2008年 03月
2008年 02月
2008年 01月
2007年 12月
2007年 11月
2007年 04月
2007年 03月
2007年 02月
2007年 01月
2006年 11月
2006年 10月
2006年 09月
2006年 08月
2006年 07月
ファン
ブログジャンル
画像一覧
2017年 12月 22日

EntityFramework Core を使ってデータベースを読み書きするプログラムの単体テストに In-Memory データベースを使ってみた

.NET プログラミングにおけるデータベースアクセスを担うライブラリ EntityFramework。

その EntityFramework の、.NET Core にも対応した新世代バージョンが EntityFramwork Core である。

EntityFrmework 及び EntityFrmework Core は、SQL Server 接続用や SQLite 接続用などの "データベースプロバイダ" を介して、実際のデータベースアクセスを行うプロバイダモデルとなっている。

そして EntityFramework Core には In-Memory データベースプロバイダが提供されている。

このデータベースプロバイダは、文字通り、メモリをデータ保存領域とした、すぐに揮発はしてしまうが高速に動作させることができるデータベースプロバイダである。
NuGet パッケージの説明書きにもあるように、もっぱらテスト用途を想定したデータベースプロバイダだ。

この In-Memory データベースプロバイダ、これまで実際に使ってみたことはなかったのだが、今回、機会を得たので、EntityFramework Core を用いたデータベースアクセスを伴うプログラムの単体テストに試用してみた。

実装の様子

下記のようなデータベースコンテキストクラスを実装していたとして、using Microsoft.EntityFrameworkCore;

public class MyDbContext : DbContext {
// ... ここに DbSet<T> 型のプロパティでエンティティ = テーブル を定義

// コンストラクタ
public MyDbContext(DbContextOptions<MyDbContext> options)
: base(options)
{
}
}
データベースコンテキストを、In-Memory データベースプロバイダの使用を指定して構築するには、下記のコードとなる。var option = new DbContextOptionsBuilder<MyDbContext>()
.UseInMemoryDatabase(databaseName: "MyMemDb")
.Options;

var db = new MyDbContext(option);
db.Database.EnsureCreated();
上記コードの最終行、"EnsureCreated()" の呼び出しによって、データベースコンテキストクラスによって示されるモデルのとおりに、In-Memory データベースが構築される。

あとはこのデータベースコンテキストオブジェクトを通して、普通に EntityFramework によるデータベースアクセスのコードが実行できる。

実際に 1対多のリレーションを持つようなモデルで、
  • エンティティへの Add() や AddRaneg() からの SaveChanges() 、
  • そのあとの Where() や OrderBy() を伴う読み取り、
  • Include() によるイーガーローディング
などを動作確認してみたが、ちゃんと期待どおりに動作してくれた。

寿命はプロセス単位、名前が同じなら同じデータベースインスタンスを指す

In-Memory データベースプロバイダを使用する指定のところで、"データベース名" なるものを指定している(下記)。 .UseInMemoryDatabase(databaseName: "MyMemDb")これは In-Memory データベースのインスタンスに付与する名前だそうだ。

さすがに使える文字種など制約・規約はあると思うが、しかしそれは別にして、とにかくプログラマが好きな名前を指定してよい。

但し、同じデータベース名を引数に UseInMemoryDatabase() 呼び出しして得たデータベースコンテキストは、同じ "内容" のデータベースを読み書きすることになる。

また、この In-Memory のデータベースは、プロセスが生きている間は生存し続けているっぽい。

この仕組み・仕様をうまく活用すれば、テスト対象の In-Memory データベース常態の初期構築をいちどだけ実行する、といった、単体テスト処理速度のチューニングに使えるのかもしれない。

しかし、同じデータベースインスタンスをテスト実行期間の間、テスト間で共有し続けたら、各テストの前提条件と結果が入り乱れてテストにならないのではないだろうか。

そう考えると、テストごとに異なる In-Memory データベースインスタンスを割り当てたほうが良いのでは、と思った。

ちなみに、テストごとに異なる In-Memory データベースのインスタンスを割り当てる、すなわち別々の異なるデータベース名で初期化するには、自分がすぐに思いつくのは GUID 値を用いる方法である。 .UseInMemoryDatabase(databaseName: Guid.NewGuid().ToString())こうすることで、とりあえずテストごとに別々の In-Memory データベースインスタンスを使用するようになり、テスト間の干渉なく安心してテストを実装・実行できる。

ただ、いちど作られた In-Memory データベースインスタンスを明示的に破棄する方法があるのかないのか、現時点ではわかっていない。

そのため、テスト実行プロセスの期間中、実行されるテストによって次々と In-Memory データベースインスタンスが立てられ、テストによってレコードが追加され、しかし破棄されないとなると、メモリ消費量が大変なことになったりしないか、ちょっと心配である。

トランザクションは効かない

あと、In-Memory データベースプロバイダは、データベーストランザクションが使えない。

In-Memory データベースプロバイダを設定したデータベースコンテキストで、下記のとおり "BeginTransaction()" 呼び出しを実行すると、var t = db.Database.BeginTransaction();この呼び出しで

「System.InvalidOperationException : Warning as error exception for warning 'Microsoft.EntityFrameworkCore.Database.Transaction.TransactionIgnoredWarning': Transactions are not supported by the in-memory store.」

という例外が発生してしまう。

上記「In-Memory データベースはトランザクションをサポートしていません」警告を、例外とせずに無視するよう設定することもできる。

下記のとおり、オプション設定するところで "ConfigureWarnings()" 呼び出しを付け加え、上記警告を示す Event ID 値を無視するよう Ignore メソッドで指定する。var option = new DbContextOptionsBuilder<MyDbContext>()
.UseInMemoryDatabase(databaseName: ...)

.ConfigureWarnings(opt => {
opt.Ignore(InMemoryEventId.TransactionIgnoredWarning);
})
.Options;
ただし、これで例外を発生することはなくなるが、In-Memory データベースがトランザクションをサポートしていないことには変わりないので注意が必要だ。

すなわち、トランザクションのロールバックが実行されても、データベース状態は巻き戻らず、すべての追加/変更は即座にコミット・反映されてしまう。

SQLite の In-Memory データベース

さてところで、EntityFramework Core で利用可能なデータベースプロバイダのひとつとして、SQLite 用データベースプロバイダがある。

そして、SQLite にも In-Memory データベース機能がある。

https://www.sqlite.org/inmemorydb.html

ということで、先述の EntityFramework Core ネイティブの In-Memory データベースプロバイダのときと同様に、単体テスト用途で、SQLite の In-Memory モードを使うこともできる。

データベースコンテキスト構築のコードは下記となる。var option = new DbContextOptionsBuilder<MyDbContext>()
.UseSqlite("Data Source=:memory:")
.Options;

var db = new MyDbContext(option);
db.Database.OpenConnection();
db.Database.EnsureCreated();
SQLite の In-Memory データベースでも、インスタンスに名前を付けて使うことができるのだが、上記コードのとおり明示的に名前を付けない場合は、接続を開くごとに異なるインスタンスとなるらしい。

先に書いたように、この振る舞いは単体テストにはうってつけである。

そのこともあり、EntityFramework Core ネイティブの In-Memory データベースプロバイダ使用のときとは違って、"OpenConnection()" 呼び出しにて明示的に接続を開いている。

また、ちゃんと確認できていないのだが、ドキュメントを読み取った感じでは、接続が閉じられる (本件で言うとデータベースコンテキストが破棄 = Dispose される) と、In-Memory データベースインスタンスも即座に破棄されるっぽい。

テスト実行プロセスの期間中ずっと、メモリ上に居座ることはなさそうな様子だ。

トランザクションもつかえる

さすが SQLite というべきか、当然のごとく、In-Memory モードにおいても、データベーストランザクションが機能する。

トランザクションを開始して、ロールバックすれば、データベース状態はトランザクション開始時点のままとなるし、コミットすれば永続化される。

まとめ

EntityFramework Core によるデータベースアクセスを伴うプログラムについて、その単体テスト実装時、揮発性の In-Memory データベースを用いて単体テストを実現する方法としては、以下が挙げられる。
  • EntityFramework Core ネイティブの In-Memory データベースプロバイダ (Microsoft.EntityFrameworkCore.InMemory) を使う
  • SQLite データベースプロバイダ (Microsoft.EntityFrameworkCore.SQLite) を用い SQLite を In-Memory データベースモードで使う

前者は、
  • トランザクションが効かないことと、
  • テスト実行プロセスの期間中、データベースインスタンスは破棄されずにメモリを消費したままとなる心配があるところ
が注意点。

個人的には、SQLite の In-Memory モードを採用の方向で考えている。
 
 

by developer-adjust | 2017-12-22 23:40 | .NET | Trackback | Comments(0)
2017年 12月 21日

.NET 用 Excel ファイル読み書きライブラリ「ClosedXML」を .NET Core 上で使う - 2017年12月21日時点の、ちょっと強引な対応方法

ClosedXML とその .NET Core 対応状況

C# などの .NET 環境において、Excel ファイルを読み書きするライブラリとしては、自分が知っている範疇では以下を挙げられる。このうち、自分は ClosedXML をよく使っている。

ところが残念なことに、2017年12月21日現在は、ClosedXML はまだ .NET Core に正式対応していない。

.NET Core 2.0 のプロジェクトに、ClosedXML の NuGet パッケージをインストールすることはできる(ただし、依存している NuGet パッケージが解決できないため、さらに手作業で DocumentFormat.OpenXml と FastMember.Signed の 2 つの NuGet パッケージを明示的にプロジェクトに追加する必要がある)。

しかしそのプログラムを実行して、実際に何か Excel ファイルを読み込む処理を実行すると、
「Could not load type 'System.Drawing.ColorTranslator' from assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'」
という実行時例外が発生してしまう。
.NET Core 2.0 ランタイム上では、System.Drawing.ColorTranslator クラスは実装されていないためだ。

ということで、2017年12月21日現在時点では、残念ながら .NET Core 上では ClosedXML は使えないということとなっている。

なお、ClosedXML に代わって、.NET Core 上でも利用可能な Excel ファイル読み書きライブラリとしては、EPPlus のベータ版があるようだ。

しかしながら自分はこれまで EPPlus を使ったこともなく、今から EPPlus に乗り換えるのもちょっと億劫に感じていた。

ClosedXML も .NET Core 上での利用に向けて対応が進行中

ところで、ClosedXML の .NET Core というか .NET Standard 2.0 対応は、実は Issue も立てられてて、別途進行中ではある模様だ。

そこで、この進行中のコードを持ってきて、私家版の ClosedXML NuGet パッケージを生成すれば、自分の .NET Core プロジェクトでも ClosedXML が使えるようになる。

ということで実際にやってみたので、その手順を以下に記す。

.NET Core 対応 私家版 ClosedXML パッケージのビルド手順

自分の環境は Windows OS。
用意するものは git と Visual Studio 2017 だ。

自分は Visual Studio の Pro Edition でこの作業を行ったが、条件を満たせば無償で利用可能な Visual Studio Community Edition でも大丈夫ではないかと思う。
また、本質的には Visual Studio は必須ではなく、.NET Core 2.0 の SDK さえあれば、dotnet コマンドで、以下で説明しているのと同じことを実行可能なはず(そしておそらくは macOS などでも)、と考えている。

さておき、ClosedXML の .NET Standard 2.0 対応は、本家の ClosedXML GitHub リポジトリから fork した、igitur 氏の GitHub リポジトリで進行している模様だ。

そこで、この igitur 氏 fork 版の GitHub リポジトリをローカル環境に git clone する。> git clone git@github.com:igitur/ClosedXML.git
> cd ClosedXML
そして、.NET Standard 2.0 対応は、netstandard2 ブランチで進行している様子。
なので、netstandard2 ブランチをチェックアウトする。> git checkout netstandard2次に、ソリューションファイル ClosedXML.sln を Visual Studio 2017 で開く。

Visual Studio でソリューションを開いたら、ソリューションのコンフィギュレーションを Release に選択変更し、ソリューションエクスプローラ上でプロジェクト「ClosedXML」を右クリックして「パッケージ」をクリックする。
d0079457_21311975.png
すると、ひととおりビルドが始まって、最終的に ./ClosedXML/bin/Release フォルダに ClosedXML.0.9.0.nupkg ができあがる。
d0079457_21315666.png

パッケージ ID の変更

基本的には、こうしてできた NuGet パッケージを使えば OK だ。

ただ、本家・公式のものと、パッケージ ID もバージョンも同じだが、中身が違う NuGet パッケージとして、この "ClosedXML.0.9.0.nupkg" をプロジェクトに取り込むと後々面倒なことになる。

そこで、どうせ私家版ビルドなので、パッケージ ID を変えてしまおう。

Visual Studio のソリューションエクスプローラ上からプロジェクト「ClosedXML」を右クリックしてプロパティを選択し、出てきたプロジェクトのプロパティの画面中、「パッケージ」のカテゴリを開くと、そこにパッケージ IDなどを設定する画面となる。

ここでパッケージ ID やバージョンなどを、適宜、私家版ビルドにふさわしいものに改変する。
d0079457_21314843.png
その上でもういちど、プロジェクト「ClosedXML」の右クリックからのパッケージ再実行で、改変後のパッケージ ID で NuGet パッケージファイル (.nupkg) ができあがる。

取り扱い上の注意

この改変後の私家版 ClosedXML パッケージだが、さすがに nuget.org に公開するのはまずいであろう。

なので、ローカルディスクであったり、あるいは会社内の LAN 上の共有フォルダに置いておくか、はたまた Visual Studio Team Service で使えるプライベート NuGet リポジトリに収録するなどして、プライベート用途に限定して非公開で配備するのがよかろうかと思う。

あと、言わずもがなだが、いくら GitHub 上で公開されているとはいえ、この私家版ビルド対象のコミットは、まだ .NET Standard 2.0 対応の仕掛中のものだ。

コミッタの igitur 氏も、私家版ビルドとはいえ、この netstandard2 ブランチからパッケージ作成して利用されることは想定していないことと思う。

まだ作業中であるが故の、igitur 氏本人にとっては既知の、これから取り掛かろうとしていた不具合修正などが多々残されてるかもしれないことは想像に難くない。
このあたりの背景や状況をよく踏まえた上で、利用可否の判断をすべきと思われる。

また、折角の機会なので、ClosedXML の .NET Standard 2.0 対応にあたり、何か助力できることがあれば、フィードバックするに越したことはないだろう。


by developer-adjust | 2017-12-21 22:00 | .NET | Trackback(3) | Comments(0)
2017年 12月 11日

Visual Studio 上で開発中の Web アプリプロジェクトで、TypeScript ファイルが意図せずコンパイルされてしまう場合の対処

Visual Studio で ASP.NET Core 2.0 Web アプリ開発をしていての話題。

こんなシナリオである。

プロジェクトの新規作成テンプレートで、SPA ではない種類のテンプレートを選んでプロジェクト作成し、開発に着手。
d0079457_22442342.png
そしてその後で、webpack による TypeScript のビルド & バンドル環境を手動で構築した。

"webpack -w" コマンドを実行するとウォッチモードで webpack が常駐し、TypeScript ファイル (.ts) を編集・保存すると自動ビルド & バンドルが行われることを確認し、しばし TypeScript ファイルの編集を継続していた。

サーバー側実装のビルドを実行した以後、.ts をいくら変更しても...

しかしそのあと、サーバー側実装を変更して Ctrl + Shift + B で Visual Studio からのビルドを実行したところ、以降、TypeScript ファイルをいくら編集 & Ctrl + S で上書き保存しても、ちっともバンドル結果の JavaScript ファイルに反映されなくなった。

webpack が何らかの原因でウォッチ停止したのかと確認してみたが、そんなことはなかった。

ウォッチをいったん停止させて、ただの "webpack" を実行してみても、webpack の表示は「正常にビルド & バンドルできましたよ」といった内容。
ということで、webpack やそのビルド環境が壊れた様子ではない。

よくよく Visual Studio の画面を見直していると、おやおや、TypeScript ファイルと対応する同名の JavaScript ファイルができあがっているではないか。
d0079457_22440267.png
どうやら Visual Studio のビルドを実行すると、ソリューションエクスプローラ上では TypeScript ファイルのビルドアクションが「なし (None)」になっていても、TypeScript コンパイラが走ってしまうらしい。

その結果、他の箇所の TypeScript コード中における import 文が、このうっかり走ってしまった TypeScript コンパイルによって生成された JavaScript のほうを読み込んでしまい、それで元となる .ts ファイルをいくら編集してもバンドル結果に読み込まれないこととなってしまったようだ。

Visual Studio からのビルド実行で不用意な TypeScript コンパイルを避けるには?

Visual Studio からのプロジェクト新規作成において、Angular などの SPA 系のテンプレートを選んでプロジェクトを新規作成した場合はこんなことはなかった覚えがある。

そこで、SPA 系テンプレートから新規作成したプロジェクトと今回問題となっているプロジェクトとで、どこが違うか、.csproj ファイルの中身を開いて見てみた。

すると、SPA 系テンプレートから作成した .csproj にはあって、今回の .csproj にはない設定が見つかった。
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>という設定である。

"TypeScript のコンパイルをブロックする" という、いかにもな感じの設定項目だ。

早速、今回の .csproj に上記設定を書き加えて保存したのちに、改めて Visual Studio 上でビルドを実行してみた。
d0079457_22443762.png
結果、上記処置で余計な TypeScript コンパイルは実行されなくなった。

解決!
 

by developer-adjust | 2017-12-11 22:50 | .NET | Trackback | Comments(0)
2017年 12月 08日

Visual Studio で C# pre-compiled な Azure Function をデバッグ実行して一瞬戸惑ったこと

以前の投稿で、Selenium WebDriver の新バージョンリリースを定期巡回で検出して自分宛にメール通知させるために、Timer をトリガとした Azure Functions を実装したことを書いた。

あの投稿の当時は Azure Functions がまだ成熟する直前であった。
ゆえに実装言語に C# を選んだ場合、"C# スクリプト" という、拡張子 .csx な形式でコードを記述する必要があった。
しかしあいにくと、.csx をコーディングするにあたっては、普通の .cs を扱うときとは数段レベルの劣る開発支援環境しかなく、かなり辛かった記憶がある。

それで、どうせスクリプトで書くのなら JavaScript (Node.js) や F# スクリプトのほうがよっぽど IDE 支援が強力じゃないか、とか思ったり、実際そうしたりしたこともあった (下記参照)。

だが今は昔。
あの投稿から程なくして、普通の C# プログラミングとして Azure Functions を実装できる環境が整った。

それが pre-compiled functions および Visual Studio 2017 Tools for Azure Functions である。

しかし時すでに遅しというか、当方、.csx や .fsx で実装した Selenium WebDriver 新バージョン検知の Functions ですでに順調に運用回っていた。
そのため、ついぞ pre-compiled 版に移行することなく日々過ぎていった。

でもいつかは pre-comiled に移行しておきたいとは考えていた。
そして、つい先日、あるきっかけができたので、ついに pre-compiled への移行を果たした。

開発はスムーズ & 楽ちん!

さすがというべきか、Visual Studio でいろいろな種類のアプリを開発開始するときと同じユーザー体験で、Azure Functions 開発ができる。

いつもどおりプロジェクトの新規作成のダイアログで "Azure Functions" を選べば、もうそれだけでプロジェクトが出来上がる。

続けて新規アイテムの追加で Azure Functon を選択すればよい。
途中、バインディングを指定するダイアログを経て、Function の枠をもった C# ソースコード (.cs) が作成される。

あともう少し (プロジェクト新規作成時にちゃんと用意されている) 設定ファイルに必要な事項を書き足せば、これでもう、F5 実行とかすれば、ローカル開発環境で Azure Function がデバッグ実行できてしまう。

デバッガでブレークポイント張ったんですけど...

...と、ここまではとんとん拍子で進んできたのだが、ここではたと戸惑った。

自分がいま開発中なのは、12時間ごとにタイマーで起動される Function だ。

で、Visual Studio で F5 実行すれば、たしかにローカル開発環境上で Azure Functions 開発用ホストプロセスが起動する。

しかし、個々の Function が呼び出されるのはトリガが発生したとき。

なので、この Function のコード内にブレークポイントを設置して待ち構えたとしても、
この Function が呼び出されるのはあと数時間後
ということになってしまった。

Azure ポータル上でブラウザ越しにちまちまスクリプトを直接記入やり方のときは、ポータル上に「テスト実行」のボタンがあり、これをクリックすることでその Function を実行できた。

だが、Visual Studio で pre-compiled な Function の開発・デバッグ実行時、この "テスト実行" を行うための UI を、自分は見つけることができなかった。

答えは公式ドキュメントに

さてどうしたものかと一瞬途方に暮れたが、落ち着いて公式ドキュメントを見てみると、あっさり答えがあった。

Function を個別にテスト実行する HTTP API エンドポイントが Azure Functions 開発用ホストプロセスに備わっているとのこと。
その API エンドポイントを叩け、ということなのだそうだ。

つまり、cURL コマンドや PowerShell の Invoke-RestMethod コマンドレットなどを活用して、HTTP リクエストを行うことで、指定の Function を呼び出してくれるという。
例えば PowerShell を使って起動する例は下記のとおり。$url = "http://localhost:7071/admin/functions/IEDriverDetector
Invoke-RestMethod -Method Post -Uri $url -Body "{}"
ということで、期待どおり、Timer トリガーな Function のテスト実行もできるようになった。

One more thing... テスト実行用の .ps1 作っておいた

さて、これで一件落着 ...なのだが、cURL にせよ Invoke-RestMethod にせよ、いくらコマンド履歴から呼び出せるとはいえ、コマンド履歴が残ってないほかのメンバの別の PC で実行するときなどなど、この HTTP POST 要求を行うコマンドを打ちなおすのはだるい。

そこで、C# Pre-Compiled Azure Functions プロジェクト向け汎用に、非HTTPトリガな Function のテスト実行を起動する PowerShell スクリプトファイルを作っておいた。

この PowerShell スクリプトを、カレントディレクトリをプロジェクトのあるフォルダにして実行すると、プロジェクト内に含まれる Function を走査・列挙して実行するようにした (但し、事前にいちど、プロジェクトをビルドしておく必要がある)。
d0079457_22523142.gif

さらに "-FuncName" オプションを実装し、Function 名を指定すればその Function をピンポイントで呼び出せるようにもしておいた。
"-FuncName" オプションは、Tab 補完によって、検出された Function 名が列挙されるようにしてある。
d0079457_22555218.gif

以上、それまでの Visual Studio による pre-compiled な Azure Functions 開発があまりに直感的かつスムーズだっただけに、個別の Function のテスト実行をどうやってやったらよいか一瞬立ち止まってしまった、という話。



by developer-adjust | 2017-12-08 23:02 | .NET | Trackback | Comments(0)
2017年 11月 27日

.NET Core 2.0 アプリで JIS 形式 (iso-2022-jp) なメールを SmtpClient で送信する

C# などを使い、.NET Core ランタイム上で動作する .NET Core 2.0 なアプリ (ASP.NET Core 含む) を開発していての話。

そのようなアプリ開発で、JIS (iso-2022-jp) エンコードなメールを、System.Net.Mail.SmtpClient を使って送信するにはどうしたらよいか、というのが今回のテーマである。

もっとも、イマドキ、アプリからのメール送信の需要は衰退の一途のような気がする (通知なら Slack や LINE、Skype などへの Bot 投稿で実装するほうがよい?)。
仮にメール送信の需要が発生したとしても、SendGrid の Web API 叩いたり、Microsoft Azure の LogicApps サービスを使ったりしてメール送信を実装したほうがよさげなので System.Net.Mail の出番はなさそうだ。
ましてや今更 JIS エンコードなメールなどほとんど絶滅危惧種ではないかとも思われる。

が、とりあえずそのような要件が発生してしまい、実装に着手したものとする。

標準の文字エンコーディング情報では不足

この場合は、下記のようなコード (例は C#) で実現するのがよくある実装かと思う。
using System.Text;
using System.Net.Mail;
...
var iso2022jp = Encoding.GetEncoding("iso-2022-jp");
var msg = new MailMessage
{
BodyEncoding = iso2022jp,
SubjectEncoding = iso2022jp,
HeadersEncoding = iso2022jp
};
このコードは、旧来からある .NET Framework 用アプリでは問題なく動作する。

しかしながら、.NET Core 用アプリでは実行時に下記例外が発生してしまう。System.ArgumentException : 'iso-2022-jp' is not a supported encoding name. 発生個所は「Encoding.GetEncoding("iso-2022-jp")」しているところ。
.NET Core ランタイムでは、標準の文字エンコーディング情報に、JISエンコーディングが含まれていないためだ。

この例外への対処は簡単である。

まず NuGet から System.Text.Encoding.CodePages パッケージをプロジェクトに追加してやる。

System.Text.Encoding.CodePages

あとはアプリの初期化のタイミングで、上記パッケージに収録されているエンコーディング情報をランタイムに登録してやればよい。using System.Text;
...
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
System.Text.Encoding.CodePages パッケージには JIS (iso-2022-jp) エンコーディング情報も収録されている。
よって、上記仕掛けを施したあとは、「Encoding.GetEncoding("iso-2022-jp")」でちゃんと Encoding オブジェクトが返ってくるようになる。

参考: OPC Diary - dotnet coreで対応しているテキストエンコーディング

System.Text.Encoding.CodePages でも不足の点が

ところが、である。

たいていの文字エンコーディングを扱う .NET Core プログラムにおいてはこれで問題解消となるのだが System.net.Mail.SmtpClient を使ったメール送信では、この対処だけではまだ足りない。

Send メソッド実行時に下記例外が発生して、相変わらず JIS (iso-2022-jp) エンコーディングでのメール送信ができないのだ。System.NotSupportedException : No data is available for encoding 50220. この例外のスタックトレースを見てみると、at System.Text.Encoding.GetDataItem()
at System.Text.Encoding.get_BodyName()
となっている。

どうも、Encoding オブジェクトの BodyName プロパティの getter で例外発生しているようだ。

念のため Visual Studio 上でブレークポイントを張って問題個所の前で停止させて、JIS エンコーディングのオブジェクトを見てみると、下図のとおり。
d0079457_11041572.png
ご覧のとおり、BodyName プロパティの参照で System.NotSupportedException 例外が発生している (BodyName プロパティに限らないが)。

他に Shift-JIS と euc-jp についても確認してみたところ、いずれも BodyName プロパティ参照で System.NotSupportedException 例外が発生した。

参考までに、ランタイム標準で備わっている UTF-8 (Encoding.UTF8) については、BodyName プロパティは、ちゃんと "utf-8" を返す。

どうやら、System.Text.Encoding.CodePages パッケージで供給される追加のエンコーディング情報、少なくとも上記 JIS, Shift-JIS, EUC-JP については、BodyName プロパティがサポートされていないようである。

いっぽうで System.Net.Mail.SmtpClient は Encoding オブジェクトの BodyName プロパティに依存しているようだ。
それで前述のとおり JIS エンコードなメールを送信しようとすると例外発生に至ってしまうらしい。

ラッパークラスを実装して回避

System.Text.Encoding.CodePages パッケージで供給される追加のエンコーディング情報について、なぜに BodyName プロパティがサポートされていないのか自分はわかっていない。

しかしとにかく、問題のメカニズムは判明したので自前の回避策は実装可能だ。

自分が実施した回避策は、
「BodyName プロパティを正しく返すよう補完実装した、Encoding から派生したラッパークラスを実装する」
という作戦。

使い方としては、まず、オリジナルの Encoding オブジェクトを、このラッパークラスのオブジェクトで包んでおく。
そして、そのラッパー Encoding オブジェクトを System.Net.Mail に教えてやる、という寸法だ。

このラッパークラスは、外部からのあらゆる問い合わせを、内包しているオリジナルの Encoding オブジェクトに横流しするだけにしておく。
ただし、オリジナルの Encoding オブジェクトが答えられない、BodyName プロパティについてだけは、オリジナルに代わってラッパークラスが返答する、という仕組みにするわけ。


ということで、そのようなラッパークラス "BodyNamePatchedEncoding" クラスを書いてみた。
下記に置いてある。

https://gist.github.com/jsakamoto/87d5b76387d8287ba6cea0362777c206

このラッパークラスの実装に面白いところは全くない。

このラッパークラスのコンストラクタで、ラップする対象の Encoding オブジェクトと、BodyName プロパティ値を受け取り、このふたつをインスタンスメンバーに保持。

あとは、Encoding オブジェクトとして必要なふるまい・プロパティ値は、メンバーに保持しているラップ対象の Encoding オブジェクトに丸投げするだけ。
ただし、BodyName プロパティだけは、コンストラクタで指定された値を返す。

BodyNamePatchedEncoding クラスの実装コードは行数がなかなかのボリュームになっている。
しかしそのほとんどが前述のとおり、ラップしている Encoding オブジェクトへ処理を横流ししているだけの、刺身タンポポ感たっぷりのコードだ。


なお、実際に BodyNamePatchedEncoding クラスを実装して System.Net.Mail.SmtpClient による JIS エンコーディングなメール送信を試したところ、最初はまたもや例外となった。
その例外の内容を見ると、どうやら SmtpClient は BodyName プロパティのみならず HeaderName プロパティも 参照してる模様。
且つ、HeaderName プロパティも System.Text.Encoding.CodePages パッケージの実装ではサポートされておらず、それでまたもや例外となったようである。
そこで、HeaderName プロパティについても BodyNamePatchedEncoding クラスがオリジナルに代わって返答することとし、返答の内容は、実装の手を抜いて、BodyName プロパティと同値を返すようにした。


以上で、この BodyNamePatchedEncoding クラスを使えば、晴れて、.NET Core アプリでの System.Net.mail.SmtpClient にて JIS エンコーディングなメール送信が実現できるようになった。using System.Text;
using System.Net.Mail;
...
Encoding.RegisterProvider(CodePagesEncodingProvider.Instance);
...
var iso2022jpOriginal = Encoding.GetEncoding("iso-2022-jp");
var iso2022jpWrapped = new BodyNamePatchedEncoding(
encoding: iso2022jpOriginal,
bodyName: "iso-2022-jp");
var msg = new MailMessage
{
BodyEncoding = iso2022jpWrapped,
SubjectEncoding = iso2022jpWrapped,
HeadersEncoding = iso2022jpWrapped
};

まとめ

.NET Core では、ランタイムが標準で提供している文字エンコーディングはかなり限定されている。

不足のエンコーディング情報が必要な場合は、System.Text.Encoding.CodePages パッケージをプロジェクトに追加して、追加されたエンコーディング情報をランタイムに登録すればよい。

しかし System.Text.Encoding.CodePages パッケージで提供される Encoding クラスの実装では、BodyName プロパティや HeaderName プロパティなどサポートされていない機能がある。

.NET Core の System.Net.Mail.SmtpClient は Encoding オブジェクトの BodyName および HeaderName プロパティを使用するので、System.Text.Encoding.CodePages パッケージで提供される Encoding クラスを指定してのメール送信では例外が発生してしまう。

これを回避する一案としては、実装が不足している機能を補うラッパー Encoding クラスを自前実装することで可能であり、実際に BodyNamePatchedEncoding クラスを実装してみて、無事メール送信に成功した次第。

補足

System.Text.Encoding.CodePages パッケージで提供される Encoding クラスの実装では、なぜ BodyName プロパティなどがサポートされていないのか、その理由が気になるところではある。
どのような設計指針・方針でサポートしないこととなったのだろうか、あるいはまた、System.Text.Encoding.CodePages パッケージの将来バージョンでは、これら機能の実装も追々追加されるのか、要注意ではあると思う。


あともうひとうつ別の話題として、ここまでの実装だと、どこか別の箇所で "Encoding.GetEncoding("iso-2022-jp")" などと Encoding オブジェクトの取得を行った場合は、相変わらず、BdoyName プロパティが機能しないオリジナル版の Encoding オブジェクトが返されることになる。

"Encoding.GetEncoding("iso-2022-jp")" を実行時も、BodyNamePatchedEncoding オブジェクトが返されるようにするには、もうひと手間必要だ。
言い換えると、もうひと手間必要ではあるが、しかしとにかく実装可能ではある。

その方法については、また機会を改めたい。
 

by developer-adjust | 2017-11-27 12:14 | .NET | Trackback | Comments(0)
2017年 10月 30日

ASP.NET Core SignalR v.1.0 Preview2 Final で Web API のアクションメソッド内など任意の箇所からクライアントにプッシュ送信する方法

ASP.NET Core SignalR とは

C# などの .NET 言語で実装する Web アプリのフレームワークである ASP.NET。
その ASP.NET フレームワーク上で、ブラウザ~サーバー間のリアルタイム双方向通信を実現するライブラリが SignalR である。

Node.js でいうところの Socket.IO に相当する、といえば話のとおりが良いだろうか。
(※もっとも、両者はそれぞれの思想や特性があるのであまり似てはいないとのこと。サーバー側からブラウザ側へ "プッシュ" する機能をカバーするという点で類似のライブラリとして話題にされるようだ。)

その SignalR だが、ASP.NET の新世代である ASP.NET Core 版もちゃんと存在する。

ただ、この記事を書いている時点では、ver.1.0.0 Alpha2 リリース最終版というバージョンが、プレリリース版として公開されているのみ。
まだ正式の初版リリースには至っていない。

Alpha1 から Alpha2 に更新されたときも、若干の破壊的変更があったようで、いかにもまだ Alpha 段階という感じ。

そんな αバージョン時点での、ASP.NET Core SignalR のお話。

ASP.NET Web API から SignalR への連携

SignalR を使った Web アプリを実装しているときに、サーバー側とクライアント側との間の通信技術が SignalR 一択である場合は、とくに困ることなく教科書どおりに実装すればよい。

しかし時折、その同一 Web アプリ上で、任意の HTTP クライアントに対する公開 Web API を搭載したい、なんてことがある。

で、えてして、その Web API で何やらが POST されたら、SignalR 経由で他のクライアントにプッシュ通知したい、なんて話になったりする。

さて、ASP.NET (ASP.NET Core じゃないほう) 時代、Web API の実装にあたっては、ASP.NET WebAPI が提供する ApiController クラスの派生クラスで API コントローラクラスを実装する。
Web API の要求は、この API コントローラクラスのメソッドに紐づけられる寸法だ。

ということで、Web API への POST を、SingalR によるプッシュ通信につなげるには、(POSTを受け付ける) API コントローラクラスのメソッド内で、SignalR における Hub クラスのコンテキストを手に入れる必要がある。


これを実現するには、下記のように書けば OK だ。
using Microsoft.AspNet.SignalR;
// FooHub という SignalR Hub クラスが定義済みだとして:
...
public IActionResult Post(...) {
...
var connectionManager = GlobalHost.ConnectionManager;
var hubContext = connectionManager.GetHubContext<FooHub>();
// ここで hubContext.Clients.All.hoge(...) とかできる
..
すなわち、ASP.NET SignalR が提供する GlobalHost クラスの ConnectionManager という静的プロパティを経由して、Hub コンテキストを入手可能という仕組みだ。

静的プロパティは、少なくともスコープの観点では事実上のグローバル変数のようなものだろう。
それでどんなシチュエーションからでも参照・入手可能ということになる。

ちなみに他にも、"HubController<T> を使う" という技法もあるらしい (2013年の記事だが、下記参照)。

ASP.NET Core SignalR からは GlobalHost クラスは廃止

...と、まぁ、ここまでは ASP.NET Core じゃない、元祖(?) ASP.NET における話。

実は ASP.NET Core 上の SignalR では、GlobalHost クラスは廃止された模様だ。

では ASP.NET Core の SignalR において、"API コントローラクラスのメソッド内から SignalR でのサーバー側からのプッシュ送信" を行うにはどうしたらよいか?


ASP.NET Core では、単純に、コントローラクラスのコンストラクタ引数に必要とするサービスインスタンスを渡してくれる、"DI (Dependency Injection, 依存性注入)" の仕組みで、任意の Hub のコンテキストが手に入る。

すなわち、コントローラクラスのコンストラクタの引数に、使用したい Hub コンテキスト型の引数を設けておけば、それだけで、ASP.NET Core MVC がそのコントローラクラスをインスタンス化するときに、その Hub コンテキストをコンストラクタ引数に入れてくれるのだ。

あとはコンストラクタに引数として渡された Hub コンテキストを、コントローラ自身のプロパティにキャッシュしておいて、アクションメソッド内から利用すれば OK だ。

具体的には下記コードとなる。
public class BarController : Controller {

private IHubContext<FooHub> FooHubContext { get; }

public BarController(IHubContext<FooHub> fooHub) {
this.FooHubContext = fooHub;
}

public IActionResult Post(...){
// ここで this.FooHubContext.Clients.All.hoge(...) とかできる
}
}
SignalR の Hub コンテキストだけ特別扱いということなく、他の各種サービスインスタンスと同じように、DI の仕組みで参照が手に入るのは、すっきりしていて覚えやすい。

また、かつての ASP.NET SignalR における GlobalHost.ConnectionManager のような static プロパティ = 実質のグローバル変数を参照することがなくなったので、単体テストもより書きやすくなる。

Web API コントローラクラス"以外"からの SignalR 連携

さてところで、Web API のコントローラクラスではなく、もっとほかのトリガーをもとに SignalR のサーバー側からクライアント側へのプッシュ送信を行うにはどうしたらよいだろう?

例えば ASP.NET Core をセルフホスティングしたプロセス上で、GPIO ピンに対する入力を監視し、入力に変化があったら SignalR でクライアントに通知する、などの実装である。

先述のとおり、(ASP.NET Core じゃない) ASP.NET SignalR では、事実上のグローバル変数 = GlobalHost.ConnectionManager をどこからでも参照できてた。
それで上記例のような案件でも GlobalHost.ConnectionManager 経由でクライアントへのプッシュ送信が記述できた。

しかし ASP.NET Core の SignalR では、既に説明したとおり、GlobalHost.ConnectionManager のような実質のグローバル変数は、もう存在しない。

ではどうするか?


私が思いついたのは、ASP.NET Core の DI の仕組みで任意の Hub クラスのコンテキストが手に入るのだから、きっと ASP.NET Core の DI の仕組みに乗っかればいいはず、というアイディアだ。


ただ残念なことに、現時点の私の知識・技量では ASP.NET Core における DI の仕組みに疎い。
ASP.NET Core MVC がコントローラクラスのインスタンス生成をどうやってるか、同じことを自分のコードで真似するにはどうしたらよいか (先の例でいうと、GPIO の監視をつかさどるクラスを new するときに、どうやって依存性の注入を行うのか) がわかってないのだ。

それでも自分がわかっている範囲で、そこそこの解決策はある。

ASP.NET Core におけるエントリポイント、Startup クラスにおいて、アプリ起動時に呼び出される Configure() メソッドの引数に渡される IApplicationBuilder オブジェクトを参照すれば、DI の仕組みで注入可能なサービスインスタンスを入手可能である。

ということで、Startup クラスの Configure() メソッド内で下記のとおり実装すれば、任意の Hub コンテキストの参照を入手可能だ。
using Microsoft.AspNetCore.SignalR;
// FooHub という SignalR Hub クラスが定義済みだとして:
...

public void Configure(IApplicationBuilder app) {
...
var hubContext = app
.ApplicationServices
.GetService<IHubContext<FooHub>>();

こうして入手した Hub コンテキストを、目的のオブジェクトに何らかの手段で引き渡せば OK だ。
(先の例でいえば、この Configure メソッド内で GPIO 監視クラスを new し、そのコンストラクタに Hub コンテキストを引き渡す設計にする、などの実装が考えられる)

まとめ

ASP.NET Core 時代の SignalR では、"DI (Dependency Injection, 依存性注入)" の仕組みで、Hub コンテキストを入手可能だ。

特に ASP.NET Core MVC/Web API コントローラクラスであれば、そのコンストラクタに IHubContext<T> 型の引数を用意すれば、そのコントローラクラスがインスタンス化 (new) されるときに、このコンストラクタ引数に T 型の Hub のコンテキストが渡される。

ASP.NET Core の DI の仕組みに乗っかれない場合でも、最悪、Startup の Configure() メソッドのタイミングで、IApplicationBuilder オブジェクト経由で、任意の Hub コンテキストを入手可能だ。
 

by developer-adjust | 2017-10-30 22:29 | .NET | Trackback | Comments(0)
2017年 09月 22日

ASP.NET Core 2.0 の Razor Pages を markdown 構文で書く

ASP.NET Core 2.0 から使えるようになった "Razor Pages"

ASP.NET Core 2.0 には、"Razor Pages" と呼ばれる、サーバーサイドレンダリングの Web アプリ実装方法が追加された。

詳しくは下記動画の 0:56:00 あたりからを視聴するとよいかも。

この Razor Pages、いろいろと面白いのだけど、自分的には「ちょこっとだけ動的要素がある Web ページ」を作りたいときに、ただそれだけのために ASP.NET MVC のコントローラーとビューとを作るまでもなく、"Razor Pages" として ~/Pages フォルダに "なんちゃら.cshtml" を置けば済んでしまうところが気に入った。

とくに ASP.NET Core MVC では、Web API 用とMVC用とのコントローラーの区別がなくなっており、Swagger UI で Web API のドキュメントページを自動生成させると、API 目的ではなく動的 Web ページのために設けたコントローラーも含まれてドキュメント自動生成されてしまう面倒があった。
(これを回避するために、Swagger ジェネレータでフィルタリングするコードを自前で書き足していた。)

その点、その動的 Web ページが Razor Pages でシンプルに書いて済ませられるようであれば、この "混信問題" は解消するのが良いと感じた。
(Razor Pages は Swagger ジェネレータの対象にならないので。)

シンプルに .cshtml を書ける? > じゃぁ markdown で!

さてそんなシンプルな使い方もできる Razor Pages なのだが、さらにもっとシンプルに、.cshtml の内容を記述したくなった。

具体的には markdown 記法で書けないか、と考えた。

ということで用意してみたのが、AspNetCore.MarkdownPages だ。

この拙作 NuGet パッケージは、ASP.NET Core の HTTP 要求処理パイプラインに挟んでおくことで、応答ヘッダのコンテンツタイプが "text/markdown" だと、その応答コンテンツを markdown だと見なして HTML に変換してしまう、という "ミドルウェア" だ。

拡張子 .md な静的ファイルを配置しておいて、その .md ファイルを指す URL を開けば、AspNetCore.MarkdownPages が HTML に変換してブラウザに返信してくれる、みたいな使い方をする (下図)。
d0079457_18330322.png
さてこのミドルウェア、繰り返しになるが、静的ファイルに限らずコンテンツタイプが "text/markdwon" である応答ならなんでも HTML に変換する。

のであれば、Razor Pages 上でも markdown 記法で記述して、それを HTML 化してブラウザに返すようにできるはず、と考えた。

実際にやってみた

AspNetCore.MarkdownPages のインストール・導入方法は、GitHub 上のドキュメントに譲るとして、
.cshtml 側の書き方を補足する。

最低限必要なのは、応答のコンテンツタイプを "text/markdown" に変更することだ。
一例としては .cshtml 中の冒頭のコードブロックで下記のように記述する。
@page
@{
Response.ContentType = "text/markdown";
}
もしも _Layout.cshtml などを併用してる場合は、
@page
@{
Layout = null;
Response.ContentType = "text/markdown";
}
というように、共通レイアウトビューも外しておく。

以上で、あとはこの .cshtml 中に
# Header Level 1

```
Current Time is @DateTime.Now
```
とか書くと、ブラウザで表示したときに HTML 化して表示される。
d0079457_18400540.png
"@DateTime.Now" の部分が、ちゃんと C# コードとして評価・実行されてレンダリングされていることもわかる。

オブジェクトの集合を foreach で列挙しての箇条書きはちょっと苦しくて、
(※下記例は、Razor Pages の機能での "ページモデル" に "Items" という List<string> なプロパティが生えている、というシナリオ)
## Properties

@foreach (var item in Model.Items)
{
<text>- @item</text>
}
というようにきれいに書いてはダメで、
## Properties

@foreach (var item in Model.Items)
{<text>- @item
</text>}
というように、
  • foreach ブロック内で "<text>" ブロックを形成しつつ、
  • しかし、余分な空白が行頭に入り込まないようにして、
  • 且つ、1アイテムごとに改行はするように、
という、インデントを潰した、どん詰まりな記述で書く必要がある。
d0079457_18444579.png

しかし利用にはリスクも...

以上、こんな感じで、Razor Pages を markdown 記法で記述することができた。

ただし、IDE/エディタは、.cshtml 内に markdown 記法で記述するとは想定していないはずで、コーディング支援やソース自動整形で難があるかもしれない。

そもそもの Razor ビューエンジンが、まさか markdown 記法でかかれたソースを読み込まされるとはつゆ知らずなわけで、Razor 構文と markdown 構文のはざまでレンダリング時の何か問題があるかもしれない。

また、拡張子 .md のファイルであれば、多くのエディタ/IDE では、HTML に変換後のプレビューを見ながら markdown をコーディングできることだろう。
しかし、おそらく拡張子 .cshtml では markdown プレビューしながらのコーディングは無理だろう。

さらには、現状の AspNetCore.MarkdownPages の機能上の限界であるのだが、実は、ページのタイトルや meta タグを制御することも難しい。
(markdown 記法はそういったメタ情報のことまでは範疇ではない...はず。)

...というように、Razor Pages を markdown 記法で書くのは若干微妙な感じも残る。

なお、ごくごく普通の Razor 構文で記述した .cshtml 中に、markdown 記法での記述を部分的に埋め込める Tag ヘルパーも見かけたような記憶もある。
そういったタグヘルパーライブラリを使ったほうが良いかもしれない。

それでもなお、この AspNetCore.MarkdownPages ミドルウェアと Razor Pages とを組み合わせることで、すっきりしたコーディングができる範疇のプロダクトであれば、これはこれで面白いかも、と思う次第。
 


by developer-adjust | 2017-09-22 21:54 | .NET | Trackback | Comments(0)
2017年 09月 08日

ASP.NET Core 1.1 アプリで、現在の要求が https 接続であるかどうかを判定する方法 - Docker 対応版

ブラウザと https で接続しているのかどうかを判定するには

ASP.NET Core 1.1 アプリにて、現在の要求が https 接続であるか否かを判定するには、要求クラス Microsoft.AspNetCore.Http.HttpRequestIsHttps プロパティを参照するとよい。

このプロパティが true であれば、クライアントとは https でつながっている、ということを示している。

IsHttps プロパティは、例えば ASP.NET Core MVC のアクションメソッド内などであれば、そのコントローラクラスの Request プロパティ経由で参照できる。
public class ProblemController : Controller
{
public ActionResult Index()
{
if (this.Request.IsHttps) {
// クライアントと https でつながっている場合にここに到達
....

このプロパティは Microsoft Azure の Web Apps Service に配置して実行されたときも、適切に true または false を返す。

たとえば foobar というアプリ名で Azure Web Apps 上に配置した場合、IsHttps プロパティは、

  • URL http://foobar.azurewebsites.net/ でアクセスした場合は false
  • URL https://foobar.azurewebsites.net/ でアクセスした場合は true

となる。

Docker コンテナ内では...?

ところが、である。

同じ ASP.NET Core 1.1 アプリを Docker イメージにパッケージし、この Docker イメージを Azure Web Apps on Linux や Heroku の Docker コンテナ機能で稼働させると、

  • Azure なら https://foobar.azurewebsites.net/
  • Heroku なら https://foobar.heroku.com/

の https スキーマの URL でアクセスしても、その要求を受け取った ASP.NET Core アプリ内では、IsHttps プロパティは常に false となってしまうのだ。

まぁたしかに、Docker コンテナ内では ASP.NET Core アプリは、ポート 80 番で TLS 暗号化されていない素の http 通信で動いてるに過ぎない。
そのいっぽうで外界とは https で通信できてるのは、ポートフォワーディングやロードバランサ、リバースプロクシといった、クラウドサービス側のインフラによって実現されてるからである。

そうである以上、Docker コンテナ内に棲息している ASP.NET Core アプリの立場としては、"クライアント" というのはそれらエッジ側に配置されたサービスのことであり、「え、クライアントとは暗号化通信なんかしてないんですけど?」といって IsHttps プロパティが false になるのも理解できる。

※Azure Web Apps も、実のところ ARR などがエッジ側にあるはずなのだが、そのあたりはうまく連携されているようだ。そのおかげで最終的に外界と HTTPS でつながっているのか否かをアプリ上で正しく判定できるっぽい。

とはいえ、このままでは「で、最終的にブラウザとは https でつながってるの? どうなの?」ということを ASP.NET Core アプリ内で判定したい場合、困ったことになる。

X-Forwarded-Proto

そこで参照するとよいのが X-Forwarded-Proto サーバー環境変数である。

Azue Web App on Linux ないしは Heroku の Docket コンテナにおいて、ユーザーエージェントとはどんなプロトコル (http なのか https なのか) で接続しているのかを、この環境変数に設定してくれるのだ。

ASP.NET Core アプリ上は、この X-Forwarded-Proto サーバー環境変数は、要求ヘッダとして参照できる。

そこで、

  1. 要求ヘッダ X-Forwarded-Proto の値の取得を試みる。このヘッダが要求に含まれていればその値をスキーマとして参照する。
  2. もし X-Forwarded-Proto ヘッダが要求に含まれていなければ、現在の要求のスキーマを参照する。

という手順でスキーマ参照し、スキーマが "https" か否かで判定ができる。


具体的なコードとしてはこんな感じ。
(実際にはコントローラクラス/アクションメソッドにこんな風に直書きせず、何かミドルウェアとか実装して、そこで https でなかったら要求を HTTP 403 で拒否するとか https な URL にリダイレクトするとかやるのだろうけれど、とりあえずサンプルコードなので)。
public class ProblemController : Controller
{
public ActionResult Index()
{
var scheme = this.Request.Headers.TryGetValue("X-Forwarded-Proto", out var value) ?
value.ToString() :
this.Request.Scheme;
if (scheme == "https") {
// クライアントと https でつながっている場合にここに到達
....

このコードはもちろん、Azure Web Apps 上に配置した場合も正しく機能する。

これで、Docker コンテナ内で稼働する ASP.NET Core アプリであっても、ユーザーエージェントと https でつながってるのかどうかを判定できるようになった。
 

by developer-adjust | 2017-09-08 23:04 | .NET | Trackback | Comments(0)