@jsakamoto

Azure Storage Emulator v.5.9 をインストールするも create database でエラーとなって動かない

Windows OS 上で C# による Azure Functions 開発を行なおうとしての話。

とある事情でまっさらの環境に Visual Studio 2019 をインストールするところから開始。

Visual Studio 2019 のインストーラにお任せで、Azure Storage Emulator (ver.5.9) や SQL Server 2017 Express および LocalDB も自動でインストールされるに任せた。

ということで早速にプロジェクトテンプレートからちゃっちゃっと C# で Azure Function プロジェクトを作り、Ctrl + F5 でビルド & 実行。

Azure Functions は背後で Azure Storage を使っている関係で、開発環境におけるローカル実行時は、Azure Storage Emulator がローカル環境で起動される。

...が、なんとここで想定外に、Azure Storage Emulator がエラーを吐いて起動に失敗してしまった。

エラーの原因は「データベースを作れません」!?

コンソールには以下のとおり出力されていた。

Error: Cannot create database 'AzureStorageEmulatorDb59' : The database 'AzureStorageEmulatorDb59' does not exist. Supply a valid database name. To see available databases, use sys.databases..

Azure Storage Emulator がその永続化層に使用するために、SQL Server LocalDB に "AzureStorageEmulatorDb59" という名前のデータベースを作ろうとするも、何やら上手くいっていないようである。

とりあえずネットで検索してみると、StackOverflow に同様のトラブルでの質問投稿を発見した。

今までこんなトラブルに遭遇したこともなくて、Azure Storage Emulator を使い倒したこともなく知らなかったのだが、上記 StackOverflow のスレッドを見ると、Azure Storage Emulator には様々なコマンドライン引数指定ができるとのこと。

例えば、"/forceCreate" スイッチ付で、"init" を指定することで、データベースが壊れた場合でも再作成・最初期化できるとのこと。

> AzureStorageEmulator.exe init /forceCreate

まずは自分のこのケースでも上記コマンド実行を試してみた。

しかし残念ながら、自分のケースでは表示されるエラーメッセージは変らず。

ちゃんとエラーログを読もう

さらに先の StackOverflow をスレッドを読み進めるに、まぁ、ちゃんとログ読もうぜ、という話らしくて、改めてちゃんと、Azure Storage Emulator のエラーログファイルを見てみることにした。

ちなみに Azure Storage Emulator のエラーログファイルは、下記フォルダに「error.log」というファイル名で保存されている。

%USERPROFILE%\AppData\Local\Microsoft\Microsoft SQL Server Local DB\Instances\MSSQLLocalDB

error.log ファイルの内容を "AzureStorageEmulatorDb59.mdf" で検索してみたところ、下記行を発見。

2019-06-09 11:24:13.15 spid52      CREATE FILE encountered operating system error 5(Access is denied.) while attempting to open or create the physical file 'C:\Users\jsakamotoAzureStorageEmulatorDb59.mdf'.

よーく見ると、作成しようとしているデータベースの物理パスがなんかおかしい。

'C:\Users\jsakamotoAzureStorageEmulatorDb....'

となっているが、あれ、ユーザーフォルダ名 (C:\Users\jsakamoto) とファイル名 (AzureStorageEmulatorDb59.mdf) との間のディレクトリ区切りが無くなってない?

正しくは

'C:\Users\jsakamoto\AzureStorageEmulatorDb....'

じゃないですか?

どうしてこうなった?

原因は SQL Server 側の不具合?

先の StackOverflow のスレッドを見直していると、コメント欄に答えがあった。

Indeed this was the issue. I installed CU13 HotFix for SQL Server 2017 and it works now. – Andrii Mar 8 at 21:07

どうやら CU13 という SQL Server 用の Hotfix で本現象は解消できるらしい。

つまり SQL Server LocalDB 側の不具合だったということだろうか。

ということで上記コメントのリンクをたどりながら下記から CU13 Hotfix をダウンロードして適用すれば直るらしい。

https://www.microsoft.com/en-us/download/details.aspx?id=56128

他の回避策

ただちょっと今回は事情があって、冒頭で "とある事情でまっさらな環境に..." とか書いたように、すぐにダウンロード & インストールできない、特殊な状況であった。

自分がこれまで今回のようなトラブルに遭遇しなかったのも、おそらくはインストールしたての環境ではなくて、ちゃんと最新の Update を適用済みの環境だったからかもしれない。

さておき、今の状況ではこれは詰んだかなー、と諦めようかと思っていたところ、別の回避策を発見。

先にも書いたが、Azure Storage Emulator にはいろいろなコマンドライン引数指定ができるのだが、その中に、永続化層に使用する SQL Server インスタンスを指定する方法があるとのこと。

具体的には、"/server" スイッチに続けて、使用する SQL Server インスタンスを指定して、"init" 動作を指定するらしい。

試しにと言うことで、この環境にインストール済みである、SQL Server 2017 Express のインスタンス (インスタンス名は "SQLEXPRESS") を使用するように、Azure Storage Emulator を構成・初期化してみることにした。

> AzureStorageEmulator.exe init /server .\SQLEXPRESS

すると、CU13 Hotfix が未適用でも、ちゃんと Azure Storage Emulator 用に、データベース AzureStorageEmulatorDb59 が SQL Server 2017 Express 上に作成された。

Windows Azure Storage Emulator 5.9.0.0 command line tool
Attempting to use server specified.
User specified an instance through /server or /sqlInstance options.
Probing SQL Instance: '.\SQLEXPRESS'.
Found SQL Instance .\SQLEXPRESS.
Creating database AzureStorageEmulatorDb59 on SQL instance '.\SQLEXPRESS'.

Granting database access to user MyPC\jsakamoto.
Database access for user MyPC\jsakamoto was granted.

Initialization successful. The storage emulator is now ready for use.
The storage emulator was successfully initialized and is ready to use.

もちろんその後の Azure Functions プログラムのローカル実行も難なく実行されるようになった。

もちろん CU13 Hotfix も有効!

後日、CU13 Hotfix を適用後に、改めて "AzureStorageEmulator.exe init" を実行したところ、こちらも無事成功し、SQL Server LoacDB 上でも正常稼働するようになった。

まとめ

ということで、 Azure Storage Emulator のコマンドライン引数指定、"init" コマンド実行に加えて付属のスイッチ群 "/forceCreate" "/server" などについて知っていると、何かトラブルの際に役立つかも知れない。

以上。

node のバージョンあげたら node-sass の npm instal でこけた話 - windows-build-tools 入れずに解決させる

Windows OS 上で SPA を開発していてのお話。

先日、しばらく前に構築した、とある Web アプリ (SPA) プロジェクトを保守する必要が出てきた。

久しぶりに当該プロジェクトをリモートリポジトリからローカル開発環境に git clone し、とりあえず npm install を実行したところ、いきなりエラーになってしまった。

npm ERR! node-sass@4.7.2 postinstall: `node scripts/build.js`

npm ERR! Exit status 1

npm ERR!

npm ERR! Failed at the node-sass@4.7.2 postinstall script.

どうやら、SaSS を CSS へ変換する Node.js 用ライブラリ node-sass のパッケージインストールでこけたっぽい。

使用している node-sass のバージョンは v.4.7.2。

開発当時はちゃんとクリーンビルド成功してたのに、なんで?

Node.js のバージョンが当時と今とで違う

当該プロジェクトの開発当時と、今回とで環境で変っていたのは Node.js のバージョンだった。

開発当時、インストールされていたのは、たしか Node.js の v.8 系。

現在は Node.js を v.10.15.3 にアップデートしたあとの環境である。

どうも、この Node.js のバージョン違いが、開発当時は問題なくて、現在だと npm install できなくなる原因らしい。

さて、この npm install できなくなる問題をどうにかしないと、本題の保守作業に入ることもままならない。

どうしたものか。

Python や C/C++ の環境が必要?

インターネット検索した感じだと、どうやら、node-sass のバイナリビルドのために、Python 2.x や C/C++ の環境が必要らしい。

で、macOS や Linux 系列だと、だいたい Python や gcc 入ってたりするので、すんなり node-sass のバイナリビルドが済んでしまう模様 (あくまでもネットで聞きかじった情報であるが)。

ところが Windows OS ではそのあたりでひっかかって、node-sass のバイナリビルドができずに npm install がコケて終わり、となるらしい。

たしかに自分の場合も、それっぽいログが表示されていた。

gyp ERR! stack Error: Can't find Python executable "python", you can set the PYTHON env variable.

gyp ERR! stack at PythonFinder.failNoPython (C:\Work\app1\node_modules\node-gyp\lib\configure.js:484:19)

gyp ERR! stack at PythonFinder.<anonymous> (C:\Work\app1\node_modules\node-gyp\lib\configure.js:509:16)

gyp ERR! stack at C:\Work\app1\node_modules\graceful-fs\polyfills.js:282:31

このような場合の定番の解決方法は、「npm install --global windows-build-tools」を実行して、Windows OS 上でもそれらビルドに必要な環境を npm でインストールしてしまえばよいようだ。

でもちょっと待て欲しい。

開発当時は、そのようなビルドツールが未インストールでも、すんなり npm install できていたのだ。

なんでだろう?

ビルド済みバイナリが GitHub 上にある!

いろいろ調べていくうちにだんだんとわかってきた。

まず、node-sass の Node パッケージスクリプトは、常にはバイナリビルドを実行しようとはしない。

まずは node-sass の GitHub リポジトリに登録されている、ビルド済みバイナリのダウンロードを試みるようだ。

そして、ダウンロードしようとしている node-sass のビルド済みバイナリのファイル名の末尾には、対応している Node.js 実行環境の "モジュールバージョン" が含まれていた。

具体的には、Windows OS 用バイナリの場合、
「win32-x64-{ここにモジュールバージョン}_binding.node」
というファイル名になる。

node-sass の GitHub リポジトリで調べてみると、node-sass v.4.7.2 のビルド済みバイナリは、モジュールバージョン 57 まで登録がある。

しかし今回の開発環境 Node.js v.10.15.3 のモジュールバージョンは 64 であった。

ということで、node-sass の GitHub リポジトリには登録のない、"v.4.7.2 で、且つモジュールバージョンが 64" であるビルド済みバイナリのダウンロードを試みて失敗 (HTTP 404 Not Found) となっていたようだ。

(下記はその証拠の npm install ログ表示。)

> node-sass@4.7.2 install C:\Work\app1\node_modules\node-sass

> node scripts/install.js

Downloading binary from https://github.com/sass/node-sass/releases/download/v4.7.2/win32-x64-64_binding.node

Cannot download "https://github.com/sass/node-sass/releases/download/v4.7.2/win32-x64-64_binding.node":

HTTP error 404 Not Found

なお、node-sass の Node パッケージスクリプトは次なる手段としてローカル環境でのバイナリビルドを開始する。

だがしかし自分の環境ではビルド用のツールの整備がなっていないので、これもコケてしまい結局エラーで終了、ということだったらしい。

さて、改めて node-sass の GitHub リポジトリの Release ページを見てみると、ちゃんとビルド済みバイナリが用意済みの、対応されている Node.js バージョンが明記されている。

これを頼りに今回は node-sass v.4.9.0 以降を使用するよう packages.json を更新した。

その結果、自分のローカル環境にビルドツール類をインストールすることなく、無事 npm install が成功するようになった。

まとめ

ということで、Windows OS 上で、必ずしも windows-build-tools Node パッケージの利用をはじめビルドツールの整備をしなくても、node-sass のバージョンを適切にアップデートしていけば、すんなり npm install を通すことはできる、という話。

なお、Node.js のいつのバージョンからかよく覚えていないが、最近の Node.js Windows 版のインストーラーでは、ビルドツールも一緒にインストールするかどうかの選択肢が出てきてるっぽい。

この選択肢を有効にして Node.js をインストールしてある環境ならば、このような node-sass を npm install できない問題は起きないのだろうか。

検証したことはないが、気になるところである。

.NET HTTP REPL を使ってみた

".NET HTTP REPL" とは?

.NET HTTP REPL とは、.NET Core 上で動作するコマンドラインツール。

既存のコマンドラインツールで類似なものを挙げるとすれば、curl や wget が近いだろうか。

すなわち、コマンドプロンプト (ターミナル) 上から指定した HTTP 要求を送信し、返信されてきた応答を表示する類いの CUI (コマンドライン ユーザー インターフェース) プログラムである。

しかしながら、このツールの名前に "REPL" と付いているように、基本的に対話形式で使用する形態となっているのが .NET HTP REPL の特徴である。

REPL (Read-Eval-Print Loop) とは、入力・評価・出力のループのこと。主にインタプリタ言語において、ユーザーとインタプリタが対話的にコードを実行する。
出典: フリー百科事典『ウィキペディア（Wikipedia）』

ちなみに、.NET HTTP REPL のソースコードは GitHub 上の AspLabs というリポジトリでホスティングされており、Apache 2.0 ライセンスで公開されている。
このリポジトリの README には、"Repo for ASP.NET experiments that are not ready for a production release." と書かれており、この先どうなるか、心配すべきかわくわくすべきか迷うようなプロダクトが詰め込まれているように感じた。

ということで、実は .NET HTTP REPL は本記事を投稿の時点では公式リリース版ではなくプレビュー扱いである。

適宜注意されたし。

.NET HTTP REPL のインストール

さて、.NET HTTP REPL を使用するには、まずは .NET Core SDK のインストールが必要である。

.NET Core SDK がインストールされ、コマンドプロンプト (ターミナル) 上から dotnet コマンドが実行可能になっていれば、.NET HTTP REPL のインストールは以下のコマンドを実行すればよい。

> dotnet tool install --global dotnet-httprepl --version 0.1.0-preview.19119.4

このようにすることで、dotent Global Tools として nuget.org 経由で .NET HTTP REPL 本体がダウンロード、インストールされる。

これで .NET HTTP REPL が使えるようになる。

.NET HTTP REPL の起動・使い方

.NET HTTP REPL は dotnet コマンドのサブコマンドという形態で実装されている。

そのため、コマンドプロンプト (ターミナル) から以下のコマンドを実行することで起動され、.NET HTTP REPL の対話モードに入る。

> dotnet httprepl

最初に書いたとおり、.NET HTTP REPL は対話形式で使用する、HTTP 要求を送信するツールである。

まずは送信先 HTTP サーバーのホスト、プロトコル、ポートを、"base" という HTTP 要求送信の基点として設定しておく必要がある。

これは、.NET HTTP REPL の対話モードのコンソールにて、以下のように "set base" コマンドで設定する。

~ set base http://localhost:50893/

base 設定が完了すると、.NET HTTP REPL のプロンプトも "(Disconnected)~" から "http://localhost:50893/~" というように設定された base に変る。

こうして base 設定が済んだら、あとは、HTTP 動詞と同じ名前で用意されているコマンドを入力すればよい。

例えば、URL = api/SampleData/WeatherForecasts に HTTP GET 要求を送信する場合は下記のような感じで、割と直感的に使える。

~ GET api/SampleData/WeatherForecasts

HTTP サーバーからの返信結果は、例えば JSON 形式で返された場合はよしなに色づけ・書式化されて表示される。

当然 POST をはじめ、PUT, DELETE などの HTTP 動詞を送信するも可能で、また、POST や PUT で JSON コンテンツを送信したい場合は、-c スイッチに続けて送信したいコンテンツを記述すればよい。(以下は「ちょまど問題サーバー」に回答を送信して正答数を得る例)

POST https://chomado-problem-server.azurewebsites.net/answer -c [1,2,4,4,1,2,3,4,1,2]

対話モードを抜けて .NET HTTP REPL を終了するには exit コマンドを実行すればよい。

~ exit

.NET HTTP REPL には cd コマンドがある

さて .NET HTTP REPL のおもしろいところとして、対話形式のツールであることから状態が持てるので、"cd コマンド" が用意されていることが挙げられる。

つまり、HTTP 要求送信先 URL をスラッシュ区切りとしてディレクトリに見立てて、"現在ディレクトリ" を移動できる、という仕組みである。

例えば以下のように api/SampleData "ディレクトリ" まで、cd コマンドで "降りて" いれば、

~ cd api/SampleData

GET コマンドで api/SampleData/WeatherForecasts に要求送信するには、前半の api/SampleData を省略した、WeatherForecasts だけを送信先 URL として記述すればよい。

/api/SampleData~ GET WeatherForecasts

"現在ディレクトリ" は .NET HTTP REPL のプロンプトに表示されているほか、引数なしの cd コマンドを実行することでも表示される。

特定のリソースを指す REST 風な Web API に対して読み書き操作を色々試したいときなど、cd コマンドで URL の共通部分まで、あらかじめ "降りて" おけば、入力の手間が省けて良さそうな感じである。

※2019/04/22現在、cd コマンドが例外を発生させることがある (当方の環境。.NET Core 3.0 Preview 4)。但しとりあえず .NET HTTP REPL は動作継続し、cd コマンドによる "現在ディレクトリ" の変更は行なわれているようである。

Swagger にも対応!?

.NET HTTP REPL の対話モードで help コマンドを入力すると、どんなコマンドがあるのかヘルプ表示される。

これを見ると、まだ試せていないのだが、"set swagger" というコマンドもあるようで、どうやら Swagger 形式の Web API 定義 JSON を読み込んで便利に使えるようだ。

また、run コマンドによって "スクリプト" を実行できる、ともある。

これもまだ試せていないので、具体的にどのように使えるものなのか現時点ではわかっていないのだが、興味を引かれるところである。

感想

.NET HTP REPL は、REPL と名前についているとおり対話形式で使用するものであり、起動時のコマンドライン引数で何か実行するということはどうやらできない模様だ（もしかしたら、スクリプト機能などで可能なのかもしれないが、まだよくわかっていない）。

そういう用途では、やはり curl などのほうが使えるということになりそうだ。

また、最近の Windows 10 OS には curl コマンドも標準で入るようになったので、自分がわかっている範囲だけでも、macOS/Linux各種ディストリ/Windows などなど、幅広い OS で使えるのも curl の良いところだろう。

他方、.NET HTTP REPL であるが、サーバーから返信された JSON コンテンツを、インデント付きで書式化・色づけして表示してくれるので、サーバー応答の JSON が読みやすいと感じた。

しかしながら、curl コマンドと jq コマンドの組み合わせ技のように、サーバー応答の JSON をフィルタしたり射影したりなどの凝った加工は、.NET HTTP REPL にはできないように見受けられる。

個人的には .NET HTTP REPL が直感的に使えるところが気に入った。

"GET /api/..." のように、自分が Web ブラウザになった気分で HTTP 要求を発行できるのが心地よい。

また、cd コマンドによる "現在ディレクトリ" の概念もおもしろいところだと思う。

さらに今後、Swagger 対応の機能の使い方がわかれば、もっと強力に使えるツールとなるかもしれないと期待もしている。

各種自動化やシェルスクリプトの記述などにおいては、相変わらず curl の出番となると思う。

そのいっぽうで、Web アプリ開発中に臨時的に Web API 呼び出しを試してみたいときなど、対話形式での使用のほうがよいケースでは、積極的に .NET HTTP REPL を使いそうな気がしている。

PowerShell の Invoke-WebRequest や Invoke-RestMethod は... うーん、自分が書く自動化系のスクリプトは PowerShell が俄然多いのでそういう PowerShell スクリプトファイル内ではよく登場するものの、今回の .NET HTTP REPL 的な、臨時的・対話的用途には、自分の手にはなじまなかったです、はい。

C# プログラムでの Excel シートの複製 (コピー) がうまくいかず ClosedXML から EPPlus に乗り換えた話

Excel ファイル (.xlsx) を、C# プログラムから読み書きするときの話。

C# プログラム (というか、.NET 系言語) から Excel ファイル (.xlsx) を読み書きするためのライブラリとして、自分はこれまで、ClosedXML を愛用してきた。

ClosedXML を使用してきた格別の理由があったわけではないが、大して公式ドキュメントに目をとおさずとも、自分の予想どおりな感じで使える API 体系がなじんだのかなと思う。

ClosedXML の限界(?) に遭遇!

さてそんな ClosedXML だが、自分のとある要件の用途で、利用に堪えない制限があることが、最近になってわかった。

Excel ファイル中のシートをコピー (複製) したときに、シェイプ (図形) がコピー先に複製されないのだ。

具体的にはこんな感じのコードで、シート「Sheet1」を、シート名「Sheet2」として複製したとする。

using (var book = new ClosedXML.Excel.XLWorkbook(bookPath))

{

book.Worksheet("Sheet1").CopyTo("Sheet2");

book.SaveAs(bookPath);

}

そうしてできた Excel ファイルを MS Excel などで開いてみると、「Sheet1」にはあった図形 (シェイプ) が、「Sheet2」には複製されていないのだ (画像は複製されている)。

ここでの詳細は割愛するが、ClosedXML におけるシート複製のソースコードに目をとおした感じだと、シート中に含まれる様々なオブジェクトを列挙しつつ複製先のシートにそれらオブジェクトも複製していく実装になってるっぽいのだが、その複製処理のなかに、そもそもシェイプは対象として含まれていないように読めた。

代替案 - EPPlus

さてどうしたものかな、と思案するに、.NET プログラミングにおける Excel ファイルの読み書きライブラリとして著名なもうひとつのライブラリ、EPPlus の存在を思い出した。

EPPlus を使った場合の Excel シートを複製する C# プログラムは、以下のような感じとなる。

using (var package = new OfficeOpenXml.ExcelPackage(new FileInfo(bookPath)))

using (var book = package.Workbook)

{

book.Worksheets.Add("Sheet2", book.Worksheets["Sheet1"]);

package.SaveAs(new FileInfo(bookPath));

}

EPPlus を使った上記コード例であれば、期待どおり、「Sheet1」に含まれる図形 (シェイプ) も、複製先のシートに複製された。

このような顛末から、今回案件では ClosedXML から EPPlus への乗り換えを行なった。

以上の動作を確認できるソースコード一式を GitHub に掲載しておいた。

補足

乗り換えではなくて ClosedXML に対し、図形 (シェイプ) も複製されるようにプログラム変更する貢献をすることも選択肢にはあり得た。

しかしながら今回は少々急いでいたこともあり、ClosedXML への貢献ではなく EPPlus への乗り換えで済ませる選択肢をとった。

ということで、また、さすがに同様の件は、既に誰かが Issue あげてて対応が将来版で計画されているのではないかという気もしてて、ClosedXML には Issue すら報告していない。

それはいわゆる OSS に対する "タダ乗り" ではないか、という後ろめたさもあるのだが、そうはいっても取り急ぎ目先の問題を解消しなくてはいけない場面もある訳で (今回がまさそうだ)、また、OSS 全般という見方をすれば自分なりに活動はしているつもりなので (今回は取り上げなかったが、かつては C# から Excel ファイルを読み書きするときの定番であったライブラリ「NPOI」には、少しばかりだが contribute していたこともあり)、そこは大目に見てもらいたいなと考えている次第である。

なお、ClosedXML は MIT、EPPlus は LGPL でライセンスされているようなので、必要であればこの点の考慮をお忘れ無く。

ASP.NET Core Web アプリプロジェクトで、Node.js 使わずに Sass (SCSS) をコンパイルする

.NET Core SDK 環境のみで Sass (SCSS) をコンパイルする

C# による Web アプリ・サーバー側実装のフレームワーク ASP.NET Core を使った、Web アプリプログラム開発での話。

最近はフロント側を Angular で書くようになったため、Sass (SCSS) を CSS にコンパイルするのは、webpack によるモジュールバンドリング処理の一環として webpack の loader で行なう必要があり、実際そのようにしている。

しかし他方、Angular などのフロント側フレームワークに依らない、静的なちょっとした Web サイト作成や、C# でフロント側を実装する Blazor のようなフレームワークを使うケースでは、Sass (SCSS) ファイルを css ファイルにコンパイルする方法は、必ずしも webpack に頼る必要はない。

実のところ、.NET Core プロジェクトのビルドシステムにおいては、nuget.org で公開されているライブラリ (NuGet パッケージ) による支援もあって、Sass (SCSS) を css にコンパイルすることが可能だ。

.NET Core SDK さえ開発マシンにインストールされていれば、Node.js などがインストールされていなくても、Sass (SCSS) コンパイルが可能なのである。

ただ、現時点では .NET Core プログラムのビルドの一環として Sass (SCSS) コンパイルを実施することが可能、という状況なので、プロジェクトファイル (.csproj など) が必須である。

実際にやってみる

.NET Core プログラムのビルドの一環として Sass (SCSS) コンパイルを実施するには、まず、以下の NuGet パッケージを当該プロジェクトにパッケージ参照追加する。

dotnet CLI であれば、対象プロジェクトがあるフォルダをカレントディレクトリにして、下記を実行すればよい。

> dotnet add package BuildWebCompiler

Windows OS 上で Visual Studio を使っている場合は、GUI のパッケージマネージャから追加してもよいだろう。

次に、対象プロジェクトのルートフォルダに以下のような内容の設定ファイル "compilerconfig.json" を作成する。

[

{

"inputFile": "wwwroot/css/test.scss",

"outputFile": "wwwroot/css/test.css"

}

]

以上で設定完了だ。

上記 compilerconfig.json の inputFile で指定した Sass (上記例だと SCSS 形式だが) ファイル "wwwroot/css/test.scss" を作成し、ビルドを実行する。

そうすると、この Sass (SCSS) ファイルがコンパイルされて、outputFile で指定されたファイル名の CSS ファイルが出力されるのが確認できるはずだ。

さらにオマケとして、出力先 css ファイルは、そのミニファイ版も同時に生成される（ファイル名は .../test.min.css となっている）。

compilerconfig.json にどのような記述ができるかは、あまり詳しいリファレンスは見つけていないものの、先の NuGet パッケージの GitHub リポジトリにある README (下記 URL) が参考になる。

https://github.com/madskristensen/WebCompiler#compilerconfigjson

このように、.NET Core SDK 環境だけでも、プロジェクトのビルドの一環として、Sass (SCSS) ファイルを css にコンパイルすることが可能である。

ちなみにこの BuildWebCompiler NuGet パッケージ、実は Sass (SCSS) -> css コンパイルのみならず、LESS や CoffeeScript などなど、様々な変換が可能だ。

自分では実際には試したことがないが (※CoffeeScript 書くスキルがない...)、もし需要があるなら試してみるとよいかもしれない。

Sass (SCSS) -> CSS コンパイルだけ実行する

ビルド時に Sass (SCSS) -> CSS コンパイルができるようになったが、しかしながら開発中は、.scss を編集するだけでいちいちプロジェクト全体をビルドはしたくないところである。

dotnet CLI を使うなら、対象プロジェクトがあるフォルダ上で下記 dotnet コマンドを実行することで、Sass (SCSS) -> CSS コンパイルだけを実施することが可能だ。

> dotnet msbuild -t:WebCompile -nologo

ウォッチ

さらにできれば、.scss ファイルを保存したら自動で .css にコンパイルしてくれたら嬉しい。

そのためのやり方のひとつとして、「ファイルの変更を監視し、変更されたらタスク (この場合は .scss > .css のコンパイル) を実行する」という "ウォッチ" 方式がある。

このウォッチ方式による .scss > .css 自動コンパイルの実現は、dotnet CLI のウォッチ機能を利用することで可能となる。

ただし残念ながら自分が知る限り、ちょっとだけ事前の手順が必要。

まず対象プロジェクトファイルをテキストエディタで編集し、下記の要領で .scss ファイルを監視対象に含めるようプロジェクトを構成する必要がある。

<Project Sdk="Microsoft.NET.Sdk.Web">

...

<ItemGroup>

...

<Watch Include="wwwroot\css\*.scss" /> <!-- この行を追加 -->

</ItemGroup>

...

上記変更を施したら、対象プロジェクトがあるフォルダ上で下記 dotnet コマンドを実行することで、ファイル変更の監視を行なう dotnet CLI が常駐する。

> dotnet watch msbuild -t:WebCompile -nologo

この状態で .scss ファイルを上書き保存すると、.scss > .css コンパイルが実行されるようになる。

なお、dotnet CLI の watch 機能は、監視対象のファイルを状況に応じて使い分けることが難しいようで、例えばこの状態で、同プロジェクトに含まれる C# ソースコード (.cs ファイル) を上書き保存しても、.scss > .css コンパイルが走ってしまう。

dotnet CLI の watch 機能を、このプロジェクトでは .scss > .css コンパイルにしか使わない、という場合は、プロジェクトファイルに以下のとおり追記して、C# ソースコードファイルを監視対象から除外することが可能だ。

<Project Sdk="Microsoft.NET.Sdk.Web">

...

<ItemGroup>

...

<Compile Update="**/*.cs" Watch="false" /> <!-- この行を追加 -->

</ItemGroup>

...

IDE/エディタの拡張機能もあるが...

以上ここまで、.NET Core SDK 環境で、プロジェクトのビルドの一環として Sass (SCSS) を CSS にコンパイルする方法について説明してきた。

なお、Sass (SCSS) を CSS にコンパイルする方法としては他にも、Visual Studio のような IDE や、Visual Studio Code などのエディタにおける「拡張機能」を利用することもできる。

実際、Windows OS 上で Visual Studio を使う場合は下記拡張を Visual Studio にインストールしておくと、Visual Studio 上での .scss ファイルの編集・保存時に .css へのコンパイルが実行されるようになる。

実のところ、これまで説明してきた、.NET Core アプリプロジェクトのビルド時に Sass (SCSS) コンパイルが実行されるやり方で使用した に BuildWebCompiler NuGet パッケージと上記 Visual Studio 拡張は同じコードベースで作られている。

そのため、先に説明した compilerconfig.json の設定を読んで同じように動作するので大変使い勝手が良い。

あと、同じ理由で、この Visual Studio 拡張も Sass (SCSS) のみならず LESS やら CoffeeScript やらもファイル保存時のコンパイルが可能だ。

また、Visual Studio Code であれば、下記の拡張が人気があるようだ。

このように、IDE やエディタの拡張機能を用いることで、.scss ファイル保存時に自動で .css にコンパイルすることができるようになり、このほうが開発者体験としてはより良いように感じる。

とはいえ、開発メンバー全員の IDE/エディタ環境を揃えるのが手間だったりうまくいかないことがあるかもしれない。

開発環境を再構築後に、うっかり拡張を入れ忘れてしまい、.scss を変更・保存したけれども、対応する .css が更新されずしまい、というバグだって引き起こしてしまうかも知れない。

そうしたケースに備える目的で、ソースコードをリポジトリから git clone するだけで、開発環境への各種拡張の追加インストールすることなく、最低限ビルドすればちゃんと .scss が .css にコンパイルされるようになるのは、これはこれで便利で大事なことだと思う。

補足

これまでの説明では、あくまでも .NET Core アプリ開発としての説明としてきたが、実は BuildWebCompiler NuGet パッケージは、.NET Framework のプロジェクトに追加しても同じように動作する。

これまでの説明における dotnet CLI を使った用法はできないが、Visual Studio 上で .NET Framework 用アプリ開発時でも、同じようにビルド時に Sass (SCSS) ファイルを CSS ファイルにコンパイルすることが可能となる。

Angular + SignalR な Web アプリで、HubConnection.invoke() 時の変更検知発動を抑止する

背景

サーバー側は ASP.NET Core 2.1、クライアント側は Angular 5.2.5 を使用し、さらにここに SignalR (JavaScript クライアントは 1.0.4) を加えてライアント/サーバー間でのリアルタイム通信を行なう Web アプリ実装における話。

SignalR は、Node.js で言うところの Socket.IO に相当するようなライブラリ。

ASP.NET Core Web アプリに、ブラウザを含めたクライアントへのプッシュ通信など、リアルタイム Web 機能を実現できるようにするものだ。

クライアント（ブラウザ）側では、サーバー側からのプッシュ通信を待ち受け（ハンドラ関数を登録しておく）するほか、SignalR の通信チャンネルを通じてサーバー側を呼び出すこともできる。

具体的には、クライアント（ブラウザ）側の JavaScript コードにて、SignalR の通信チャンネルを表す HubConnection オブジェクトの invoke メソッドを呼び出すことで実装する。

HubConnection.invoke() で発生する変更検知を debounce したい!

さて、SignalR を使用して、クライアント/サーバー間通信を頻繁に行なう、クライアント側は Angular を採用した SPA 実装を行なっていると、ちょっと処理速度性能的に問題となることがある。

あまりに頻繁に SignalR の HubConnection.invoke() を呼び出す必要があると、Angular の変更検知処理が都度都度走ってしまい、アプリが重くなってしまうのだ。

そのため、Angular の NgZone の機能を使い、HubConnection.invoke() 呼び出し時の Angular の変更検知発生を明示的に抑止し、デバウンス処理などを自前で組み込むことにしていた。

前提知識: Angular の変更検知を走らせないようにする方法

下記記事が参考になる。

記事タイトルは「Angularの外部でイベントが発生した時の変更検知の方法」だが、「逆に Angular に変更検知をさせたくない場合」の節に変更検知を抑止する方法が記載されている。

具体的には、NgZone オブジェクトを DI 機構で受け取っておき、その上で、変更検知を走らせたくない処理を、NgZone.runOutsideAngular() メソッドのコールバック内で実行すればよい。

HubConnection.invoke() での変更検知を抑止

さて、SignalR の HubConnection.invoke() 呼び出し時、Angular の変更検知を走らせないようにするには、結論としては以下の3点。

1. SignalR の接続開始処理 (HubConnection.start()) を、NgZone.runOutsideAngular() 内で実行する
   
2. HubConnection.invoke() を NgZone.runOutsideAngular() 内で実行する
   
3. HubConnection.invoke() の呼び出し結果を、async/await ではなく .then() による Promise メソッドチェーンで処理する
   

なぜ async/await してはいけないか?

上記 3 の「async/await 使うな」についてはちょっと説明が要るかもしれない。

上記 3 を記載したのは、NgZone.runOutsideAngular() を使って変更検知抑止を実施したとしても、その処理を内包している async 関数の Promise が解決されるときに、結局変更検知が走るからである。

もっとも、その async 関数自体をさらに NgZone.runOutsideAngular() 内で実行すればこれまた変更検知は抑止できるので、絶対に async/await を使ってはいけない、と単純に言えるものではない。

また、もしかしたら、「とある async 関数 foo 内での HubConnection.invoke() 呼び出し時は、変更検知は抑止したいが、それら処理がひととおり終わって async 関数 foo から抜け出したら、変更検知が走って欲しい」というケースのほうが多いかも知れない。

そのような要件・シナリオの場合は、むしろ async/await で実装したほうが、コードも読みやすいし、期待した動作結果・挙動となることと思う。

start() と invoke()、片方だけ runOutsideAngular しても効果無し

ちなみに、HubConnection.start() と、HubConnection.invoke()、いずれか片方だけ NgZone.runOutsideAngular() 内で実行しても変更検知は走ってしまう。

特に HubConnection.invoke() だけ NgZone.runOutsideAngular() 内で実行した場合、変更検知は抑止されず、しかし変更検知のタイミングが invoke() の結果処理後にずれこみ、レンダリング内容に反映されないなど面倒なことになるようだ。

いっぽう、 HubConnection.start() を NgZone.runOutsideAngular() 内で実行しておいた場合は、

• HubConnection.invoke() をそのまま実行した場合は従来どおり変更検知が実施され、
  
• HubConnection.invoke() を NgZone.runOutsideAngular() 内で実行した場合は変更検知が抑止される、
  

という具合に呼び分けられるようになる。

つまり、SignalR 通信に関して Angular 変更検知を抑止するつもりなら、HubConnection.start() を NgZone.runOutsideAngular() 内で実行しておくのが肝要なようだ。

注意: HubConnection.on() で登録したハンドラ関数実行時の変更検知も抑止されてしまう

しかしながら、前述の変更検知抑止処置 ― HubConnection.start() をNgZone.runOutsideAngular() 内で実行 ― をしてしまうと、サーバー側からのプッシュ通信を受け取るハンドラ関数呼び出し (HubConnection.on() で登録したコールバック関数の実行時) についても、一切、変更検知が走らなくなってしまう。

より正確に言えば、HubConnection.on() だけではなく、HubConnection.onclose() コールバックでも変更検知は発生しなかった。

これらコールバックでも変更検知を発動させるには、面倒だが、ハンドラ関数内で個別に NgZone.run() 呼び出しを使って明示的に変更検知を走らせるほかないようだ。

もっとも、「SignalR 通信のサーバー側プッシュのハンドラでは、 Angular 変更検知を抑止したい」ということであれば、HubConnection.start() をNgZone.runOutsideAngular() 内で実行すればよい、ということでもある。

コード例

実際のコード例を GitHub にあげておく。

とくにクライアント側コード例の抜粋を以下に貼っておく。

ASP.NET Core Web アプリの開発中、開発機の外から接続できるようにする

背景

Visual Studio や dotnet CLI + お好みのエディタなどを使っての、ASP.NET Core Web アプリを開発中の話。

開発中の ASP.NET Core Web アプリを、エミュレータではない実機のモバイル端末 (iOS や Android など) から接続して動作確認したいことはよくある。

その実現方法としては、例えば ngrok を使ってローカル開発中の ASP.NET Core Web アプリをインターネット上に晒し、そこにモバイル端末実機のブラウザから接続しにいくのもアリではある。

とはいえ、開発途上のものを、一時的とはいえインターネット上に晒すのは危険が伴う。

そもそも通信経路が長くなる上、ngrok の処理性能やモバイル回線の速度・帯域にも大きく左右されて、すばやい動作確認、トライ&エラーの繰り返しがやりにくい。

ということで、顧客に見てもらうなどの理由がない限りは、開発機と同一ローカルエリアネットワークに Wi-Fi 接続したモバイル端末実機から、同ネットワーク経由で接続するのが普通かと思う。

ただ、ASP.NET Core Web アプリの既定のプロジェクト構成では、開発中の ASP.NET Core Web アプリはローカルホスト (127.0.0.0/24, ::1) でしか待ち受けしていない。

なので、当該開発機の外部からは、そのままでは接続できない。

そこで、プロジェクト構成を変更する必要がある。

Visual Studio 上からの設定変更

Visual Studio で開発中の場合、お勧めの方法は以下のとおり。

1. まず実行形態を、IIS Express によるホスティングではなく、プロジェクト実行 (いわゆる、"dotnet run" 実行) を選択しておく。
   
2. Visual Studio 上で当該 ASP.NET Core Web アプリプロジェクトのプロパティ表示を開き、[デバッグ] カテゴリを開く。
   
3. この画面で、[ブラウザを起動] の設定で、「https://localhost:5001」というような絶対 URL を明記。
   
4. 続けて [環境変数] のところに、[名前] が「ASPNETCORE_URLS」である項目を追加、[値] には「https://*:5001;http://*:5000」というように、ホスト名を 「*」で指定した待ち受け URL を、複数ある場合はセミコロン (;) 区切りで設定する。
   
5. [アプリケーション URL] の欄は空欄にする。
   

以上で Ctrl+F5 で実行などすれば、当該開発機の外部からも、この ASP.NET Core Web アプリが接続を受理、応答を返すようになる。

なお、上記で行なった設定内容は、Properties フォルダ内にある、「launchSettings.json」というファイル名の JSON ファイルにその設定内容が保存されている。

例えば次のとおり。

{

"iisSettings": ...,

"profiles": {

"IIS Express": ...,

"WebApplication1": {

"commandName": "Project",

"launchBrowser": true,

"launchUrl": "https://localhost:5001",

"environmentVariables": {

"ASPNETCORE_URLS": "https://*:5001;http://*:5000",

"ASPNETCORE_ENVIRONMENT": "Development"

},

"applicationUrl": ""

}

}

}

"dotnet run" で実行する場合

dotnet CLI を用いた "dotnet run" による実行でも、上記 launchSettings.json に基づいて ASP.NET Core Web アプリを立ち上げる。

なので、 dotnet CLI を使っての開発中の場合でも、上記のように launchSettings.json を作成・記述しておけばそれだけでよい。

また、先の説明では端折ってしまったが、設定のキモは、環境変数 ASPNETCORE_URLS の設定である。

標準のプロジェクトテンプレートで作成された ASP.NET Core Web アプリであれば、環境変数 ASPNETCORE_URLS を見て、そこに設定されている待ち受け URL を採用するようにできているのだ。

先で説明している launchSettings.json の内容も、要するに環境変数 ASPNETCORE_URLS を設定しているわけである。

なので、launchSettings.json がなくても、コマンドプロンプト (ターミナル) で下記のように環境変数 ASPNETCORE_URLS を設定してから dotnet run を実行することでも OK だ。

> rem 以下は Windows OS のコマンドプロンプトでの例

> cd \path\to\yourprojectdir

> set ASPNETCORE_URLS=https://*:5001;http://*:5000

> dotnet run

※ "dotnet run" を実行したコマンドプロンプト (ターミナル) 内で環境変数 ASPNETCORE_URLS を設定しつつ、 launchSettings.json でも環境変数 ASPNETCORE_URLS を設定していた場合は、 launchSettings.json の設定のほうが優先する。

補足: アプリケーション URL を設定すればよいのでは?

ホストアドレスに「0.0.0.0」を指定

実は、Visual Studio での設定時、環境変数 ASPNETCORE_URLS ではなく、[アプリケーション URL] に、「https://0.0.0.0:5001;http://0.0.0.0:5000」というように、ホストアドレスを「0.0.0.0」とした待ち受け URL を設定することでも、外部からの接続を受け付けるようになる。

但し上図の設定だと、IPv4 アドレスでのみ待ち受けすることになるので注意。

すなわち、開発機上のブラウザでアドレスバーに「https://localhost:5001」や「http://127.0.0.1:5001」と入力するぶんには当該 Web アプリにアクセスできるものの、IPv6 アドレスである「https://[::1]:5001」を入力すると、接続不能となるのである。

まぁ、「開発中の Web アプリをモバイル端末実機で確認」という用途であれば、IPv4 アドレスのみでの待ち受けで十分事足りる気もする。

なので、実際上は、上図のようなアプリケーション URL 設定による方式で十分かもしれない。

もっとも、IPv6 アドレスでも待ち受けさせることももちろん可能で、その場合はホストアドレスとして「[::]」を指定すればよい。

例えば「https://0.0.0.0:5001;http://0.0.0.0:5000;https://[::]:5001;http://[::]:5000」というようにアプリケーション URL を設定すれば、IPv4 でも IPv6 でも、外部からつながるようになる。

ただ、ちょっと設定が長すぎではある。

アプリケーション URL 設定で、ホストアドレスに「*」を指定しないのはなぜ?

アプリケーション URL 設定に、（環境変数 ASPNETCORE_URLS での設定と同じように）「https://+:5001」とか「https://*:5001」 のように、ホストアドレスとして「+」や「*」を指定すれば、 IPv4 と IPv6 の設定を併記しなくて済むのでは? とも思われた。

試しにやってみたところ、 launchSettings.json を直接編集して "applicationUrl" に "https://*:5001" を設定し、dotnet run で実行するぶんにはうまくいった。

しかし launchSettings.json がこの状態で、当該プロジェクトを Visual Studio で開き、Ctrl+F5 実行すると、「Invalid URI: The hostname could not be parsed.」というエラーメッセージボックスを表示して起動してくれない。

また、Visual Studio 上からは、アプリケーション URL に + や * をホストアドレスとした URL を設定すると入力検証エラーになって設定できない。

加えて、先のとおり launchSettings.json を直接編集した状態でプロジェクトのプロパティ画面から [デバッグ] セクションを開いてしまうと、場合によっては入力検証エラーに阻まれ、プロパティ画面を閉じたり保存したりができなくなり、どうにもならない "詰んだ" 状況に陥ってしまう。

...これらのことから、環境変数 ASPNETCORE_URLS に待ち受け URL を設定する方式がいちばん一貫性もあり、自分のお勧めの方法と結論づけている。

補足: [ブラウザを起動] の URL を明記するのはなぜ?

dotnet run で実行するぶんには、 launchSettings.json の "launchUrl" は無くても (あるいは空文字であっても) なんら問題ない。

本稿作成時点では、dotnet run では、ブラウザの起動までは行なわないからだ。

しかし Visual Studio 上で開発・実行してブラウザも開きたいというケースでは、[ブラウザを起動] の URL を明記しておかないと厄介なことになる。

まず、環境変数 ASPNETCORE_URLS に待ち受け URL を設定する方式の場合、Ctrl+F5 実行すると、Web アプリのプロセスは起動するものの、Visual Studio がエラーメッセージボックスを出してブラウザ起動に至らない。

また、アプリケーション URL にホストアドレス 0.0.0.0 で設定する方式の場合、Ctrl+F5 実行すると、ブラウザは起動するものの、「https://0.0.0.0:5001」という URL を開いてしまってアクセスできない結果となる。

なので、少なくとも Visual Studio 上での実行でブラウザも同時に開きたいケースでは、ちゃんと [ブラウザを起動] の URL を明記しておくに越したことはない。

補足: IIS Express での実行時について書かれてないけど?

需要と余力があれば調べて試して本ブログに投稿する...かもしれない。

はじめての C# からの Selenium、そして NET Core ではエラーになる場合

Selenium とは

ここで言う Selenium とは、Web ブラウザをプログラミング言語から自動操縦することを可能にするソフトウェアだ。

npm パッケージのバージョンを上げてたら webpack 実行時に _ValidationError2.default 例外が発生

JavaScript を webpack を使ってモジュールバンドルする、そんな SPA な Web アプリ開発の話。

個人的には早く Blazor に移行したくてたまらない今日この頃であるが、仮に Blazor が公式リリースされたとしても、これまで開発した webpack な JavaScript 製 SPA の保守は必要である。

さて、今回、そのような事情から、過去に作ったプロダクトの保守が発生した。

折角の保守の機会なので、60本ほど参照している npm パッケージを確認し、せめてパッチバージョンくらいは更新しておこう、とちまちま参照 npm パッケージのバージョンを、場合によってはマイナーバージョンも含めて手作業で上げていった。

(※ ncu は知ってるけど、諸事情により今回は出番なし。)

さてこんな感じかなー、と落ち着いたところで、webpack を実行してみたところ、下記の例外が出るようになってしまった。

...\node_modules\schema-utils\dist\validateOptions.js:42

throw new _ValidationError2.default(ajv.errors, name);

^

せっかくのエラー詳細がわからない

コンソール出力を読むに、schema-utils モジュールで JSON スキーマに基づく入力 JSON の検証で、検証エラーが発生したっぽい。

ということは、おそらくは、webpack.config.js の記載内容のどこかに誤りがあるのだろう、というところまでは察しがついた。

しかしここまでの情報では、いったい webpack.config.js 中のどこでどんな問題で JSON スキーマ検証エラーになったのか、見当がつかない。

いちおう、ネットで検索もしてはみたけれども、まぁ、いろいろヒットするにはするのだが（下記は一例）、

いかんせん、このエラーを引き起こす原因は、ようするに JSON の書き損じなので、それこそシチュエーションは十人十色。

ネット検索の結果では、自分のケースを解決できそうにもない。

上記コンソール出力を見るに、せっかく "ajv.errors" や "name" といった有益そうな情報を例外オブジェクトにまとめて throw してくれているのに、その内容が見られないことには如何ともしがたい。

webpack の機能（例えばコマンドラインスイッチなど？）で例外内容を見る事ってできるんでしょうか。

console.log で出力するように書き換えてしまえ!

正攻法はわからず仕舞いだったが、幸い、上記コンソール出力には、大変有り難いことに、例外を発射している箇所の JavaScript ファイル名と行番号が書いてある。

そこで、この JavaScript ファイル ― .\node_modules\schema-utils\dist\validateOptions.js ― の該当箇所に console.log() を書き足して、エラーの内容、すなわち "ajv.errors" と "name" の内容をコンソール出力するようにした。

これでもういちど webpack を実行すると、エラーの詳細がコンソールに出力された!

これでようやくわかったのは、

• この検証エラーは UglifyJs Plugin に関する JSON で発生していること、
  
• そして JSON 中、"parallel" プロパティの指定は boolean か interger のいずれかである必要があるのに、それに違反している
  

ということだ。

改めて webpack.config.js 中の UglifyJs プラグインを構成しているところを確認してみる。

new UglifyJSPlugin({ parallel: { cache: true, workers: 2 } })

たしかに、parallel プロパティに、boolean ないしは integer ではなく、オブジェクトを渡していた。

かつてはこの設定方式でよかったのだろうけれども、新しいバージョンでは不可となったということであろう。

自分は Windows OS 上で Visual Studio IDE を使って開発をしているのだが、幸い、Visual Studio のエディタの支援によって、現在バージョンにおけるオプション指定をガイドしてもらうことができた。

ということで、 UglifyJs プラグインの構成を下記に更新。

new UglifyJSPlugin({ parallel: true, cache: true })

これで再び webpack を実行すると、今度は無事成功した。

解決!

.NET Framework 上での xUnit 単体テストを SDK スタイルのプロジェクト形式で作る

xUnit 単体テストプロジェクトも SDK スタイルでやりたい!

Windows OS 上で Visual Studio 2017 を使ってのプログラム開発における、.NET Core ではなく .NET Framework 用の単体テストプロジェクトの話。

C# + .NET Framework 用の単体テストプロジェクトを作ると、そのプロジェクトファイルの形式は、新しい "SDK スタイル" と呼ばれる形式ではなく、旧来からのプロジェクト形式となる。

もっとも、単体テストのプロジェクト形式が従来形式だからといって、そんなに困ることもない。

しかし最近、xUnit を使った単体テストプロジェクトにおける NuGet パッケージ参照で躓いてしまった。

というのも、従来形式のプロジェクトだと、基本的にソリューションファイルからの相対位置で、packages サブフォルダに参照パッケージがダウンロードされる。

そのせいで、ちょっと別のフォルダ階層のソリューションから同プロジェクトを参照すると、".dll が見つからない!" といったビルドエラーになってしまったのだ。

SDK スタイルのプロジェクト形式だと、NuGet パッケージ参照の方式が変わるので、このようなトラブルはなくなる。

そこで、この xUnit 単体テストプロジェクトを、SDK スタイルのプロジェクト形式に変更してみた。

SDK スタイル形式で xUnit 単体テストプロジェクトを作る

変更といっても、.csporj ファイルを書き換えると、手落ちがあっては後々面倒である。

そこで改めて新規プロジェクト作成から進めてみた。

Visual Studio を起動し、プロジェクトの新規作成から、（今回対象のプロジェクトは、.NET Core ではなく .NET Framework である必要があるのだが、まずは）「.NET Core」のカテゴリを選択、xUnit の単体テストプロジェクトを作成する。

今回対象のプロジェクトは、.NET Core ではなく .NET Framework である必要があるのに、あえて「.NET Core」用の単体テストプロジェクトを作ったのは、SDK スタイルの C# + xUnit な単体テストプロジェクトファイルを作成するのにいちばん近道だったからだ。

そして続けて、できあがった xUnit 単体テストプロジェクトファイルを編集し、対象フレームワークを .NET Core から .NET Framework に書き換える。

今回の .NET Framework の対象バージョンは 4.5 だったので、.csproj ファイルには "net45" と記した。

これで、対象フレームワークは .NET Framework 4.5 としつつ、プロジェクト形式が SDK スタイルの、 C# + xUnit 単体テストプロジェクトが出来上がった。

上手くいったと思ったのだが...

早速テストコードを移植しビルドしてみると、当然のことながらビルドは成功し、Visual Studio のテストエクスプローラにもテストが検出されて表示された。

ここまでは順風満帆。

では単体テストを実行してみると...

あれ?

テストエクスプローラの表示上、各テストがいずれも「未実行」のアイコンのまま。

Visual Studio の出力ウィンドウをよく見てみると、

xunit.execution.desktop.dll がないので単体テストを実行できません、というではないか。

たしかに、単体テストプロジェクトの出力フォルダを見てみると、言われた xunit.execution.desktop.dll ファイルは存在しない。

(.NET Core プロジェクトではなく .NET Framework のプロジェクトなので、GAC に存在しない必要なDLLファイルは出力フォルダに出現する)

.NET Framework 4.5.2 なら OK!?

どうしてこういう事態になるのか、あまり深く考えずにとりあえずはとばかりにネットで検索してみた。

そうしたところ、xUnit のリリースノートに答えが。

.NET Framework のバージョン 4 および 4.5.1 は公式サポート期間を過ぎたので、4.5 ではなく、4.5.2 に引き上げろ、とのこと。

公式サポート期間、なるほど、そうでした。

自分のこのケースでは、たまたま古い内製ライブラリの保守の関係で、当時、.NET Framework 4.5 を対象にしていたので単体テストプロジェクトも .NET Framework 4.5 を対象に考えていて、こうなってしまったのであった。

ということで、単体テストプロジェクトの対象 .NET Framework のバージョンを、4.5 から、4.5.2 に引き上げてみた。

その上でリビルドし、Visual Studio のテストエクスプローラからテスト実行したところ、今度は期待どおりに実行されたのであった。

ちなみに、.NET Framework のバージョンを 4.5.2 に引き上げたプロジェクトでの出力フォルダを見てみると、ちゃんと xunit.execution.desktop.dll ファイルが配置されていた。

まとめ

以上、とりあえず、

• (.NET Core ではなく) .NET Framework + C# + xUnit な単体テストプロジェクトを、SDK スタイルのプロジェクト形式で Visual Studio 上で開発・実行することは可能
  
• 但し、対象 .NET Framework のバージョンが 4.5 だと期待どおりに動作しないので、4.5.2 に引き上げる必要がある
  

ということがわかった。