@jsakamoto

(.NET Core ではないクラシカルな) ASP.NET Web アプリ開発と、Azure Web App への配置における、データベース接続文字列をどこにどう設定するのか、の話題。

本投稿では、SQL Server データベースに接続して、何かしらデータベースに読み書きする ASP.NET Web アプリを想定している。

そしてデータベースアクセスライブラリには Entity Framework を用い、Code Fist スタイルで実装するものとする。

まずはおさらいから。

開発環境では...

開発環境、およびバージョン管理システムにコミットされる内容としては、web.config の connectionStrings セクションに、SQL Server LocalDB によってプロジェクトフォルダ以下にデータベースファイルができあがるように、データベース接続文字列をインラインで記述する。
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<connectionStrings>
<add
name="MyDB"
connectionString="Server=(LocalDB)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|MyDB.mdf;Integrated Security=True;Connect Timeout=30"
providerName="System.Data.SqlClient"/>
</connectionStrings>
...
</configuration>

このコード・構成ファイルをバージョン管理システムにコミットしておくことで、このリポジトリを clone (あるいはチェックアウト) した他のメンバーも、ビルドして実行するだけで、データベースも新規構築されてその ASP.NET Web アプリを動かすことができる。

もっとも、最低限、いずれのメンバーの開発環境にも、同じバージョンの SQL Server LocalDB が事前にインストール済みである必要はある。
とはいえ、そもそも ASP.NET Web アプリ開発のために Visual Studio が必要という程度には各メンバーの開発環境をそろえる手間をかけているはず。
なので、さらに SQL Server LocalDB についても環境をそろえることは大したコスト、問題にはならないと思う。

実行環境では...

さてこうして開発した ASP.NET Web アプリを、Azure Web App として配置するとしよう。

上記手順で開発したとすれば、接続先データベースに LocalDB が指定された web.config が配置されることになる。

しかし当然のことながら、一般的(?)なケースであれば、実行環境用のデータベースは LocalDB ではなく Azure 上の SQL Database サービスなどを別途用意済みで、そちらに接続するようにしたいはずだ。

このような目的で、Azure Web App のアプリケーション構成の中に、データベース接続文字列をポータル上から指定できるようになっている。

web.config の connectionStrings セクションと、この Azure のポータル設定とで同じ名前のエントリがあると、Azure のポータルで設定したデータベース接続文字列のほうが優先して採用されるのだ。

この仕掛けにより、
本番環境用のデータベース接続文字列をバージョン管理システムにコミットすることなく、
またいっぽうで開発者はソースコードリポジトリからプロジェクト一式を取り出したらすぐにローカル環境で実行できる

体制とすることができる。

開発環境側で、異なるデータベース接続がしたい!

...と、ここまではおさらい。
それなりに ASP.NET Web アプリ開発や Azure への配置を手掛けている経験があれば、ここまでの内容は半ば "常識" かもしれない。

さて、以上の仕組み・体制で大抵の場合は問題ない。
しかし稀ではあるものの、開発環境においてデータベース接続文字列を変更したい需要がある。

いくつかの面倒なシナリオがあるのだが、わかりやすい例としては、開発環境にインストールされている SQL Server LocalDB のバージョンが合っていなかった、という例が挙げられる。

久々に古いプロダクトのコードを開いて実行してみたら、開発機を入れ替える前のコードで、現在の開発機にはそのプロダクトが指している古いバージョンの SQL Server LocalDB がインストールされていなかった、とかである。

LocalDB 2014を使っている場合、接続文字列はData Source=(LocalDb)\v11.0 じゃないし v12.0 でもないし ProjectsV12 でもなく、正解はData Source=(LocalDb)\MSSQLLocalDB でした。お疲れ様でした。— ちきさん (@ovrmrw) April 1, 2015

まぁ普通に考えると、指定のバージョンの SQL Server LocalDB をインストールすればよいのだろう。
しかしながら、いろんなバージョンの SQL Server LocaDB が開発機にインストールされるのは (しかもそのようなレアなプロダクトの保守のためだけに)、気持ち悪いかもしれない。

そんなことから指定バージョンの SQL Server LocalDB のインストールを嫌って、web.config にインラインで記載されているデータベース接続文字列を、自身の開発機にインストールされている SQL Server LocalDB バージョンに合わせて書き換えてしまい、これをコミットしてしまうと、あまり致命的ではないとはいえ (どうせ Azure に配置するときにはポータルで設定された接続文字列が使われるので問題ない)、開発メンバー間で面倒なことになりかねない。

「あいつのコミットをマージしたら、自分の環境で動かなくなったー！」みたいに、である。

ということで、最近編み出した手法を紹介する。

解決方法まず、データベース接続文字列は、web.config にインラインで記述せず、web.config 中からは (例えば) "connectionStrings.config" という、もうひとつ外部の構成ファイルを参照するように変更する。
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<connectionStrings configSource="connectionStrings.config" />
...
</configuration>
いっぽうで、バージョン管理システムには、ファイル "connectionStrings.config" がバージョン管理下に含まれないようにしておく。
git であれば .gitignore に "connectionStrings.config" の1行を加筆しておくことになるだろう。

さてこれだけだと、新たにバージョン管理リポジトリからプロジェクト一式を clone しても、"connectionStrings.config" がないので、ビルドや実行時エラーになってしまう。

そこで、ビルドイベントの「ビルド前に実行」されるバッチスクリプトとして、
「もし "connectionStrings.config" がプロジェクトフォルダに存在しなければ、既定の内容で生成」
というバッチスクリプトをプロジェクトファイルに組み込んでおくのだ (下記例)。

set configPath= "$(ProjectDir)connectionStrings.config"
if exist %configPath% goto SKIP
echo ^<?xml version="1.0" encoding="utf-8" ?^> > %configPath%
echo ^<connectionStrings^> >> %configPath%
echo ^<add name="MyDB" connectionString="Server=(LocalDB)\MSSQLLocalDB;AttachDbFilename=|DataDirectory|MyDB.mdf;Integrated Security=True;Connect Timeout=30" providerName="System.Data.SqlClient"/^> >> %configPath%
echo ^</connectionStrings^> >> %configPath%
:SKIP
※上記例以外にも、別途既定の構成の "connectionStrings.config" ファイルをバージョン管理下にはあるがプロジェクトフォルダの外に「テンプレート」として配置しておき、プロジェクトフォルダになければコピー、といった仕組みとすることもできるだろう。

あとは、"connectionStrings.config" をプロジェクトに含め発行対象となるようにしておけばよい。

こうしておくことで、
開発者はこれまでどおり、プロジェクト一式をバージョン管理リポジトリから clone した直後、そのままビルド、実行してもちゃんとアプリを動かすことができるいっぽう、
データベース接続文字列を記述している "connectionStrings.config" はバージョン管理下にないので、安心して自分の好きなように接続先データベースを書き換えて実行

といったことができる。

まとめ

ここで紹介したやり方は、実のところ、あまり美しいやり方とは言えないと思う。

実際、もしも Azure Web App への配置が CI/CD の仕組みではなく手動による配置だと、配置を行うメンバーが "connectionStrings.config" を既定とは違う内容に書き換えていたら、それが Azure 上に配置されてしまうという気持ち悪さもある。
(どのみち、ポータルで設定されたデータベース接続文字列に上書きされて動作するはずなので、実害はないはずだが)

とはいえ、本記事で取り上げたような需要 ― 既定のデータベース接続文字列を開発者間で共有しつつ、自分独自のデータベース接続文字列に書き換えたいときがある ― を、とにかくは満たしてはいる。

広く勧める技法ではないが、同じような需要に迫られてお困りの方の一助になれば幸いである。
よりクールでスマートなやり方・運用があればご教示いただければ嬉しい限り。

最後に補足として、ASP.NET Core ではアプリケーション構成の仕組みが変わっているので本記事は参考にならないと思うので悪しからず。

表題の件、毎回やり方を忘れてはネット検索しているので、自分用にメモ。

なお、ASP.NET Core ではなく、従来からの ASP.NET における話題。
まずは結論からASP.NET Web API コントローラにてバイナリコンテンツを返すには、API コントローラのアクションメソッドについて、以下のようなコードを書けばよい。
アクションメソッドの戻り値は HttpResponseMessage 型とする。
返したいバイナリコンテンツを ByteArrayContent でラップする。
さらに、適宜、コンテンツタイプを ByteArrayContent オブジェクトに設定する。
Request オブジェクトの CreateResponse メソッドで、応答オブジェクトを作る。
この応答オブジェクトに、返したいコンテンツをラップした ByteArrayContent オブジェクトを設定する。
こうして作成した応答オブジェクトを、アクションメソッドの戻り値として返す。

public class FooController : System.Web.ApiController
{
// HTTP GET /api/Foo
public HttpResponseMessage Get()
{
...
var bytes = new byte[] { /* バイナリコンテンツのバイト列 */ };
var content = new ByteArrayContent(bytes);
content.Headers.ContentType =
MediaTypeHeaderValue.Parse("application/octet-stream");
var res = this.Request.CreateResponse();
res.Content = content;
return res;
}
}
うまくいかない例ちなみに下記コードでは期待した動作とならない。
public class FooController : System.Web.ApiController
{
// HTTP GET /api/Foo
public byte[] Get()
{
...
var bytes = new byte[] { /* バイナリコンテンツのバイト列 */ };
return bytes;
}
}
上記コードだと、返したいバイナリコンテンツのバイト列が、JSON (ないしは XML) 形式で返されてしまうからである。

もちろん、たいていの場合、ASP.NET Web API コントローラの仕組みとしては、任意の型の戻り値が JSON (or XML) で返却されるのはうれしい仕様である。
しかし、今回のようにバイナリコンテンツを返したい場合には融通が利かず、先に書いたとおりの実装を記述しなければならないようだ。
もっとうまい方法がありますか？それにしても、たかだかバイナリコンテンツを返すだけなのに記述量がちょっと多い気がする。
もしかしてもっとスマートに実装できるのだろうか?

個人的には下記の妄想例のように、アクションメソッドに属性指定することで、バイナリコンテンツを返すことができたらいいのにな、とか思ってしまった。
public class FooController : System.Web.ApiController
{
// HTTP GET /api/Foo
// ※こんな属性や仕組みはないのだけれど、
// 　こんな風に書けたらいいな！という妄想
// 　(まさか、もしかして既にあったりする?)
[ByteArrayContent("application/octet-stream")]
public byte[] Get()
{
...
var bytes = new byte[] { /* バイナリコンテンツのバイト列 */ };
return bytes;
}
}
そもそも API コントローラでバイナリコンテンツを返す？ところで、そもそも API コントローラでバイナリコンテンツを返す需要があるのか、はたまた、API コントローラからはバイナリコンテンツを返すべきではないのでは、といった議論もあろうかと思う。

まず需要についてだが、昨今の SPA (Single Page Application) 実装におけるクライアント側からサーバー側 API の呼び出しにおいて「チケットの QR コード画像を動的生成して返したい」であるとか、「現在ログインユーザーのプロフィール画像を返したい」など需要はあるように思う。
MVC コントローラから返すなら容易だけれども...そうしたときに、ASP.NET MVC コントローラであれば、File 拡張メソッドで容易にバイナリコンテンツを返すことができる。
よって、Web API コントローラでの実装にこだわらずに、MVC コントローラで実装すればいいのかもしれない。

しかし昨今の SPA 実装だと、サーバー側実装は MVC コントローラは無くて、Web API コントローラだけ、ということも多い。
そんな背景下、バイナリコンテンツを返すためだけに MVC コントローラを追加実装するのもどうかと思う次第。
CDN とか使うのでは?また、それなりのアクセス数・負荷が見込まれるような Web アプリ・サイトの場合、そのようなバイナリコンテンツはこれらコントローラ類で処理していると性能が追い付かないであろう。
このようなケースでは、CDN にそのようなバイナリコンテンツを配信しておいて処理を移譲する、といったような策を打つべきだろう。

とはいえ、中小社内向けや B2B でユーザー数が限定されているよううな場合は、CDN をはじめあまり連携サービスを増やさずに Web アプリ本体だけで完結していることも、サーバーへの配置などの取り扱いが簡潔になるので、それはそれで価値があると思う。
最後に - ASP.NET Core では未確認なお、ASP.NET Core では、バイナリコンテンツの返し方がどうなるか未確認なので悪しからず。

前回の投稿で、ASP.NET Web API (.NET Core ではなく) において、バイナリコンテンツを返すにはどう実装するのかについてまとめた。

たかだかバイナリコンテンツを返すだけなのに、決して少ないとは言えない量のコードを記述する必要があることがわかり、もやっとする印象であった。
ASP.NET Core での実装はどうなる？さてところで、ASP.NET Core における Web API からバイナリコンテンツを返す場合はどうなるか。

ASP.NET Core からは、ASP.NET MVC と ASP.NET Web API は、その実装が統一化された。

旧来の ASP.NET では、MVC のコントローラクラス (System.Web.Mvc.Controller) と、Web API のコントローラクラス (System.Web.Http.ApiController) とは別物であった。
しかし ASP.NET Core MVC からは両者は統一され、MVC コントローラと API コントローラで区別がなくなり、いずれも同じ Microsoft.AspNetCore.Mvc.Controller クラスからの派生となる。

その結果、バイナリコンテンツの返し方は、旧来の ASP.NET MVC と同じ、File() メソッド呼び出しを返すだけでよくなった！
[Rout("api")]
public class MyController : Controller
{
// 戻り値は IActionResult とする。
[HttpGet, Route("picture")]
public IActionResult Get()
{
// MVC/Web API の区別なく、File メソッド使うだけで
// 容易にバイナリコンテンツを返すことができる!
var bytes = new byte[] { /* バイナリコンテンツのバイト列 */ };
return this.File(bytes, "application/octet-stream");
}

// もちろん従来どおり、任意の型の戻り値を返すことができ、
// ブラウザには JSON に書式化して届く。
// HTTP GET /api/values => [1, 2, 3]
[HttpGet, Route("values")]
public int[] GetValues()
{
return new []{ 1, 2, 3 };
}
}

まとめASP.NET Core ならとてもシンプルである。

これならはじめから ASP.NET Core で実装しておけばよかったと反省である。
　

自 PC のグローバル IP を知るのに inet-ip.info を使ってたが...以前、こんな記事を投稿した。

Azure CLI 2.0 ("az" コマンド) を使って Azure SQL Database のファイヤーウォールを開閉する

http://devadjust.exblog.jp/23804079/

この記事の中で、「補足: 自 PC からのアクセスでのグローバル IP を知るには?」ということで、http://inet-ip.info の利用を紹介していた。
最近、inet-ip.info 落ちてる?しかしながら、ここ数日、http://inet-ip.info がたまーに落ちてることがあった。
https://t.co/2p2r8mmMZi が落ちてしまってるようだけど、heroku で動いてたのね。 pic.twitter.com/HD6Xp2W0jS— jsakamoto (@jsakamoto) July 26, 2017ほどなく復活はするのだが、自分は運が悪いのか、ここ最近は立て続けに利用不能の憂き目に逢っている。
どうやら Heroku 上に立てられているようなのだが、利用量の制約にでも触れてしまっているのだろうか。

それはさておき、まぁ、HTTP 要求に対し、要求もとのリモートアドレスを応答に返すような Web アプリの作成なんぞ大した手間ではない。
ということで、他人様がたててくれた Web アプリだけに頼るのではなく、ささっと自分専用の「お前の IP アドレスを echo する」Web アプリを作って立てることにした。

とはいえ、たかだか「お前の IP アドレスを echo する」のためだけなので、
Web アプリすら大仰
である。

ということで、Microsoft Azure の機能のひとつ、「Azure Function Apps」として構築することにした。
「お前の IP アドレスを echo する」Azure Function App今回はプログラミング言語としては JavaScript を採用。

ということで、言語 = JavaScript で、HTTP Trigger な Function を1つ作り、下記内容で実装すれば完了である。
// index.js
module.exports = function (context, req) {
var remoteAddress = req.headers['x-forwarded-for'];
context.res = {body: remoteAddress.split(':').shift()};
context.done();
};
あとは、この Function を起動する URL に、HTTP GET 要求でも送れば、応答コンテンツに、アクセス元 = 自身の IP アドレスが echo されて返ってくる次第。

以下、Azure Portal での操作手順の説明となるが、もう少し詳しく手順を説明してみよう。
手順をもうすこし詳細に説明してみるまずは Web ブラウザで Azure Portal サイトを開いてサインイン。
続けて、「New (追加)」から「Compute」>「Function App」とカテゴリをたどる。
最低限、アプリ名を指定し（アプリ名は URL の一部というか先頭部分となる）、適宜、ホスティングされる場所を選んで「Create」をクリック。

これでしばらくすると新規 Function App の枠ができあがる。
続けてこの枠の中に個別の Function を作っいく（今回は IP アドレスを echo する Function x 1つだけだが）。
Azure Portal 上で今作った Function App のブレードを開き、下図のように Functions の追加ボタンをクリック。するとどのような Function を追加するのかの画面になる。
この画面では、よく使われるシナリオ用の Function をさくっと追加できるようになっているのだが、あいにくと HTTP トリガーが選択肢にない。
そこで、「create your own custom function」をクリック。

これで、細かく選べる画面になる。
「Language (プログラミング言語)」は「JavaScript」を選択、シナリオは「HttpTrigger」を選択して、最後に Function の名前（これが URL パスの末尾になる）を決めて入力、「Create」をクリックする。

これで、HTTP 要求によって起動される Function がひとつできあがる。
実装内容を下図のように、今回案件の「お前の IP アドレスを echo する」内容に書き換えて「Save」をクリックして保存。

これで完成である。
あとは、この Function を起動する URL が画面右上のリンクから知らされるので、この URL を手に入れておく。

ちなみに、ここまで、既定の設定で作ってきたので、この Function は、いわゆる "パスワード" というか、API キーによる認証必須となっている。
つまり、API キーを添えて HTTP 要求を送らないと、Azure Function App のインフラストラクチャによって「401 Not Authorized」エラーになる。
なお、上図で見えている当該 Function を起動する URL には、クエリ文字列として、その API キーが込みで掲載されている。なので、この URL で HTTP 要求を送れば...

ご覧のとおり、ちゃんとアクセス元のグローバル IP アドレスが応答として返ってくる。上図は PowerShell で Invoke-RestMethod による実行例だが、もちろん curl でも同じだ。

ちなみに API キーの指定方法だが、上記のように URL 中のクエリ文字列で "code=..." に指定するほか、HTTP 要求ヘッダに「x-functions-key」を追加してそこに API キーを指定してもよい。
下記など参照されたし。Azure Functions の API Key を扱ってみる
http://tech.guitarrapc.com/entry/2016/04/22/042331

まとめ以上、Azure Function App を使えば、「お前の IP アドレスを echo する」程度の Web アプリは、さくっと立てられる。
なお、Azure Function の料金については下記を参照されたし。
ベースの無料枠もあるので、但しストレージの使用料金はかかるのだがそれもたかがしれていると思うのでかなり廉価に運営できると思われる。

Application Insights の試用を始めた実はこれまでのところ、Web アプリの各種モニタリングには Application Insights は使っていなかったのだが、思うところあって、Application Insights の利用を始めることにした。

Application Insights の適用できるプラットフォームは多岐に渡る。
今回は Web ページの監視、クライアント側スクリプトにおける Application Insights の試用を開始した。

実装ガイドに従って手続きを進め、下記のような JavaScript コードをページに埋め込んだ。
<script type="text/javascript">
var appInsights = window.appInsights || function(config){
... 省略 ...
}({
instrumentationKey: "a79dec8d...c3a427"
});
window.appInsights = appInsights;
appInsights.trackPageView();
</script>
これで、JavaScript コード上で捕捉されなかった例外が Application Insights サービスにインターネット経由で送信され、Visual Studio 上や、Web ブラウザからの Azure ポータルサイト上で確認することができるようになる。

試用を始めて早速に、捕捉されないクライアントスクリプト例外が発生。

それではと、Azure ポータルで発生した例外のログを確認してみた。

なるほどなるほど、例外のメッセージはもちろん、スタックトレースも当然のごとく閲覧可能。

...と、見ているうちに気が付いた。

例外発生時のページ URL はどこ?

ページ URL の記載がない?このクライアントスクリプト例外が発生したときの、ページ URL がわからない。

「http://host/#/foo/edit/123」みたいに URL がわかれば、「foo の ID = 123 を編集中に、この例外が発生したんだな！」と、現象の再現に大変役立つ。
しかしその URL がわからないとなると、かなりきつい。

"url" という項目はあるにはある。
しかしこれは例外発生個所の JavaScript ファイルの URL だった。
そういう URL は無用である (スタックトレースみればわかるし)。

何か見落としているのかもしれないが、現時点でもなお、にクライアント側スクリプト例外の発生時のページ URL の記録は見つけられていない。
いちおう、ブラウザの開発者ツールで、Application Insights への送信内容も傍受して内容の JSON を見てみたが、そこにもページ URL らしきものは、自分には見つけられなかった。
自前で配線致し方ないので、捕捉されなかったクライアントスクリプト例外の記録を、Application Insights の既定のスクリプトに任せるのをやめ (下記)、
<script type="text/javascript">
var appInsights = window.appInsights || function(config){
... 省略 ...
}({
instrumentationKey:"a79dec8d...c3a427",
disableExceptionTracking: true // このオプション指定を追加
});
代わりに自前で、捕捉されなかった例外の Application Insights への送信を実装し、そこで window.location.href も盛り込むようにした。
window.onerror = function (msg, file, line, column, err) {
appInsights.trackException(err, null, {
url: file,
pageUrl: window.location.href
});
};
</script>
これで Azure ポータル上での例外ログを閲覧したときに、例外発生時の URL もわかるようになった。

でも本当にこれでいいの?...という感じで、とりあえずは自己解決したのだけれど、今になって落ち着いて考えるに、皆さん、クライアントスクリプト例外の記録に、例外発生時のページの URL が併記されてないまま Application Insights を利用されているのだろうか??

それとも自分が何か壮大な勘違い・間違いを犯しているのではないだろうか?

もし何か情報があればコメントや Twitter 上のツイートなどで教えていただけると大変ありがたい。
　

Visual Studio 2017 による Docker サポートVisual Studio 2017 では、ASP.NET Core 1.1 Web アプリを開発する際、Docker イメージを生成するよう構成することができる。

新規プロジェクト作成時に、プロジェクト作成のダイアログで Docker サポートの追加を選択するか、

あるいは既存の ASP.NET Core プロジェクトをソリューションエクスプローラ内からの右クリックで Docker サポートの追加を行うことができる。

Docker サポートが追加されると、ソリューションの下に、主体である ASP.NET Core プロジェクトとは別に、Docker Compose のプロジェクト (.dcproj ファイル) が追加される。

Docker Compose のノードをスタートアッププロジェクトに指定して F5 実行すれば、IIS Express や dotnet コマンド実行ではなく、Docker イメージの作成とそのイメージからの Docker コンテナの開始でアプリが実行される。

もちろん Visual Studio 上でいつもと変わらずデバッグも可能だ。

作成される Docker イメージにはプロジェクト名の名前空間 + dev のタグ名が付く。
> docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
chomadproblemserver dev d6b1f650bd7d 1 hours ago 320MB

ただしこの dev タグ付きの Docker イメージは、単純に docker run しても、下記のようなメッセージを吐くだけで実行できなかった。
> docker run -p 32767:80 d6b1f650bd7d
Did you mean to run dotnet SDK commands? Please install dotnet SDK from:
http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
たぶん、Visual Studio から起動されるときは、何かしらの追加のオプションが指定されて実行されているのだろう (詳しくは調べていない)。

Release モードにして Docker Compose プロジェクトをビルドを実行すれば、単純な docker run でちゃんと稼働する Docker イメージが作成される。

Release モードで作成される Docker イメージには、プロジェクト名の名前空間 + latest のタグ名が付く。
> docker images
REPOSITORY TAG IMAGE ID CREATED SIZE
chomadproblemserver latest f650bd7dd6b1 a seconds ago 320MB
chomadproblemserver dev d6b1f650bd7d 1 hours ago 320MB

ところで、Visual Studio 2017 のプロジェクトテンプレートから作成した ASP.NET Core アプリのコーディングだと、環境変数 ASPNETCORE_URLS で指定したポート・URL でリッスンするようにできている。

それを踏まえつつ、"docker inspect {イメージID}" で件の Docker イメージの設定内容を確認してみると、環境変数 ASPNETCORE_URLS に「http://+:80」の設定が施されていて、それで TCP ポート 80 でリッスンするのだな、ということがわかる。
(どうやらこの環境変数設定は、元となっている「microsoft/aspnetcore:1.1」イメージにて設定が盛り込まれているようだ)

以上のことから、このイメージ内で稼働する ASP.NET Core アプリは、docker run での開始時にとくに指定がなければ、TCP ポート 80 でリッスンしている。

そこで、docker run 時に、-p オプションでポートフォワーディング指定をすることで、指定のポート番号経由でブラウザからアクセスが可能となる。
> docker run -p 32768:80 chomadproblemserver:latestこの Docker イメージは、このように手元のローカルの Docker 環境だけでなく、Microsoft Azure の Web Apps on Linux に配置しても稼働する。
Docker Hub にこの Docker イメージを push してそれを Azure の Web Apps on Linux に配置することも可能だ。

ちなみに、この Docker イメージを Docker Hub に公開するには、docker tag コマンドを使って Docker Hub の自分のアカウントの名前空間で別名を付与し、これを docker push すればよい。

> docker tag chomadproblemserver:latest jsakamoto/chomad-problem-server:latest
> docker push jsakamoto/chomad-problem-server:latest

...以上の話題は、今年 2017 年に開催されたマイクロソフトの開発者向けイベント「de:code 2017」の TL04 セッション「.NET 15 周年の今こそ考えるクラウドネイティブアプリケーションと .NET の活用」の動画でも知ることができる。

Heroku の Docker コンテナサポートさて話は変わって、PaaS の老舗(?)、Heroku での話。

Heroku も時流に遅れることなく、Docker イメージを push して稼働させることが可能だ。

Heroku 上には registry.heroku.com という Docker リポジトリが用意されている。
このリポジトリに、Heroku 上のアプリ名の名前空間 + /web という名前空間で Docker イメージを push すれば、それで Docker コンテナが開始される。

Heroku CLI がインストール済みの環境であれば、下記要領となる。

まずは準備。
いちど済ませてあれば毎回行う必要はない。
# 念のため、事前に heroku CLI を最新版にしておく
$ heroku update

# 事前に、Heroku サービスにログインしておく。
$ heroku login

# さらに事前に Heroku の Docker リポジトリサービスにログインしておく。
$ heroku container:login
次に、Heroku 上にアプリ枠を作る。
アプリ名が "foobar" だとすると、こんな感じ。
$ heroku apps:create foobar
もちろん、このアプリ作成の手順は、heroku.com の Web コンソールから作っても構わない。

あとは、この foobar アプリとして配置したい Docker イメージに、Heroku の Docker リポジトリを指す、アプリ名 + /web を名前空間とした別名を付与して、push するだけだ。
$ docker tag {配置したい Docker イメージのID} registry.heroku.com/foobar/web
$ docker push registry.heroku.com/foobar/web
これで、docker push が完了すると、Heroku 上でこのイメージから Docker コンテナが自動で開始される。
"heroku open -a foobar" を実行すれば、手軽に当該アプリをデフォルトブラウザで開いてくれもする。

しかし VS2017 で生成したイメージでは Heroku で動かないところがところが、Visual Studio 2017 の機能で生成した ASP.NET Core アプリの Docker イメージは、この方法では Heroku 上に配置しても以下のようにエラーとなって稼働してくれない。
> docker push registry.heroku.com/chomado-problem-server/web
The push refers to a repository [registry.heroku.com/chomado-problem-server/web]
d678574e5668: Pushed
2783887ca397: Pushed
...(中略)...
unsupported: Your Docker image must specify a `CMD` instruction.
どういうことかというと、Heroku による Docker コンテナサポートには、以下の2つの制約がある。
CMD 指定が必須
環境変数 $PORT で指定される TCP ポート番号でリッスンする必要がある

先のエラーは、メッセージからも読み取れるとおり、上記制約のうち最初のひとつめ (CMD 指定が必要) に抵触したことによるものだ。

これを踏まえつつ、Visual Studio 2017 の機能で生成された Docker イメージを見てみると次のとおりとなっている。
CMD 指定は使わず、ENTRY 指定を使用
リッスンするポート番号は、基本、80 番固定。(docker run 時に環境変数 ASPNETCORE_URLS を上書き設定すれば任意のポート番号でリッスンさせることはできる)

そこで、Visual Studio 2017 の機能で生成された Dockerfile を以下のように書き換えてビルドし直し・Docker イメージを作成しなおしすればよい。
ENTRY 指定をやめ、CMD での指定
ただし、単純に dotnet コマンドを起動する CMD ではなく、環境変数 $PORT を環境変数 $ASPNETCORE_URLS に反映させてから dotnet コマンドを実行するシェルスクリプトを記述する
なお、Heroku 以外の環境では、$PORT 環境変数は与えられないので、環境変数 $PORT の既定値 (80) を設定しておく

以上を反映した Dockerfile は下記となる。({ASP.NET Core プロジェクト出力 .dll 名} の部分は実際の名前に置き換わる)
FROM microsoft/aspnetcore:1.1
ARG source
WORKDIR /app
EXPOSE 80
COPY ${source:-obj/Docker/publish} .
# "ENTRYPOINT～" の行を削除し、代わりに下記2行を追加。
ENV PORT 80
CMD ASPNETCORE_URLS=http://*:$PORT dotnet {ASP.NET Core プロジェクト出力 .dll 名}
この Dockerfile に基づいて生成された Docker イメージであれば、Heroku に配置・稼働させることができるようになる。

もちろんこの変更を加えても、ローカルでの実行や、Visual Studio からのデバッグ、Azure Web Apps on Linux への配置など、これまでと同じ要領で変わらず実行可能だ。

補足・Dockerfile の変更・イメージの再作成ができない場合例えば他の人が作成・公開したような既存の ASP.NET Core アプリの Docker イメージで、且つ、前述のような対 Heroku 問題を抱えているイメージを、Heroku の Docker コンテナに配置したい場合はどうするか。

その Docker イメージの "再作成" は手が届かないとしても、ENTRYPOINT 指定を "上書き" した、レイヤーを重ねた新 Docker イメージを作成することで実現可能だ。

具体的には、以下のような Dockerfile を作り、
FROM {イメージ名}

# 元のイメージの ENTRYPOINT 指定を null 値で書き潰す
ENTRYPOINT

# 代わりに下記2行を追加。
ENV PORT 80
CMD ASPNETCORE_URLS=http://*:$PORT dotnet {元の ENTRYPOINT 指定と同じ.dllファイル名}
その Dockerfile があるフォルダで以下のように Docker イメージのビルドを行えばよい。
$ docker -t registry.heroku.com/{Heroku上に配置するアプリ名}/web ./
こうして作成した Docker イメージなら、docker push して Heroku 上に配置しても、期待どおり動作してくれるようになる。

以上!

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

このプロパティが 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 サーバー環境変数は、要求ヘッダとして参照できる。

そこで、

という手順でスキーマ参照し、スキーマが "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 でつながってるのかどうかを判定できるようになった。
　

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 に変換してブラウザに返信してくれる、みたいな使い方をする (下図)。

さてこのミドルウェア、繰り返しになるが、静的ファイルに限らずコンテンツタイプが "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 化して表示される。

"@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アイテムごとに改行はするように、

という、インデントを潰した、どん詰まりな記述で書く必要がある。

しかし利用にはリスクも...以上、こんな感じで、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 とを組み合わせることで、すっきりしたコーディングができる範疇のプロダクトであれば、これはこれで面白いかも、と思う次第。
　

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 コンテキストを入手可能だ。
　

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 の LogicFlow サービスを使ったりしてメール送信を実装したほうがよさげなので 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 エンコーディングのオブジェクトを見てみると、下図のとおり。

ご覧のとおり、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 オブジェクトが返されるようにするには、もうひと手間必要だ。
言い換えると、もうひと手間必要ではあるが、しかしとにかく実装可能ではある。

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

以前の投稿で、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 を走査・列挙して実行するようにした（但し、事前にいちど、プロジェクトをビルドしておく必要がある）。

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

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

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

こんなシナリオである。

プロジェクトの新規作成テンプレートで、SPA ではない種類のテンプレートを選んでプロジェクト作成し、開発に着手。

そしてその後で、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 ファイルができあがっているではないか。

どうやら 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 上でビルドを実行してみた。

結果、上記処置で余計な TypeScript コンパイルは実行されなくなった。

解決！
　

前提jQuery を使用した Web アプリクライアント側実装における話。

自前のコードは TypeScript で記述し、これをモジュールバンドラーである webpack を使用して、JavScript へのトランスパイルからモジュールバンドルまで実施する構成である。

プロジェクト立ち上げの様子はこうだ。

まず npm (yarn でも可) でプロジェクトを初期化。
> npm init -f -y続けて必要な Node パッケージをインストールする。> npm install --save-dev webpack typescript ts-loader jquery @types/jquerypackage.json はこんな感じ。{
"name": "sample-webapp",
"version": "1.0.0",
"scripts": {
"build": "webpack",
"watch": "webpack -w"
},
"devDependencies": {
"@types/jquery": "^3.2.17",
"jquery": "^3.2.1",
"ts-loader": "^3.2.0",
"typescript": "^2.6.2",
"webpack": "^3.10.0"
}
}次に、TypeScript コンパイラを使用して、既定の tsconfig.json も作成しておく。>.\node_modules\.bin\tsc --initwebpack.cconfig.js も下記のとおり記述する。// webpack.config.js
module.exports = {
entry: ['./src/app.ts'],
output: {
filename: './wwwroot/js/bundle.js'
},
resolve: { extensions: ['.js', '.ts'] },
module: {
loaders: [
{
test: /\.ts$/, use: [
{ loader: 'ts-loader' }
]
}
]
},
devtool: 'source-map'
};そして、アプリケーションコードとなる ./src/app.ts を作成。// ./src/app.ts
import * as $ from 'jqeury';

$(() => {
let randomNum = Math.round(100 * Math.random());
$('#p1').text(randomNum);
});以上で、「npm run build」を実行すれば、app.ts が JavScript に変換されつつ、jQuery の JavaScript コードをモジュールバンドルした、"./wwwroot/js/bundle.js" ができあがる。

この bundle.js を HTML コンテンツ中から script タグで参照・読み込むよう記述するわけだ。
(例えば下記 ./wwwroot/index.html のように。)<html>
<body>
<p id="p1"></p>
<p id="p2"></p>
<script src="/js/bundle.js"></script>
</body>
</html>命題さてここで、下記のような実装がされた、クラシカルな jQuery 拡張ライブラリ ( 架空の例として ./wwwroot/js/jquery.fizzbuzz.js ) を使う必要に迫られたとする。// ./wwwroot/js/jquery.fizzbuzz.js
(function($) {
$.fn.fizbuzz = function(n) {
...
}
})(jQuery);先に述べた構成・開発環境において、どうやってこの古典的な jQuery 拡張を使用するのか、というのが本稿の命題だ。
まずは externals 化このクラシック実装な jQuery 拡張は、上記のとおり、JavaScript のモジュール機構など考慮していない実装なので、app.ts で下記のように// ./src/app.ts
import * as $ from 'jqeury';
import '../wwwroot/js/jquery.fizz.buzz';

$(() => {
let randomNum = Math.round(100 * Math.random());
$('#p1').text(randomNum);
});と import 文を書き足して参照しても、これは機能しない。

webpack によるビルドは成功するものの、いざブラウザで index.html を開くと「ReferenceError: jQuery is not defined (jQuery というシンボルが見つからない)」という実行時エラーになる。

そこで、まずは webpack の構成を変更し、jQuery が webpack によるモジュールバンドルに取り込まれないようにする。

そして代わりに、jQuery およびクラシック jQuery 拡張ライブラリ ( この例では jquery.fizzbuzz.js ) を、HTML 中から各々 script タグで参照するようにするのだ。

まず webpack.config.js に以下のように externals プロパティを記述する。// webpack.config.js
module.exports = {
entry: ['./src/app.ts'],
output: {
filename: './wwwroot/js/bundle.js'
},
resolve: { extensions: ['.js', '.ts'] },
module: {
loaders: [
{
test: /\.ts$/, use: [
{ loader: 'ts-loader' }
]
}
]
},
devtool: 'source-map',
externals: {
"jquery": '$'
}
};そして index.html には以下のとおりに script タグを追加する。<html>
<body>
<p id="p1"></p>
<p id="p2"></p>


<script src="/js/jquery.min.js"></script>
<script src="/js/jquery.fizzbuzz.js"></script>

<script src="/js/bundle.js"></script>
</body>
</html>この構成は、今回のようなケースに限らず、JavaScript ライブラリを CDN 経由で参照するのでバンドルに含めたくない、といった場合にも採用する構成だ。

これで実行時に jquery.fizzbuzz.js が初期化失敗することはなくなった。
TypeScript における型定義の解決アプリケーションコードをTypeScript ではなく素の JavaScript で記述していたのであれば、以上、webpack の externals 指定を構成するだけで対応完了となる。

しかし今回の命題では、アプリケーションコードは TypeScript で記述することとしている。
そのため、何らかの手段で拡張された jQuery メソッドの情報を TypeScript に教えてやらないといけない。

今回の架空の例である jquery.fizzbuzz.js は、$("セレクタ").fizzbuzz(数値) という、fizzbuzz メソッドが jQuery に追加になるという代物である。

だが、ここまでの段階ではまだ、app.ts に下記のとおり記述しても、TypeScript のコンパイルが「TS2339: Property 'fizzbuzz' does not exist on type 'JQuery<HTMLElement>'.」というエラーで失敗する。// ./src/app.ts
import * as $ from 'jqeury';

$(() => {
let randomNum = Math.round(100 * Math.random());
$('#p1').text(randomNum);
$('#p2').fizzbuzz(randomNum); // ← この行がコンパイルエラー
});TypeScript コンパイラには、jquery.fizzbuzz.js によって fizzbuzz メソッドが増えるということがわからない・知らされていないためだ。
型定義情報を記述「jQuery に fizzbuzz メソッドが増えている」ことを TypeScript コンパイラに知らしめるためには、型定義を自前で書けばよい。

ということで、./src/jquery.fizzbuzz.d.ts を作成。
単純に jQuery の型定義で提供されている JQuery インターフェース定義に対し、追加の定義を書き足せばよい。// ./src/jquery.fizzbuzz.d.ts
interface JQuery {
fizzbuzz(n:number) : jQuery;
}以上で、TypeScript 型定義もなく、JavaScript モジュール機構にも対応していない古典的な jQuery 拡張ライブラリを、webpack + module import な TypeScript + jQuery の構成でも使用できるようになる。

参考までに、プロジェクト全体を GitHub にサンプルコードとして載せておいた。

こんなクラシックな jQuery 拡張を相手にしないで済むのであれば、それがいちばんよいのだろう。
とはいえ、なかなか現実にはそうもいかないこともあろうかと思う。

そんな場面に遭遇した時には、本稿の手順で対応することを検討するのも選択肢のひとつである。

前回の記事で、下記のように JavaScript のモジュール機構をまったく知らない世代の実装となっている jQuery 拡張ライブラリについて、(function ($) {
// こうすることで jQuery に拡張機能 xxxx を括り付ける
$.fn.xxxx = ...
})(jQuery);これを webpack + TypeScript の開発環境にてどうやって使うか、その方法について投稿した。
前回の作戦は、「jQuery をバンドル対象外」とするよう webpack を構成することで、jQuery オブジェクトをグローバル名前空間に晒すこととし、その結果、旧来どおり script タグで jQeury を読み込むようになったので、レガシーな jQuery 拡張も使えるようになるよ、というものであった。

いっぽうで、このレガシーな jQuery 拡張の実装のほうに手を入れることで、その jQuery 拡張を module import 可能に対応させることで先の命題を解決することもできる。

今回はその方法について説明する。
レガシー jQuery 拡張をモジュールバンドルすると実行時エラーが起きる仕組みさて、レガシー jQuery 拡張ライブラリが、実行時に「ReferenceError: jQuery is not defined (jQuery というシンボルが見つからない)」エラーを引き起こすのは、レガシー jQuery 拡張ライブラリが、グローバル名前空間に "jQuery" というシンボルが存在することを前提としているためだ (下記参照)。(function ($) {
$.fn.xxxx = ...
})(jQuery); // <- ここいっぽうで、webpack を用いて CommonJS 方式でモジュールバンドルする際は、jQuery 本体もモジュール機能で名前空間が隔離されている。
結果、グローバル名前空間に "jQuery" という名前で jQuery オブジェクトをさらすことはない。

この食い違いが原因で、レガシー jQuery 拡張は実行時に "jQuery というシンボルが見つからない" エラーを引き起こすわけである。

CommonJS の仕組みにおいては、jQuery オブジェクトに用事があるモジュールは、そのモジュール内で "require('jquery')" を実行してその戻り値としての jQuery オブジェクトを使用する必要がある。解決方法ここまでわかれば、レガシー jQuery 拡張を CommonJS モジュール対応させるのは簡単だ。

グローバル名前空間にある jQuery シンボルを参照しようとするのをやめ、代わりに require('jquery') で jQuery モジュールを正規にインポートしたものを参照すればよい。(function ($) {
$.fn.xxxx = ...
})(require('jquery')); // グローバル変数 jQuery ではなく、
// require() の結果を引数に渡す!これで webpack + TypeScript な構成でも、この改造後の jQeuery 拡張を import しモジュールバンドルできるようになる。
下位互換も維持するにはなお、このような改造を施した jQuery 拡張ライブラリは、今度は、旧来どおり素で script タグでブラウザに読み込ませるような構成だと動作しないことになる。

script タグで個々の JavaScript ライブラリを読み込ませるような構成だと、ブラウザの JavaScript エンジン上では require などという CommonJS モジュール機構が存在しないので、ここで実行時エラーになるわけだ。

最初の話と逆転しているわけである。

ただし、jQuery 本体それ自体が、CommonJS 方式のモジュール機構にも、素の script タグで読み込ませるケースにも、両方に対応できていることからわかるように、今回話題にしてるようなレガシー jQuery 拡張も、両方のケースに対応させることは難しくない。

アルゴリズムとしては、下記のとおりだ。

まず、(jQuery拡張) 自身が読み込まれた環境が CommonJS モジュール機構内かどうかを判定し、モジュール機構内であれば、require('jquery') を実行して戻り値で返ってきたオブジェクト ( = jQuery オブジェクト) を、そうでなければグローバル名前空間の jQuery というシンボルを使って、jQuery 拡張機能を括り付ける

実際にコードに書き表したのが下記である。// 下記赤文字の jQuery 拡張機能を括り付ける関数を引数 factory として受け取り...
(function (factory) {
// 先述のアルゴリズムで jQuery オブジェクトの参照方法を if 文で仕分けて、
// 引数 factory で受け取った jQuery 拡張機能括り付け関数を実行する。

// ...という処理を無名関数として実装、即時実行する。

// CommonJS の場合...
if (typeof exports == 'object' && typeof module == 'object') {
// require('..') で取得したオブジェクト (= jQuery オブジェクト) を渡す
factory(require('jquery'));
}

// ブラウザの場合...
else {
// グローバル変数 jQeury を渡す
factory(jQuery);
}
})(function ($) { // jQuery 拡張を括り付ける本体
// ちなみに、この関数内は改造の必要はない。
$.fn.xxxx = ...
})CommonJS を知らないレガシーな jQuery 拡張機能であっても、このような改造を施せば、旧来通りの使い方もできる下位互換を維持しつつ、webpack による CommonJS モジュールバンドリングにも使用できるようになる。
補足ちなみにこの実装方法は、カラーピッカーとして (多分) 有名な jQuery 拡張である Spectrum のソースコードを参照してて知った。

Spectrum のソースコードでは、JavaScript のモジュール機構として、CommonJS のみならず、AMD 方式にも対応しており、ブラウザう + CommonJS + AMD の 3方式すべてに互換となっている。詳しくは Spectrum のソースコードを参照されたし。

ClosedXML とその .NET Core 対応状況C# などの .NET 環境において、Excel ファイルを読み書きするライブラリとしては、自分が知っている範疇では以下を挙げられる。ClosedXMLEPPlusNPOIこのうち、自分は 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」を右クリックして「パッケージ」をクリックする。

すると、ひととおりビルドが始まって、最終的に ./ClosedXML/bin/Release フォルダに ClosedXML.0.9.0.nupkg ができあがる。

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

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

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

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

ここでパッケージ ID やバージョンなどを、適宜、私家版ビルドにふさわしいものに改変する。

その上でもういちど、プロジェクト「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 対応にあたり、何か助力できることがあれば、フィードバックするに越したことはないだろう。

.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 モードを採用の方向で考えている。
　
　

Visual Studio の外部ツールメニューに PowerShell を登録自分は Visual Studio IDE の外部ツールに、下記のような感じで PowerShell の起動を登録してある。

さらにこの外部ツール登録に対し、キーボードショートカット Ctrl + P, Ctrl + S を割り当ててある。

これでいつでも現在開いているプロジェクトのソリューションフォルダをカレントディレクトリとして、Ctrl + P, Ctrl + S を打鍵することで PowerShell を開くことができる。

ちなみに、Visual Studio IDE には、通常、Package Manager Console ウィンドウが付属している。
この Package Manager Console は PowerShell セッションなので、外部ツールとして PowerShell を起動せずとも、Package Manager Console を PowerShell のターミナルとして使うこともできる。

また、Visual Studio IDE のアドインである "Open Command Line" をインストールすると、Ctrl + Space でコマンドプロンプトを起動する拡張機能を使えるようになる (キーバインドは変更可能)。

ただ、自分の場合は、諸々の事情から、冒頭のとおり外部ツールとして PowerShell を開いて利用する形態としている。

Ctrl + C で止まってくれないさて、そうやって外部ツールメニュー登録から開いた PowerShell コンソールで何をするかというと、git の操作やら、明示的な webpack によるバンドルやら、いろいろやるのであるが、なかには cordova run browser などのように Apache Cordova によるモバイルアプリ開発における Web ブラウザでの試験実行もある。

なお、Visual Studio IDE には、Apache Cordova 用のプロジェクトテンプレートや、Tools for Cordova なども含まれている。
しかし、対応している cordova や Android SDK のバージョンが古いままらしく、新しいバージョンの環境ではうまく動作してくれなかった。
そのため、いまのところ、Visual Studio Tools for Cordova の統合環境は利用せずに、コマンドラインベースで Cordova アプリ開発を実施している。

さて、開発作業の過程にて、「cordova run browser」を停止させたくなるケースも普通にある。
そのような場合、通常は Ctrl + C を打鍵すればコンソールアプリは停止してくれる。

ところがどういうわけか、Visual Studio の外部ツールメニュー登録から起動した PowerShell コンソール内では、いくら Ctrl + C を打鍵しても無視されてしまい、cordova コマンドは停止してくれないのだ。

しかし同じ PowerShell でも、スタートメニューやエクスプローラ、「ファイル名を指定して実行」から起動した PowerShell コンソールであれば、(当たり前だが) Ctrl +C を押せば cordova コマンドは停止してくれる。

なぜこのような違いが起こるのだろうか?

Ctrl + C の無視は子プロセスに引き継がれるいろいろ調べていくうちに、これは、Windows OS におけるコンソール API の仕組みが関係してるらしいことがわかってきた。

Windows OS におけるコンソール API には、SetConsoleCtrlHandler という API があり、この API を呼び出すことで、コンソール内で Ctrl + C が押された時の挙動をカスタマイズできるらしいのだ。

そして上記ドキュメントによれば、この SetConsoleCtrlHandler API による Ctrl + C 押下時の挙動カスタマイズは、親プロセスから子プロセスへ引き継がれるとのこと。

つまり、もしも Visual Studio IDE 内で SetConsoleCtrlHandler API を使って Ctrl + C の動作を抑止していたとすれば、Visual Studio IDE から起動される子プロセスでも Ctrl + C が効かないわけである。

そこで、この仮説に基づき、Visual Studio IDE から起動された、Ctrl + C が効かない状態の PowerShell コンソールで、明示的に SetConsoleCtrlHandler API を呼び出して、Ctrl + C 押下時の既定の動作を有効化することにしてみた。

Ctrl + C 押下時の既定の動作を復旧・有効化するには、SetConsoleCtrlHandler API の第1引数であるハンドラ関数として null を、第2引数のハンドラの追加有無を指定する真偽値に false を渡せばよい。// C/C++ Syntax with Win32 SDK
SetConsoleCtrlHandler(NULL, FALSE);なお、自分が知っている範疇では、PowerShell から直接には Win32 API を呼び出しできないっぽい。
そこで、まず C# にて P/Invoke 機構を利用して SetConsoleCtrlHandler API を呼び出すクラスライブラリを作成。
PowerShell からはこの自作のクラスライブラリを参照・実行することで間接的に SetConsoleCtrlHandler API を呼び出すようにしてみた。
Ctrl + C の有効化に成功こうして試してみたところ、予想は的中。

C# 製のクラスライブラリを仲介に SetConsoleCtrlHandler API を呼び出して、Ctrl + C 押下時の既定の動作を復旧・有効化したあとの PowerShell コンソール内では、「cordova run browser」実行中に Ctrl + C を押せば、cordova コマンドは期待どおり停止してくれるようになった。

仕上げとして、Visual Studio から PowerShell を起動するたびに毎回手作業で Ctrl + C の有効化作業を行うのは面倒なので、PowerShell のプロファイルに登録して、PowerShell コンソールを開くときは Ctrl + C の有効化が自動的に実施されるようにした。

以上の成果を、GitHub にまとめておいた。

なお、今回は SetConsoleCtrlHandler API を呼び出すために C# 製の独立したアセンブリファイル (.dll) を配置して行ったが、PowerShell の Add-Type コマンドレットでは、C# ソースコードの文字列を与えればオンザフライでコンパイルしてその .NET 型を利用できたように記憶している。
そのような手法を採れば、ソースファイルとしては .ps1 ひとつで完結するように作ることもできると思った (が、やってない)。

また、あいにくと自分は、PowerShell のモジュールの作り方とか PowerShell Get での公開の仕方とかわかってないので、この Ctrl + C 有効化手続きをそのようなパッケージに取りまとめて公開・配布することはできていない。

悪しからず。

あと今一度付け加えるとすれば、自分のケースのように事情がある場合はそうそうないと思うので、普通は素直に "Open Command Line" アドインを使っておくのが無難であろう。
このアドインが PowerShell を開くときは、おそらくは本記事で触れてあるような内容に対処済みなのであろう、ちゃんと Ctrl +C が効くのでご参考までに。

シナリオ.NET 版 Web アプリサーバー側フレームワークである ASP.NET Core で実装したWebアプリにおける、サーバー側からもクライアント側への呼び出しを行なうことのできる "Real time Web" 実装、ASP.NET Core SignalR。

今回はその ASP.NET Core SignalR を使っていて遭遇したトラブルとその回避方法の話である。

下記記事のコード例を基に話を進めよう。

但し、上記記事のコード例では、単一文字列を送受信していたところを、文字列の配列に変えてみたのが、今回のテーマ。

サーバー側実装は、上記記事のコード例に対し、下記強調表示のとおり書き換える。
public class Chat : Hub
{
public Task Send(string[] messages)
{
return Clients.All.InvokeAsync("Send", messages);
}
}
すなわち、クライアント側からサーバー側へ送信された文字列の配列を、そのまま文字列の配列のまま、クライアント側に送り返す実装だ。

クライアント側も同様に下記要領で、SignalR 接続が開設したら、単一文字列 "Hello" を送信していたところを、["Hello", "World"] の文字列の配列を送信するようにする。
且つ、受信した内容を console.log で開発者コンソールに表示する際に、合せてその受信内容の型も表示するようにしてみる。
let connection = new signalR.HubConnection('/chat');

connection.on('send', data => {
console.log(typeof (data))
console.log(data);
});

connection.start()
.then(() => connection.invoke('send', ['Hello', 'World']));
さて、このように手を加えたサンプルコードを実行、ブラウザで開くと、サーバー側からクライアント側に送信された内容が開発者コンソールに表示される。
その内容の期待値は、文字列の配列を送受信しているわけだから、当然下記のようなものとなる。
> object
> ["Hello", "World"]
ところが実際にやってみると、その実行結果は下記のとおりとなった。
> string
> "Hello"
サーバー側からは文字列の配列をクライアント側へ送信しているのに、それを受け取ったクライアント側では、なぜか第1要素のみが受信ハンドラの引数に渡されているのである。

これはおかしいと、ブラウザの開発者コンソールにて通信内容を確認してみた。
すると、なんと、下図（蛍光マーカー表示の箇所）のとおり、サーバー側からは単一文字列が2引数で送信されているように見える。当方の期待するところとしては、ここは ["Hello", "World"] ではなく、[ ["Hello", "World"] ] である。

原因原因は、サーバー側実装にあった。

SignalR における、サーバー側からクライアント側への送信に用いる InvokeAsync メソッドなのだが、これが可変個引数を扱うために object[] を引数にとるようになっている (下記)。
namespace Microsoft.AspNetCore.SignalR
{
public interface IClientProxy
{
Task InvokeAsync(string method, object[] args);

}
}
このため、愚直に配列をクライアント側へ送信しようと思って InvokeAsync メソッドの第二引数に渡すと、
配列を引き渡したいつもりが可変個引数として扱われてしまっていた
という訳だ。

ちなみに、InvokeAsync メソッドには拡張メソッドによるオーバーロードバージョンも用意されている (下記)。
using System.Threading.Tasks;

namespace Microsoft.AspNetCore.SignalR
{
public static class IClientProxyExtensions
{
public static Task InvokeAsync(this IClientProxy clientProxy, string method, object arg1);

public static Task InvokeAsync(this IClientProxy clientProxy, string method, object arg1, object arg2);
public static Task InvokeAsync(this IClientProxy clientProxy, string method, object arg1, object arg2, object arg3);
... // 以降、10引数まで続く
}

このオーバーロードバージョンによって、n 個引数での InvokeAsync 呼び出しの際、InvokeAsync("method", new object[]{ "taro", 24 }) と書かずに InvokeAsync("method", "taro", 24) と略して書けるようになっている。

回避方法回避方法はいくつかある。

「可変個引数のうち、第一引数に、文字列の配列を渡しますよ」ということを、略記せずにきっちり記述することで回避できる。
InvokeAsync("Send", new []{ // 可変個引数を表す配列
messages // その第1要素(第1引数) に、文字列の配列を渡す
});
いちばん直球勝負で正直な実装方法だが、ちょっとくどい。

あるいはまた、「object[] args」のシグネチャにマッチするのを回避しつつ、クライアント側 JavaScript では配列として扱われる List<T> に変換してから渡す方法もある。
// LINQ の ToList 拡張メソッドで List<T> に変換してから渡すことで、
// InvokeAsync(string, object arg1) の拡張メソッドに適合するようにする。
InvokeAsync("Send", messages.ToList());
いったん List<T> を生成するのでメモリ効率的に気持ち悪いが。

はたまた、「object[] args」のシグネチャにマッチしなければよいので、InvokeAsync(string, object arg1, object arg2) などにマッチするよう、ダミーの引数を付加することもできよう。
InvokeAsync("Send", message, "dummy");
しかし、前者でさえ「なぜわざわざ List<T> にするの?」という点で可読性低いのに、このダミー引数版はさらに可読性ダダ下がりな感じで、個人的には採用したくない手法。

「object[] args」のシグネチャにマッチしないようにオーバーロードバージョンの使用を誘導するのであれば、as 演算子で型を指定することもできる。

// as 演算子で object 型にアップキャストすることで、
// InvokeAsync(string, object arg1) の拡張メソッドに適合するようにする。

InvokeAsync("Send", message as object);

クライアント側実装もあわせて変えてよければ、同じく「object[] args」のシグネチャにマッチしないよう、匿名型オブジェクトにくるむ方法もある。

InvokeAsync("Send", new {messages});
クライアント側はこうなる。
connection.on('send', data => {
console.log(data.messages);

});

ざっと思いつく回避方法はこんなところだ。

ちなみに可変個引数は、例えば string.Format メソッドとかをはじめ、いろいろなところでよく使われる一般的な技法ではある。
ただ、例えば string.Format では配列を書式化したいとかいう需要がさほどないであろうから、そんな感じであまり問題にはならないのだろう。

まとめ以上、こんな感じで回避はできる。
とはいえ、やっぱり「なんでそのまま引数に渡さずにコネコネしてるの？」というように可読性は低いし、将来の保守で壊してしまったり、あるいは新規実装でもたびたびこのワナに陥りそうでちょっと嫌ではある。

ということで、この件は GitHub 上の Issue でもちょうど検討中らしい。

ASP.NET Core SignalR は、まだ Alpha バージョンである。
この件に関しても今後、何かしら変更や改善など進展が見られるかもしれない。
注目しておこうと思う。

Visual Studio 2017、または Visual Studio Code を使って、C# のコーディングをしていての話。

頻出パターン - コンストラクタ引数で受け取りプロパティに格納昨今の ASP.NET Core Web アプリ開発では、フレームワーク備え付けの DI (Dependency Injection:依存性注入) 機構によって、必要なサービスオブジェクトを参照するのが普通だ。

例えば Entity Framework Core のデータベースコンテキストオブジェクトをコントローラクラスで使いたい場合、コントローラクラスのコンストラクタにて、その引数にデータベースコンテキストオブジェクトを受け取るように実装する。

そして普通は、そうしてコンストラクタ引数で受け取ったオブジェクトを自身のプロパティで参照を押さえておき、のちのアクションメソッド内などから使用するのが常である。

この「コンストラクタ引数で受け取って、プロパティに格納」というコーディングは、今や頻出パターンである。

それだからであろうか、最新の Visual Studio IDE および Visual Studio Code には、このコーディングを支援するクイックアクション機能がいくつか備わっている。

その支援機能の中でも自分が好んで使うのは「プロパティを作成して初期化」クイックアクションだ。

「プロパティを作成して初期化」クイックアクション「プロパティを作成して初期化」クイックアクション機能の利用手順はこうだ。

Visual Studio 2017 ないしは Visual Studio Code でクラスのコーディング中において、コンストラクタの引数をまず実装する。

話がそれるが、引数の型名を入力してスペースまで打鍵した段階で、引数名の提案 (Suggest) が出てくるのも便利。
多くの場合、そのまま Tab キー打鍵で引数名のコーディングが済んでしまう。

話を戻そう。

そうやってコンストラクタ引数のコーディングが済んだら、すかさず Ctrl + . (ドット) を打鍵する。

するとこれがクイックアクション発動のキーバインドになっているため、既定のクイックアクション「プロパティを作成して初期化」が初期選択された状態でクイックアクションのメニューが開く。

そのまま Enter を打鍵すれば、以上で getter のみのプロパティとそのプロパティの初期化コードが生成される。

このように、
コンストラクタ引数をコーディング ⇒ CTrl + . ⇒ Enter
という、
たったこれだけのキー操作で、「コンストラクタ引数で受け取ったオブジェクトをプロパティに格納」がコーディングできてしまう
のが「プロパティを作成して初期化」クイックアクションだ。

ほかにもいろいろな手順でコーディング支援してくれるこの機能、あるきっかけで気が付いた。
恥ずかしながら、Visual Studio 新バージョンが出てもろくにリリースノート読んだりしてなかったので、いつのバージョンからこの機能が使えたのかはよくわかってない (もしかして、かなり昔から使えてた...?)。

が、とにかく、Visual Studio IDE および Code の両方で、「プロパティの作成と初期化」クイックアクションによるコーディング支援が受けられる。

詳しくは下記公式ドキュメントに説明がある。

このドキュメントを見ると、プロパティではなくフィールドを使用することもできることがわかる。

また、ほかにも「コンストラクタ引数で受け取って、プロパティに格納」をコーディングする支援機能はいろいろあるようだ。

例えば、先にプロパティをずらずらをコーディングしておき、それらプロパティを選択してからクイックアクション発動で、コンストラクタのほうを自動生成する、といった手順も可能だ。

ということで、「コンストラクタ引数で受け取って、プロパティに格納」が頻出パターンなプロジェクトにかかわっているのに、私のように、この、Visual Studio 2017/Code が提供してくれている「プロパティの作成と初期化」クイックアクションをまだ知ってなかった! という稀有な方は、これを機会にぜひ試用してみていただき、ご自身のコーディング人生をより幸せなものにしていただければと願う。
　

Azure Active Directory (AzureAD) Azure Active Directory (以下 AzureAD) は、Microsoft のパブリッククラウドサービス「Microsodt Azure」が提供する各種サービス機能のひとつ。

自分は、AzureAD を、自作のWebアプリの認証基盤として使用している。

すなわち、自作Webアプリのユーザー情報管理（ユーザーの追加・変更・削除）は、Azure のポータル Web サイトにおける AzureAD の画面で行い、且つ、ユーザーのサインイン処理(認証)も AzureAD が提供する機能・画面に任せて、自作アプリのほうはその認証の結果だけを頂戴するような形だ。

このように AzureAD を利用させてもらうことで、自作アプリ側に個別のユーザー情報管理機構を実装しなくて済む。

いわゆる "ID as a Service" って感じである。

AzureAD のユーザーアカウントのパスワードを無期限にさてそのような AzureAD であるが、AzureAD 上で作成するユーザーアカウントは、パスワード有効期間は 90日という設定が課せられている。

通常はそれで問題ないことと思うが、諸事情により、どうしてもパスワード有効期間を無期限としたい要件が発生した。

検索サイトで調べてみたところ、まず、AzureAD ユーザーアカウントのパスワード有効期間を無期限とすることは可能ではあるとのこと。
が、但しその設定変更は、Azore ポータル Web サイト上からはできない、ということらしい。

その代わりに、Office365 管理用の PowerShell モジュールを介して PowerShell 上からコマンドレット呼び出しして行えばよい、との記事が多数ヒットした。

しかしながら実際にそれら記事に沿って試してみたところ、自分の場合、同じサインイン名で複数の AzureAD インスタンス (テナント、ディレクトリ) に出入りしているケースがあり、しかし Office365 PowerShell モジュールの接続コマンドレット「Connect-MsolService」ではテナントIDを明示して接続する方法がわからず、目的のディレクトリ上での作業ができなかった。

あれこれ試行錯誤するも、時間ばかり過ぎて業を煮やした自分は、"Msol" が名前に付く Office365 管理由来のコマンドレットではなくて、生粋の AzureAD を相手にする PowerShellモジュール/コマンドレットがないものか、再度検索サイトで調べなおした。

そうしたところ、AzureAD v2 と呼ばれる PowerShell モジュールを用いた下記手順があることを知り、設定作業に成功した。

AzureAD v2 を使ってパスワードを無期限に設定する前提条件・事前インストール作業まず前提条件としては下記のとおり。
PowerShell v.5.0 以降、64bit 版
.NET Framework v.4.5 以降
上記が動作するOS (Win7 SP1以降、64bit)

この環境で、管理者として実行した PowerShell コンソール内で下記を実行し、AzureAD PowerShell モジュールをダウンロード & インストールする。
PS> Install-Module AzureADこれで AzureAD PowerShell モジュールのインストールが完了し、以後この環境から AzureAD を操作する各種コマンドが使えるようになった。

AzureAD への接続さて、ユーザーアカウントのパスワードを無期限とするためには、まずは PowerShell のセッションを、目的の AzureAD テナントに接続しておく必要がある。
接続のコマンドは下記のとおり。
PS> Connect-AzureAD -TenantId {ディレクトリID}引数のテナントID(ディレクトリID)は省略もできるが、接続する AzureAD ディレクトリを明示的に指定したい場合に使える。

なお、ディレクトリ ID は、Azure ポータル Web サイトの AzureAD 管理画面中、「プロパティ」カテゴリの表示から知ることができる。

さてこうしてコマンドレットを実行すると、認証用の GUI が表示される（下図）。

ここで対象の AzureAD に対する管理者アカウントで認証を済ませ、接続するとよいだろう。
( Get-Credential コマンドレットを使って認証情報を変数に入れてから、Connect-AzureAD の -Credential 引数に渡す手順を解説している記事を多々目にした。が、個人的には上記手順のほうが手数が少なくて面倒がない気がしている。)
ユーザーアカウントの設定変更ひとたび、Connect-AzureAD で PowerShell セッションを AzureAD に接続できたら、そのほかの AzureAD 関連コマンドレットが使えるようになる。

今回目的のパスワード有効期間を無期限とするユーザーアカウントの設定変更は、「Set-AzureADUser」コマンドレットを使って、以下のように実行する。
PS> Set-AzureADUser -ObjectId {対象ユーザーの ObjectID} -PasswordPolicies DisablePasswordExpiration

設定変更対象のユーザーアカウントは、そのユーザーアカウントの "ObjectID" で指定する。

ユーザーアカウントの ObjectID は、Azure ポータル Web サイトの AzureAD 管理画面から表示可能なほか、PowerShell セッション上で「Get-AzureADUser」を実行してディレクトリ中のユーザーアカウント一覧を表示させることでも知ることができる。

出典以上、AzureAD PowerShell モジュールを使って、AzureAD 上のユーザーアカウントのパスワード有効期間を無期限に設定変更する手順である。

なお、-PasswordPolicies 引数及び DisablePasswordExpiration 指定についての出典は下記のとおり。

New-AzureADUser | Microsoft Docs

Set-AzureADUser | Microsoft Docs

ASP.NET アプリ開発時 & Azure への配置における、DB接続設定の使い分けについて再び

ASP.NET Web API コントローラにてバイナリコンテンツを返す方法

ASP.NET Core では Web API でバイナリコンテンツを返すのは簡単だった件

「お前の IP アドレスを echo する」Web アプリを作る (手順はあるけど実装コードそのものは6行!)

Application Insights で Web アプリのクライアント JavaScript 例外を記録したら、URL は記録されていない?

Visual Studio 2017 上で作成した ASP.NET Core 1.1 アプリの Docker イメージを Heroku に配置・実行する

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

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

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

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

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

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

型定義もなく module import もできないレガシー jQuery 拡張を、webpack + module import な TypeScript で使う

module import できない古典的な jQuery 拡張を、import できるようにする

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

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

Visual Studio IDE の外部ツールに登録した PowerShell 内では Ctrl + C が効かない?

ASP.NET Core SignalR - サーバー側で配列を渡して InvokeAsync しても、JavaScript 側で第1要素しか受け取れない?

最近お気に入りの Visual Studio 2017/Code の機能 - 「プロパティを作成して初期化する」

Azure AD のユーザーアカウントのパスワード期限を無期限にする