@jsakamoto

2018年 08月 28日

[解決] スリープからの復帰後、Surface Pro (第5世代) のタイプカバーから文字が打てなくなる

最近、Surface Pro (第5世代) (US配列 Type Cover 込み) を入手、使い始めるようになった。

仕事上、デスクでの作業は外部モニタ + Apple Wireless Keyboard (Bluetooth 接続) をつないで、据え置きで業務を行なっている。

出張時に、Surface Pro 本体と Type Cover だけ持ち出して出かける格好だ。

ところが、入手そうそうトラブルに遭遇してしまった。

本ブログ記事のタイトルのとおり、スリープから復帰後、タイプカバーから文字が打てない状態となってしまうのだ。

再起動以外、復旧しない...

いろいろ試したが、いちどこの現象が発生すると、再起動する以外、復旧しないようであった。

タイプカバーの脱着や、デバイスマネージャからの「Surface Type Cover Filter Device」の削除からの入れ直しも効果無し。

とはいえ、再起動すれば確実に復旧はする。

でも、ちょっと不思議な不具合...

どうしたものかと、いろいろいじってはみたのだが、解決には至らない。

だが、そうやっていじっている内に、この不具合の詳細が見えてきた。

まず、Type Cover それ自体がデバイスとして機能しなくなるわけではなかった。

Type Cover 上のタッチパッドでマウスカーソルは動かしたり、クリックしたりすることは大丈夫なのだ。

さらに加えて、ディスプレイの輝度変更や音量変更などのファンクションキーも動作したのだ。

それ以外の、カーソルキーや文字キー、Caps ロックキーに限って、これらを押しても何の反応も示さない、という挙動なのである。

さらにこの現象発生後、Bluetooth 接続の Apple Wireless Keyboard でも、文字キーに反応しなくなってしまった。

Type Cover のみならず、である。

キーボード入力にかかわるソフトウェアの問題?

ここまできて、これはもしかして、キーボード入力にかかわるソフトウェアが、何か互換性の問題を引き起こしているのでは、と思い至った。

ということで、まずはこの Surface Pro にインストールした、キーボード入力に関わりそうなソフトウェアを思い出しつつ挙げてみた。

- Mouse without Board

- Apple Wireless Keyboard Driver (WinA1314)

- ATOK Passport

- TeamViewer 13 Business

次に、これらを順にアンインストールしてみて、当不具合が解消されるか様子を見てみることにした。

犯人がわかった!

その結果、上記リストの 2つ目、Apple Wireless Keyboard Driver をアンインストールしたところ、嬉しいことにこの不具合現象が解消された。

今にして思えば、文字キー入力を受け付けなくなる現象が、Type Cover のみならず、Apple Wireless Keyboard でも同時発生していた時点で、最有力候補として疑うべきだったかもしれない（まぁ、後知恵バイアスではあるが）。

ということで、ひとまず一件落着といったところであるか。

ただし、デスクトップ環境で、これまで長年使ってきた Apple Wireless Keyboard が併用できなくなると考えた方がよさそうなので（Apple Wireless Keyboard Driver を使っても、スリープ後キー入力出来ない不具合を解消できるかどうか、トラブルシュートしてる精神的余裕がない...）、デスクトップ環境でのキーボード環境をどうしたものか、今後の課題である。

# by developer-adjust | 2018-08-28 18:37 | その他IT系 | Comments(0)

2018年 07月 23日

空のフォルダをコンテンツに含む NuGet パッケージのソースコードを Git でバージョン管理する

何を言っているのかわからないかもしれないが、とにかく記す。

こんな感じの、空のフォルダをコンテンツに含む NuGet パッケージを作ったとする。

この NuGet パッケージを作るための .nuspec ファイルはこんな感じで、

<?xml version="1.0" encoding="utf-8"?>
<!-- 例えばファイル名は Foo.nuspec とか。-->
<package xmlns="http://schemas.microsoft.com/packaging/2012/06/nuspec.xsd">
  <metadata>
    <id>Foo</id>
    <version>0.1.0</version>
    <authors>(authors)</authors>
    <description>(description)</description>
  </metadata>
  <files>
    <file src="Content\" target="Content" />
  </files>
</package>

上記、file 要素で指定している Content フォルダの中に、収録の目的である空のフォルダ "Controllers" を設けてある (下図)。

これで、(nuget.exe が PATH 上にある前提で) "nuget.exe pack Foo.nuspec" を実行することで、空のフォルダをコンテンツに含む NuGet パッケージ "Foo.0.1.0.nupkg" ができあがる。

めでたしめでたし、なのだが...

Git では空のフォルダはバージョン管理下に登録されない

このような NuGet パッケージ作成プロジェクトを Git のバージョン管理下においたとする。

ところがである。

Git はその仕様上、空のフォルダはバージョン管理のリポジトリに登録できないのだ。

なので、このプロジェクトの Git リポジトリを clone すると、空のフォルダ (この例では "Content"、及びそのサブフォルダの "Controllers") が復元されない。

その結果、clone した先の作業フォルダで NuGet パッケージ生成を実行しても、下記のようなエラーになってしまう。

Attempting to build package from 'Foo.nuspec'.
Could not find a part of the path '...\Content'.

Git で空のフォルダをバージョン管理に含める方法

自分が知る限り、Git で空のフォルダをバージョン管理に含める直接的な方法は存在しない。

その代わり、".gitignore" や ".gitkeep" など、何かしらのファイルを配置し、そのファイルを Git バージョン管理に含める事をもって、clone 先でも確実に当該フォルダが作成されるようにする、という回避策が一般的かと思う。

ということで、この NuGet パッケージ作成プロジェクトでも、"Content\Controllers" フォルダに ".gitkeep" を配置し、これを Git バージョン管理に追加してみる (下図)。

そうすると、当然のことながら、このリポジトリの clone 先でも "Content\Controllers" フォルダが再現され、nuget pack コマンドが成功するようになった。

しかし、である。

今度は、できあがった NuGet パッケージに、".gitkeep" ファイルが含まれてしまった (下図)。

これでは、この NuGet パッケージをインストールすると、本当は空っぽのフォルダができあがるのが期待値であるところ、".gitkeep"

ファイルが「ゴミ」ファイルとして配置されてしまう。

exclude 指定してみるが...

それではということで、.nuspec ファイルの指定にて、".gitkeep" を対象ファイルから除外してみた。

  ...
  <files>
    <file src="Content\" target="Content" exclude="**\.gitkeep" />
  </files>
</package>

これでイケるだろうと思いきや、なんと、下記エラーとなってしまった。

Attempting to build package from 'Foo.nuspec'.
Error NU5017: Cannot create a package that has no dependencies nor content.

ぐぬぬ。

exclude 指定でもなく、".gitkeep" ファイルでもなくて...

あーでもないこーでもないと、検索しまくっているうちに、下記の NuGet の Issue にたどり着いた。

なんと、"_._" というファイルは、NuGet パッケージ作成の際に無視されるらしい。

マジか。

半信半疑で下図のとおり配置し、nuget pack コマンドを実行したところ...

ちゃんと、"_._" ファイル抜きで、空のフォルダを含むコンテンツが、.nupkg 内に再現できた！

"_._" ファイルは、Git にとっては何の変哲もない "ただのファイル" に過ぎないので、普通に Git バージョン管理に登録できる。

これで万事解決と相成った。

# by developer-adjust | 2018-07-23 22:33 | .NET | Comments(0)

2018年 06月 29日

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 プロトコルへのリダイレクトが機能するようになった。

以上！

# by developer-adjust | 2018-06-29 19:02 | .NET | Comments(0)

2018年 05月 23日

気が付いたら Visual Studio Code / Visual Studio 2017 IDE で TypeScript の import 文が自動挿入されてた件

import 文をコーディングするのがストレス!

TypeScript による Web フロントエンド実装をコーディングしていての話。

個人的に、長らくの間、import 文を記述するのが億劫でならなかった。

いくらインテリセンス/コード補完があるとはいえ、下記 GIF アニメでわかるように、カレットを右に・左に・また右に、みたく忙しく動かさねばならないからだ。

左から右へ流れるようにタイプするだけの構文だったら、まだ救われたのかもしれないが...。

あと、例えば上記例のように、Angular4+ の HttpClinet サービスを必要とするコンポーネントやサービスをコーディングするときは毎回、この import 文を書かねば HttpClinet 型の参照すらままならず、正直、かなりイライラさせられていた。

あれ、何ですか、この神機能!

ところがである。

ふと、ある日、Visual Studio 2017 IDE を使用して、またしても HttpClient を DI 機構で受け取るコンポーネントのコンストラ引数を (import 文書くより前に、ついうっかり) コーディングしていると、なんと、まだ import していない HttpClient クラスがインテリセンスの候補に挙がってきているではないですか (下図)。

そして、何かの見間違いかと思いつつ、そのまま Tab キー押して候補を確定したところ、なんと、import 文が自動挿入されたのである。

あわてて (常用していない) Visual Studio Code を起動して同じプロジェクトを開いて動作を試してみたところ、Visual Studio Code でも、この、import 前の型の候補表示 & 自動 import 挿入が発動した。

これはきわめて便利!

これまでの import 文コーディングに関する不満が吹き飛んだ。

いつから使えてたのか/どうやって実現してるかは不明のまま放置

この機能はいつのバージョンから使えるようになっていたのだろう?

とりあえず Visual Studio 2017 IDE については、v.15.7 に更新したあたりで気づいたのだが、もっと前からサポートされていたのだろうか?

リリースノートを確認すればはっきりしたことがわかるとは思うが、とにかく、2018年5月時点で最新版の Visual Studio Code 及び Visual Studio 2017 IDE を使っていれば、この機能の恩恵にあずかれるっぽい。

また、この import 前の型の候補表示 & 自動 import 挿入が、どのような仕掛けで機能しているかは、まだよくわかっていない。

packages.json を見てるのか、webpack.config.js を見ているのか、node_modules フォルダ以下をスキャンしているのか、はてさて。

しかし何はともあれ、数字としてタイピング量を減らすという以上に、コーディング時の心理的疲弊をばっちり回避できる、素晴らしい機能だと思った。

※ Atom や Sublime、Vim などなど、そのほかのリッチ系エディタについても、同様のサポートがあるのかどうかは知らない。ご存知の方は、ブログのコメントないしは Twitter 上などでお知らせいただけるとありがたい。

2018/05/25 追記

JetBrains 製の IDE、IntelliJ/WebStorm であれば対応してるよ、とのお知らせを頂戴した。

さすがは JetBrains である。

ところで、この Tweet ― 不要な import を削除する機能 ― を頂戴して、もしかしたら思い、Visual Studio 2017 IDE 上で Ctrl+R, Ctrl+G のキーボードショートカット (これは、C# ソースの編集中における、未使用の名前空間 using 節の削除を行なうショートカット) を打鍵してみたところ、TypeScript の未使用 import 削除としても機能した。

さらには、Visual Studio Code にも、April 2018 (version 1.23) から同様の機能が備わっているとのこと。

Visual Studio Code では、既定のキーバインドだと、Shift+Alt+O で発動するらしい。

TypeScript のソースコード保存時に自動で不要 import 削除を発動させることも、Visual Studio Code の設定で構成可能とのこと。

Visual Studio 2017 IDE でも、たしか、アドインを追加することで、保存時の不要 import 削除を自動化できるかもしれない (自分は未確認)。

# by developer-adjust | 2018-05-23 22:34 | Visual Studio | Comments(0)

2018年 04月 29日

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

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

# by developer-adjust | 2018-04-29 22:33 | その他IT系 | Comments(0)

2018年 03月 26日

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

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 が提供してくれている「プロパティの作成と初期化」クイックアクションをまだ知ってなかった! という稀有な方は、これを機会にぜひ試用してみていただき、ご自身のコーディング人生をより幸せなものにしていただければと願う。

# by developer-adjust | 2018-03-26 22:41 | Visual Studio | Comments(0)

2018年 02月 27日

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

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

注目しておこうと思う。

# by developer-adjust | 2018-02-27 12:39 | .NET | Comments(0)

2018年 01月 29日

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

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 ひとつで完結するように作ることもできると思った (が、やってない)。

[2018-02-01 追記]
早速に .ps1 ひとつで完結する作例の Pull Request をいただいた。

[2018-02-01 追記ここまで]

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

悪しからず。

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

# by developer-adjust | 2018-01-29 23:02 | Visual Studio | Comments(0)

2017年 12月 22日

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

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

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

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

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

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

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

実装の様子

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

using Microsoft.EntityFrameworkCore;

public class MyDbContext : DbContext {
    // ... ここに DbSet<T> 型のプロパティでエンティティ = テーブル を定義
    
    // コンストラクタ
    public MyDbContext(DbContextOptions<MyDbContext> options)
         : base(options)
    {
    }
}

データベースコンテキストを、In-Memory データベースプロバイダの使用を指定して構築するには、下記のコードとなる。

var option = new DbContextOptionsBuilder<MyDbContext>()
    .UseInMemoryDatabase(databaseName: "MyMemDb")
    .Options;

var db = new MyDbContext(option);
db.Database.EnsureCreated();

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

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

実際に 1対多のリレーションを持つようなモデルで、

エンティティへの Add() や AddRaneg() からの SaveChanges() 、
そのあとの Where() や OrderBy() を伴う読み取り、
Include() によるイーガーローディング

などを動作確認してみたが、ちゃんと期待どおりに動作してくれた。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

var option = new DbContextOptionsBuilder<MyDbContext>()
    .UseInMemoryDatabase(databaseName: ...)
    .ConfigureWarnings(opt => {
        opt.Ignore(InMemoryEventId.TransactionIgnoredWarning);
    })
    .Options;

ただし、これで例外を発生することはなくなるが、In-Memory データベースがトランザクションをサポートしていないことには変わりないので注意が必要だ。

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

SQLite の In-Memory データベース

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

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

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

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

データベースコンテキスト構築のコードは下記となる。

var option = new DbContextOptionsBuilder<MyDbContext>()
    .UseSqlite("Data Source=:memory:")
    .Options;

var db = new MyDbContext(option);
db.Database.OpenConnection();
db.Database.EnsureCreated();

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

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

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

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

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

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

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

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

まとめ

EntityFramework Core によるデータベースアクセスを伴うプログラムについて、その単体テスト実装時、揮発性の In-Memory データベースを用いて単体テストを実現する方法としては、以下が挙げられる。

EntityFramework Core ネイティブの In-Memory データベースプロバイダ (Microsoft.EntityFrameworkCore.InMemory) を使う
SQLite データベースプロバイダ (Microsoft.EntityFrameworkCore.SQLite) を用い SQLite を In-Memory データベースモードで使う

前者は、

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

が注意点。

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

# by developer-adjust | 2017-12-22 23:40 | .NET | Comments(0)


	ファン申請 ※ メッセージを入力してください