@jsakamoto

ASP.NET Core のアプリケーション構成を上書きするいろいろ - 特に環境変数とコレクション

ASP.NET Core アプリのアプリケーション構成

ASP.NET Core アプリは、標準のプロジェクトテンプレートで作成すると、プロジェクトのフォルダにある appSettings.json というファイルを読みこんで、アプリケーション構成として使用するようにできている。

この appSettings.json にアプリケーション固有の半固定パラメータなどの設定値を JSON 形式で記述しておき、アプリ中からその設定値を読み取って利用する、というものだ。

詳しくは下記を参照するとよいだろう。

例えば下記のような appSettings.json を用意したとして、

{

"SiteSettings": {

"Title": "Hello World",

"TimeZone": {

"Name": "Tokyo Standard Time",

"Offset": 9

},

"Tags": [

{ "Text": "Foo", "Priority": 0.7 },

{ "Text": "Bar", "Priority": 0.3 }

]

}

}

ASP.NET Core アプリの実装コード (今回は C#) で、下記のように、上記 appSettings.json の JSON 構造にマッピングされるクラスを用意して、

public class SiteSettings {

public string Title { get; set; }

public TimeZoneSettings TimeZone { get; set; }

public class TimeZoneSettings {

public string Name { get; set; }

public int Offset { get; set; }

}

public TagSettings[] Tags { get; set; }

public class TagSettings {

public string Text { get; set; }

public double Priority { get; set; }

}

}

ASP.NET Core アプリの Startup クラスにて、下記のように、appSettings.json ファイル中の SiteSettings ノード以下を DI コンテナへサービス登録することで、

public class Startup

{

public IConfiguration Configuration { get; }

public Startup(IConfiguration configuration)

{

Configuration = configuration;

}

public void ConfigureServices(IServiceCollection services)

{

services.Configure<SiteSettings>(Configuration.GetSection("SiteSettings"));

...

`IOptions<SiteSettings>` 型のインスタンスを DI 機構によって入手できるようになる。

この `IOptions<SiteSettings>` オブジェクトの各プロパティを参照すると、appSettings.json の記載内容が SiteSettings オブジェクトにマッピングされて読み取られ、参照可能となっている寸法だ。

// 変数 settings は、DI 機構から入手した IOptions<SiteSettings> オブジェクトへの参照

settings.Value.Title; // <- "Hello World"

settings.Value.TimeZone.Name; // <- "Tokyo Standard Time"

settings.Value.TimeZone.Offset; // <- 9

settings.Value.Tags[0].Text; // <- "Foo"

settings.Value.Tags[1].Text; // <- "Bar"

アプリケーション構成の "上書き"

この appSettings.json に記載されている設定値だが、いくつかの方法で "上書き" が可能だ。

ひとつは appSettings.Develop.json に記述する方法。

開発環境での実行時は、appSettings.json の設定値に対して、appSettings.Develop.json に記述した設定値で上書きされたように、アプリ側では設定値を読み取るようにできているのだ。

この仕組みにより、appSettings.json には既定値を、appSettings.Develop.json には各開発者固有の環境依存の設定値など（例えばデータベースの接続先設定値とか）を記載しておいたりして、アプリの動作を調整できる。

例えば先の例だと、appSettings.Develop.json に以下のように記述しておくと、

{

"SiteSettings": {

"TimeZone": {

"Name": "Asia/Tokyo",

}

}

}

アプリ側の読み取り結果は下記のとおりとなる。

settings.Value.Title; // <- "Hello World"

settings.Value.TimeZone.Name; // <- "Asia/Tokyo" ... 上書きされた!

settings.Value.TimeZone.Offset; // <- 9

settings.Value.Tags[0].Text; // <- "Foo"

settings.Value.Tags[1].Text; // <- "Bar"

なお、appSettings.Develop.json の "Develop" のファイル名部分は、実は環境変数 ASPNETCORE_ENVIRONMENT の値である。

なので、環境変数 ASPNETCORE_ENVIRONMENT に "FooBar" を設定すれば、appSettings.FooBar.json が上書き用に読み込まれる。

アプリケーション構成のセクション名は英字の大小が区別されない

話は逸れるが、面白い(?)ことに、appSettings.Develop.json で appSettings.json の設定値を上書きする際、セクション名 (ノード名、プロパティ名) の英字の大文字と小文字は一致しなくても構わない。

アプリケーション構成のセクション名は Case Insensitive として動作するのだ。

なので、appSettings.json に、英字の大小違いの同一セクションを設けると（例えば下記）、JSON としては間違いではないのだが、その ASP.NET Core アプリは起動時にクラッシュしてしまう。

{

"SiteSettings": {

"title": "hello world", // <- セクション名の先頭が小文字

"Title": "Hello World", // <- セクション名の先頭が大文字

IIS 経由で実行した場合は

「HTTP Error 502.5 - Process Failure - The application process failed to start」

として現れるし、「dotnet run」で実行すると、

「Unhandled Exception: System.FormatException: A duplicate key 'SiteSettings:Title' was found.」

というように、重複キー発生である例外メッセージがコンソール出力から読み取れる。

環境変数で "上書き"

アプリケーション構成を上書きするもうひとつの方法は、環境変数で "上書き" する方法である。

appSettings.json 中の各セクション (ノード、プロパティ) 名を、コロン (:) 区切りで連結した名前で環境変数を定義すると、その環境変数の値がアプリケーション構成として読み取れるのだ。

言い換えると、C# や JavaScript 上、ドット (.) で区切るところをコロン区切りに置き換えた名前、とも言える。

先の例でいくと、例えば環境変数 "SiteSettings:TimeZone:Offset" に "8" と設定してから実行すると、アプリでの読み取り結果は下記のとおりとなる。

settings.Value.Title; // <- "Hello World"

settings.Value.TimeZone.Name; // <- "Tokyo Standard Time"

settings.Value.TimeZone.Offset; // <- 8 ... 9 から 8 に上書きされた!

settings.Value.Tags[0].Text; // <- "Foo"

settings.Value.Tags[1].Text; // <- "Bar"

Windows OS 上で Visual Studio を用いて開発・実行している場合は、Visual Studio の画面上、プロジェクトのプロパティ画面から環境変数を設定することもできる。

このやり方だと、環境変数の設定を変更して保存 (Ctrl +S) すると、Visual Studio が自動で ASP.NET Core アプリのプロセスを再起動してくれ、アプリケーション構成が再読み取りされて、設定内容が即反映されるのだ。

appSettings.json 及び appSettings.Develop.json を編集・保存した場合は、そのようなプロセス再起動をはじめ、自動でアプリケーション構成を再読み取りされることはないようである。

(どこかで、appSettings.Develop.json が変更されたら再読み取りするオプション指定を見かけたような気もするのだが。)

ちなみに、こうして Visual Studio 上から設定した環境変数設定は、プロジェクトのフォルダ以下、Properties フォルダ内の launchSettings.json 内に書き込まれる。

「dotnet run」で実行する際も、この launchSettings.json の内容は読み取られて使われる。

なので、launchSettings.json に環境変数を設定しておいて「dotnet run」で実行すると、その環境変数設定が反映されて実行される。

ご参考までに。

また、これも至極当然のことではあるが、こうして環境変数で上書きする際も、セクション名 (環境変数名) の英字の大小は区別されない。

Microsoft Azure の App Service 設定での "上書き"

実は、Microsoft Azure の App Service 上に Web アプリを配置したときに、Azure ポータルから「アプリケーション構成」で設定する値も、アプリ側には環境変数として現れる。

なので、この仕組みで、ASP.NET Core アプリのアプリケーション構成を Azure ポータルから上書き設定することができるのだ。

その際のセクション名の指定方法は、上記のとおりコロン区切りでセクション名を連結した名前を、Azure ポータル「アプリケーション構成」の欄の "APP SETTING NAME" のところに指定してやれば良い。

"上書き" というよりは "合成" と言ったほうがイメージあってる?

これら "上書き" の動作だが、優先順位としては次のとおり。

環境変数 > appSettings.Develop.json > appSettings.json

上記3者で同じセクション名で異なる値をそれぞれ設定していた場合、環境変数による設定が勝つ。

また、"上書き" とは言ったが、appSettings.json 内に記述のないセクション名のアプリケーション構成を、環境変数で設定してあれば、アプリ側ではちゃんと読み取れる。

例えば appSettings.json に SiteSettings.Title がなくても、

"SiteSettings": {

"TimeZone": { // <- "Title" プロパティがない!

...

環境変数 "SiteSettings:Title" に "HELLO!" が設定されていれば、アプリ側ではちゃんと読み取れる。

settings.Value.Title; // <- "HELLO!" ... 環境変数での設定が見えている!

なお、上記のような例を見ると、appSettings.json に存在しないセクションなので、存在しないものに対して "上書き" という言い方には違和感を覚えるかもしれない。

上書きというよりかは、Key-Value の辞書のツリーを "合成" (マージ) していくようなイメージのほうが理解しやすいかもしれない。

よくよく考えたら、環境変数を読むのに使えたり。

ここまでを振り返ってよくよく突き詰めて考えてくと、実は ASP.NET Core のアプリケーション構成の仕組みで、環境変数がまるっと取得できてしまったりもするのだ。

ここまで紹介してきた例では、Startup にて、"Configuration.GetSection("SiteSettings")" と設定していたので、すべての環境変数は見えず、"SiteSettings:～" で始まる名前の環境変数だけ見えていた。

これを改め、単に "Configuration" オブジェクトそのものを渡してバインドすれば、すべての環境変数値がバインド可能だ。

また、ASP.NET Core アプリケーション構成の仕組みは、必ずしも静的型付けしなくては使えないわけではなく、Configuration オブジェクトを参照し、その GetValue などのメソッドを使って、文字列でセクション名 (= 環境変数名) を指定して取得することもできる (下記など参考に)。

本来の用途ではないが、ASP.NET Core のアプリケーション構成の仕組みを介して、プロセスの環境変数をすべて参照することも可能だ。

ところで、コレクションって何にバインドできる?

ところで、今回の例にある、"Tags" セクションは、JSONN 上、配列になっており、これのバインド先の SiteSettings クラスでも配列としている。

public class SiteSettings {

...

public TagSettings[] Tags ... // <- TagSettings 型の "配列"

...

試したところ、実はここ、配列じゃなくても大丈夫だった。

"List<T>" でも "IEnumerable<T>" でも "ICollection<T>" でもバインドできた。

public class SiteSettings {

...

public IEnumerable<TagSettings> Tags ... // <- これでも OK!

...

果たして "T[]"、"List<T>"、"IEnumerable<T>"、"ICollection<T>"、etc. のいずれでバインドするのが最適なのか、自分にははっきりとは判断つきかねる。

ただ、どちらかといえばいちばん書き換えできなさそうな "IEnumerable<T>" がいいのかなぁ、と漠然と考えている。

環境変数からコレクションの設定を上書きするには?

さて今回の例の "Tags" セクション内の配列構成を、環境変数で上書きするには、どのような変数名を指定すればよいのだろう?

最初は、"SiteSettings:Tags[0]:Text" というような、C# や JavaScript などでよくあるインデクサ表記を環境変数名とすることで上書きできるのかと考えた。

が、試したところこれは間違い。

正解は "SiteSettings:Tags:0:Text" だ。

これは "JavaScrit 的な考え方" に慣れてるとわかりやすいと思う。

すなわち、配列の要素を、例えば0番目の要素であれば「Tags オブジェクトの、"0" という名前のプロパティ」というように捉えるのだ。

今回の例の、上書き前のオリジナルの appSettings.json の構成内容だと、Tags プロパティの内容は下記のとおりとなっている。

settings.Value.Tags[0].Text; // <- "Foo"

settings.Value.Tags[0].Priority; // <- 0.7

settings.Value.Tags[1].Text; // <- "Bar"

settings.Value.Tags[1].Priority; // <- 0.3

ここで環境変数 "SiteSettings:Tags:1:Text" に "Hoge" を設定すると、下記のとおり上書きされる。

settings.Value.Tags[0].Text; // <- "Foo"

settings.Value.Tags[0].Priority; // <- 0.7

settings.Value.Tags[1].Text; // <- "Hoge" ... "Bar" から上書きされた!

settings.Value.Tags[1].Priority; // <- 0.3 ... ここはそのまま!

上書き前の配列要素数を超えたら...?

さて、では今回の例において、環境変数 "SiteSettings:Tags:999:Text" に "Hoge" を設定したらどうなるのか!?

アプリ側で読み取った結果はこうなった。

settings.Value.Tags[0].Text; // <- "Foo"

settings.Value.Tags[0].Priority; // <- 0.7

settings.Value.Tags[1].Text; // <- "Bar"

settings.Value.Tags[1].Priority; // <- 0.3

// Tags[2] が増えた!

settings.Value.Tags[2].Text; // <- "Hoge"

settings.Value.Tags[2].Priority; // <- 0.0

一瞬戸惑ってしまったが、改めて JavaScript 脳になって考えてみると、何のことはない、環境変数名の "999" は「配列の添え字」ではなく、プロパティ名なのだ。

どうやら、ASP.NET Core のアプリケーション構成の仕組みは、バインド先の型がコレクションである場合、バインド元の値の "プロパティ" を列挙して、その値を順繰り、バインド先のコレクションの要素に編成しているようである。

配列、じゃなくて、結局は Key-Value の辞書である

なので、数字だけじゃなくて、任意の識別子を当てはめられる。

例えば環境変数名を、"SiteSettings:Tags:999:Text" ではなく、"SiteSettings:Tags:FizzBuzz:Text" としても、結果は同じになるのだ。

また、環境変数からの上書きというのではなく、appSettings.json の記述そのものを辞書形式で記述することもできる。

"SiteSettings": {

...

"Tags": [

{ "Text": "Foo", "Priority": 0.7 },

{ "Text": "Bar", "Priority": 0.3 }

]

...

は、アプリケーション構成的観点では以下のように記述してるのと同義と言える。

実際、アプリでの読み取り結果も変らなかった。

"SiteSettings": {

...

"Tags": {

"0": { "Text": "Foo", "Priority": 0.7 },

"1": { "Text": "Bar", "Priority": 0.3 }

}

...

さらには、プロパティ名 (Key) は数字である必要すらない。

下記でも TagSetting[] にバインドされ、読み取り結果は変わりない。

"SiteSettings": {

...

"Tags": {

"Alpha": { "Text": "Foo", "Priority": 0.7 },

"Omega": { "Text": "Bar", "Priority": 0.3 }

}

...

ちなみに、上記のような感じで Key-Value 辞書オブジェクトをコレクションにバインドした場合、その要素の追加順序は、プロパティ名 (Key) のオーダーとなるようだ。

削除はできなさそう

なお、このような仕掛けであるようなので、appSettings.json で設定した配列構成要素を、appSettings.Develop.json や環境変数から "削除" することはできなさそうだ。

例えば今回の例において、appSettings.Develop.json を以下のとおり記述し、Tags の設定内容を要素数 0 件に潰そうとしたとする。

"SiteSettings": {

...

"Tags": [] // オリジナルの Tags 構成値を0件にしてやる!

...

しかしこれは意図したとおりには動作しない。

配列ではなく、"0" や "1" といった配列序数を名前としたプロパティを持つオブジェクトを "上書き" するのだ、と JavaScript 脳で考える必要がある。

JavaScript で言うならば、オリジナルの Tags オブジェクト に対し、空のオブジェクトで Object.assign するようなものだ。

var tags = {"0":{...}, "1":{...}};

var tagsDevlop = {}; // "Tags":[] は空オブジェクトと同義

// 空オブジェクトを assign しても、tags は何の変化もなし!

Object.assign(tags, tagsDevelop);

結果として、上記 appSettings.Develop.json は、何の効果ももたらさないこととなる。

そう、JavaScript の Object.assign を知っているならば、ASP.NET Core アプリケーション構成の "上書き" の仕組みは、Object.assign であると考えると間違いがないだろう。

まとめ

以上、ASP.NET Core のアプリケーション構成の上書き (というか、"合成") の振る舞いについて色々試した結果となる。

ざっくりおさらいすると下記のとおり。

• 英字の大文字・小文字は区別されない。
  
• appSettings.Develope.json より環境変数のほうが勝つ。
  
• 環境変数ではセクション名をコロンで区切って設定。
  
• Visual Studio での環境変数設定は Properties\launchSettings.json ファイルに保存される。
  
• コレクションのバインド先は "T[]", "List<T>", "IEnumerable<T>", "ICollection<T>" のいずれでも OK。
• 環境変数でコレクションの要素を上書きするには、序数をプロパティ名として設定。
  
• コレクションもその正体は、"0" や "1" といった序数をプロパティ名とした JavaScript オブジェクト (辞書) であるだけ。
  
• なので、序数じゃない任意の識別子も指定できちゃう - その場合、プロパティ名 (Key) のオーダーでコレクションが編成される。
  
• 結局、JavaScript の Object.assign() で重ね書きしてる感じ。
  
• なので、appsettings.json に設定済みの要素を、削除することはできないと思われる。
  

あと、最後になってしまったが補足しておくと、ここまでのアプリケーション構成の仕組みは ASP.NET Core アプリに限らず、Microsoft.Extensions.Options でアプリケーション構成を扱う .NET アプリ全てに適用される。

今回の投稿はかなりの大作となってしまった。

これでアプリケーション構成の "上書き" で迷うことはなくなった...と思いたい。

ASP.NET Core 2.1 の UseHttpsRedirection が Azure Web Apps 上では効かない?

HTTPS プロトコルでのアクセスを強制する

ASP.NET Core 2.1 から登場した、Microsoft.AspNetCore.HttpsPolicy NuGet パッケージにて提供されている HttpsRedirection ミドルウェアを使うと、ASP.NET Core 2.1 Web サイト/アプリに、HTTP プロトコルでのアクセスがあったら HTTPS プロトコルのアクセスにリダイレクトさせる機能を実装できる。

例えば Visual Studio IDE 2017 で開発している場合は、Visual Studio IDE のプロジェクト新規作成のダイアログにて、この HTTPS リダイレクト機能込みでプロジェクトを作成する選択肢が用意されている。

こうして作成した ASP.NET Core 2.1 Web アプリの Startup.cs を覗いてみると、Configure メソッド内にて、「app.UseHttpsRedirection()」というように、HttpsRedirection ミドルウェアの組み込みを行っている行があるのがわかる。

この状況で、ローカル開発環境で実行してみると、たしかに http://localhost:... のアクセスは https://localhost:... へのアクセスにリダイレクトされている。

Azure Web Apps 上では、デプロイするだけでは NG

それではこの ASP.NET Core 2.1 Web アプリを Azure Web App に発行してみたらどうなるか。

残念ながら (?)、それだけでは HTTPS プロトコルへのリダイレクトは機能しない。

ドキュメントを確認してみると、HttpsRedirect ミドルウェアによる HTTPS プロトコルへのリダイレクトは、ある一定の条件が必要らしい。

ここでは、「環境変数 ASPNETCORE_HTTPS_PORT に、HTTPS プロトコルで接続するときのポート番号が指定されている場合」を、Azure Web Apps に適用して、HTTPS プロトコルへのリダイレクトが発動するように試してみた。

具体的には、Azure ポータル上から、当該 Web App のアプリケーション構成の設定ブレードを開き、下図のように HTTPS_PORT = 443 (※ポート番号 443 は HTTPS プロトコルの標準のポート番号) に設定する。

こうすると、Azure Web Apps 上に発行後でも、HTTPS プロトコルへのリダイレクトが機能するようになった。

以上！

　

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

シナリオ

.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 バージョンである。

この件に関しても今後、何かしら変更や改善など進展が見られるかもしれない。

注目しておこうと思う。

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

　

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

さてこのミドルウェア、繰り返しになるが、静的ファイルに限らずコンテンツタイプが "text/markdwon" である応答ならなんでも HTML に変換する。

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

実際にやってみた

AspNetCore.MarkdownPages のインストール・導入方法は、GitHub 上のドキュメントに譲るとして、

.cshtml 側の書き方を補足する。

最低限必要なのは、応答のコンテンツタイプを "text/markdown" に変更することだ。

一例としては .cshtml 中の冒頭のコードブロックで下記のように記述する。

@page

@{

Response.ContentType = "text/markdown";

}

ASP.NET Core 1.0 のアプリケーション構成 (オプション) を動的に読み取る

ASP.NET Core 1.0 ではアプリケーション構成は型付けされる

ASP.NET Core 1.0 からは、アプリケーション構成(オプション)を読み取る方法が大幅に改築された。

まずはオプション値を表すクラスを記述し、そのオプション値の型にアプリケーション構成を逆シリアライズして、そうして生成されたオプション値を DI 機構を経由して受け取る、という "型付け" された形態になった。

詳しくは下記が大変参考になる。

ASP.NET Core 1.0 でオプションを柔軟に扱えるようになった話
http://blog.shibayan.jp/entry/20160529/1464456800

型がついてまわるので、文字列でアプリケーション構成のエントリ名を記述するのとは異なり、

• インテリセンスが効くのはもちろん、
• オプション値を参照している個所の特定や
  (同僚が書いたコード又は自分が3ヵ月前に書いたコードを保守するときは、これがとても心強い)、
• エントリ名の変更といった仕様変更も楽勝

である。

※余談になるが、自分の場合、旧来の web.config 中の appSettings 構成セクションへのアクセスを静的型付けするために、SwissKnife.T4.AppSettings NuGet パッケージを多用してきた。

また、ASP.NET MVC コントローラクラスなどでは、DI 機構を通じてオプション値を入手するため、コントローラの単体テストの記述のしやすさに大きく貢献することだろう。

しかし実行時にエントリ名が決まることもある

このように、ASP.NET Core 1.0 から型付けを前提にアクセスすることになったアプリケーション構成(オプション)。
しかし、そうやたらとあるわけではないにせよ、まれに、実行時にエントリ名が決定されるような要件、言い換えると、文字列でエントリ名を指定してオプション値を入手しなければならないケースがある。

さきのしばやん先生のブログ記事でも触れられているが、"裏技的な感じ" はするものの、 IConfiguration を DI に追加すればこの要件に対応できると予想された。

ということで、試してみた。

IConfiguration を DI に登録してみる

DI 機構にて注入される "サービス" オブジェクトを DI 機構に登録するには、Startup クラスの ConfigureServices メソッド内でその登録処理を行う。

そこで、Startup クラスのコンストラクタにて別途 Configuration プロパティに初期化みの、IConfiguration インターフェースを備える "構成オブジェクト" を、ConfigureServices メソッド内で DI 機構に登録する。

具体的なコードは下記のとおり。

public void ConfigureServices(IServiceCollection services)

{

  ...

  services.AddSingleton<IConfiguration>(this.Configuration);

}

以上で、ASP.NET MVC コントローラクラスなどで、コンストラクタ引数に IConfiguration 型の引数を記述しておくと、フレームワーク側にてこのコントローラクラスをインスタンス化するときに、先に DI 機構に登録されていた IConfiguration 型に対するオブジェクトが、この引数に渡される次第である。

具体的なコード例としては下記のとおり。

public class HomeController : Controller

{

  private IConfiguration Config { get; }



  public HomeController(IConfiguration config)

  {

    this.Config = config;

  }



  public IActionResult Index()

  {

    return View(this.Config["foo"]);

  }

  ...

このコードを実行してみたところ、appsettings.json に「{"foo":"bar"}」が記述されていると、「this.Config["foo"]」は文字列 "bar" を返すことを確認できた。

このように、裏技感は否めないものの、実行時にエントリ名を示す文字列を組み立てて "動的" にアプリケーション構成を読み取ることが、DI 機構に IConfiguration オブジェクトを直接登録してしまうことで実現できた。

階層化されたオプションは?

ところで、appsettings.json が以下のように記述されていた場合、

{

  "layer1":{

    "layer2":{

      "key1":"foo",

      "key2":"bar"

    }

  }

}

いちばん末端の "key2" エントリの値 ( この例では "bar" ) を IConfiguration インターフェース経由で読み取るにはどうすればよいか?

先の HomeController の例でいうと、

this.Config.GetSection("layer1").GetSection("layer2")["key2"]

というコードで取得可能ではある。

しかしこれにはもっと簡易に書ける短縮構文があって、先の JSON の子要素をたどるのにコロン「:」でメンバ名を区切って記述すればそれでアクセス可能だ。

具体的には

this.Config["layer1:layer2:key2"]

で OK である。

GetValue 拡張メソッドも便利

ここまでは IConfiguration のインデクサ構文でアプリケーション構成を参照していた。

しかし参照方法としてはほかにもあり、「GetValue」という拡張メソッドも用意されている。

ここまでの例はすべて文字列としてアプリケーション構成を読み取っていたが、GetValue 拡張メソッドを使えば、

• int や DateTime としてアプリケーション構成を読み取ってそれらの型で返してくれたり、
• 指定した名前のエントリが実在しなかった場合の既定値を併せて指定できたり

など、便利なことも多い。

Microsoft.Extensions.Configuration 名前空間をインポート(using)すれば GetValue 拡張メソッドが使えるようになるので、いちどインテリセンスでどんなオーバーロードバージョンがあるのか眺めてみるのもよいかもしれない。

英字の大文字小文字は区別されない模様

あと、これらアプリケーション構成(オプション)機構は、そのエントリ名に関して、大文字小文字を区別しないようだ。

先の例でいえば、

this.Config["layer1:layer2:key2"]

も

this.Config["LAYER1:Layer2:kEY2"]

も、同じ結果を返す。

これは型付けしたオプション用クラスについても同じで、オプション用クラスのプロパティ名と、appsettings.json に記載されているプロパティ名とが、英大文字小文字が違っていてもバインドされる。

まとめ

IConfiguration オブジェクトを DI 機構に登録することで、実行時にエントリ名文字列を構築してアプリケーション構成を読み取るような要件にも対応できることが確かめられた。

一般的な用途では、基本的には型付けされたオプション機構を用いたほうが利が大きい。
とはいえ、場合・要件によってはここで紹介した技法も役に立つだろう。

以上、ご参考まで。