@jsakamoto

.NET Core 3.0 の単一実行可能ファイル生成を手なずける

.NET Core 3.0 の単一実行可能ファイル生成

先日、公式リリースとなった .NET Core 3.0。

その新機能のひとつとして「単一ファイルの実行可能ファイル」を発行する機能がある。

これまでは、C# や VB、F# など .NET Core プラットフォームのプログラムをビルド・発行した場合、その最終成果物は、各種 .dll ファイル群がごちゃっと発行先フォルダに出力されるだけであった。

それが、.NET Core 3.0 の新機能「単一実行可能ファイル生成」を用いると、発行先フォルダには、たったひとつだけの実行可能ファイルが生成されるだけとなり、配布などの取り扱いが容易になる。

(なお、本機能の動作原理は、たとえて言うならば tar のような、どうやらある種の "アーカイブ" として必要 .dll ファイル群を単一実行可能ファイル内に収録しているようである)

もっとも、これまでも ILMerge や ILRepack などなど、.NET プラットフォームのバイナリを単一ファイルにまとめる手法やツールは存在していた。

とはいえ、.NET Core SDK 本体に類似の機能が標準で搭載されており、すぐに使える点は大変便利である。

ということで、Windows OS 上で Visual Studio 2019 を使った開発体制にて、「単一実行可能ファイル生成」を実際に試してみた。

まずは動作を確認

まずは試しにということで、Visual Studio 2019 のプロジェクトテンプレートから .NET Core コンソールアプリケーション (今回は言語は C#) を生成。

"Hello World" を表示するだけの C# プログラムだ。

そして下記記事を参考に、.csproj ファイルに2行書き加えてみる。

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

<PropertyGroup>

<OutputType>Exe</OutputType>

<TargetFramework>netcoreapp3.0</TargetFramework>

<PublishSingleFile>true</PublishSingleFile>

<RuntimeIdentifier>win10-x64</RuntimeIdentifier>

</PropertyGroup>

</Project>

まずはここまででビルドして実行してみる。まぁ、普通に成功することを確認。

続けて、いよいよ発行である。

Visual Studio 2019 上の開発作業ということで、Visual Studio 上でフォルダへの発行プロファイルを作成し(下図)、発行を実行。

すると、手順どおりにやっているのだから当たり前であるが、無事、発行先には .exe ファイルがひとつだけ生成された。(実行環境に 64bit Windows10 OS を指定しているので、生成される実行可能ファイルは拡張子 .exe の PE ファイルである。)

なお、たかが "Hello World" を表示するだけのコンソールアプリケーションであるが、その実行可能ファイルのサイズは 65.8MB になってしまった。

まぁ、ターゲットランタイムがポータブルでない、且つ、配置モードが自己完結 (Self-Contained) な発行成果物を、非圧縮でアーカイブしているだけのようなものなので、こんなものだろう。

他の OS 用にも発行できる

なお、.NET Core といえばクロスプラットフォームである。

ということで、上記プロジェクトを、例えば 64bit Linux 用に単一実行可能ファイルを発行したい場合はどうするか?

これはもう、何も難しいことはない。

ただただ単純に、ターゲットランタイムとして "linux-64" を指定した発行プロファイルを作成して、その発行プロファイルで発行すれば良いだけである (下図)。

だがしかし、そのプロジェクト、Windows 専用になってない?

さてところで、上記までの手順だと、プロジェクトファイル内にターゲットランタイム指定が記載されているため、発行ではなくビルドの時点でも、64bit Windows10 用のバイナリを吐くように規定されてしまっている。

このようなプロジェクトファイルを、Linux や macOS など他の OS 上でビルドするとどうなるか?

まぁ、実はビルドは成功する。

だが、さすがに実行まではできない。

(※実は、Windows10 上の Windows Subsystem for Linux, いわゆる WSL の中だと実行できてしまったりもするのだが、それはまた別の話。)

かといって、ターゲットランタイムの指定をプロジェクトファイル内から記述削除し、ポータブル形式でてビルドしようとしても、今度はビルドが下記エラーで失敗するようになってしまう。

error NETSDK1097:

RuntimeIdentifier を指定せずにアプリケーションを単一ファイルに発行することはサポートされていません。

RuntimeIdentifier を指定するか、PublishSingleFile を false に設定してください。

".NET Core といえばクロスプラットフォームである" といっておきながら、これはいただけない。

どうしたものか?

発行プロファイルで指定する

答えは

「単一実行可能ファイル生成の指定は、プロジェクトファイル (.csproj) に書かない。代わりに発行プロファイル (.pubxml) に書く。」

である。

Visual Studio で開発していての発行プロファイルとは、その実態は、Properties フォルダ以下に配置された拡張子 .pubxml のファイルであり (下図)、プロジェクトファイル (.csproj) に対する差分である。

ということで、まずは .csproj ファイルからは、先ほど追加した単一実行可能ファイル生成およびターゲットランタイム指定の2行を削除して、元に戻す。

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

<PropertyGroup>

<OutputType>Exe</OutputType>

<TargetFramework>netcoreapp3.0</TargetFramework>

</PropertyGroup>

</Project>

次に、先に作成していた発行プロファイルを (Visual Studio の発行プロファイル編集 GUI 経由ではなく) エディタで開いて直接編集し、"<PublishSingleFile>true</PublishSingleFile>" の行を追加する。

(※ターゲットランタイム指定 ("<RuntimeIdentifier>～</RuntimeIdentifier>") は既に含まれているはず)

<?xml version="1.0" encoding="utf-8"?>

<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">

<PropertyGroup>

...

<RuntimeIdentifier>win10-x64</RuntimeIdentifier>

<PublishSingleFile>true</PublishSingleFile> <!-- ← これを追記 -->

</PropertyGroup>

</Project>

以上で OK だ。

これでこのプロジェクトは、どの OS 上であっても、ターゲットランタイム = ポータブルとしてビルド・デバッグ実行可能となる。

その上で、上記発行プロファイルを使って発行すれば、64bit Windows 10 上で直接実行可能な (.NET Core Runtime の事前インストールも不要な) 単一ファイルの実行可能ファイルが手に入る。

もちろん、他の OS 用に発行プロファイルを変更したり発行プロファイルを追加したりしてもよい。

補足1 - dotnet CLI での開発時

冒頭で示した公式ドキュメントを見ると、dotnet CLI を使う場合は、dotnet CLI 実行時のコマンドライン引数に、ターゲットランタイム指定と、単一実行可能ファイル生成指定を行なう方法が説明されている (下記例)。

> dotnet publish -r win10-x64 /p:PublishSingleFile=true

このように、やはりプロジェクトファイル内では単一実行可能ファイル生成の指定はせず、発行時に個別に単一実行可能ファイル生成の指定を行なう (この例で言えば、dotnet CLI のコマンドライン引数で指定する) のがよさそうである。

また、dotnet CLI を使った場合でも下記要領にて、今回説明したような発行プロファイルを用いた発行をすることもできる。

dotnet publish /p:PublishProfile=<ここに.pubxmlファイルのパス>

補足2 - Visual Studio 2019 の発行プロファイル編集 GUI がおかしい

ここまでわざと気づかぬフリをしてきたが、実はここまで説明してきた手順だと、本記事のスクリーンショットにもちょっと見えているが、Visual Studio 2019 の発行プロファイル編集 GUI の表示上は、配置モードが「フレームワーク依存」と表示されてしまっている。

しかし実際に発行される内容は、配置モード = 「自己完結」 (Self-Contained) な内容となっている。

実はこれ、ターゲットランタイム指定 (RuntimeIdentifier) が指定されていると、配置モード指定が明示的に設定されていない場合、どうやらビルドスクリプト上は配置モードのデフォルト値が、「フレームワーク依存」から「自己完結」に切り替わっているようなのである。

ただ、そのビルドスクリプトの仕様が Visual Studio 2019 の発行プロファイル編集 GUI には反映されていないようで、すなわち、Visual Studio 2019 の発行プロファイル編集 GUI では、配置モードの指定が明示的に設定されていない場合は「フレームワーク依存」と表示されているようだ。

ぐだぐだ書いたが、このような混乱を避けるには、配置モード指定を発行プロファイル内に明記してしまえばよい。

...

<SelfContained>true</SelfContained> <!-- ← これを明記 -->

</PropertyGroup>

</Project>

あるいは Visual Studio 2019 の発行プロファイル編集 GUI 上で、配置モードを明示的に「自己完結」に選択し直しておいても OK だ。

このように常に配置モードの指定を明示的に設定しておくようにすれば、要らぬ混乱を避けられるであろう。

なお、この逆に、配置モードを「フレームワーク依存」として明示的に設定して単一実行可能ファイル生成指定で発行したらどうなるか?

そうすると、OS に別途 .NET Core ランタイムの事前インストールが必要となるが、サイズは極小となる、そのような単一実行可能ファイルが発行先に生成される。

.NET Core SDK がインストール済みであることが前提な開発者向けのツールなど、これはこれで需要あるかもしれない。

まとめ

単一実行可能ファイル生成は、その機能の性質上、ターゲットランタイムの指定が必須である。

そのため、単一実行可能ファイル生成の指定は、プロジェクトファイルに記入するのではなく、発行プロファイルに記入しておくのが、自分的にはお勧めである。

Entity Framework Core でデータベースを読み書きする ASP.NET Core アプリ開発中に、発行される SQL 文字列を確認する

背景 - EFCore が出力する SQL 文を知りたい

データベースを読み書きする ASP.NET Core Web アプリ実装において、データベースアクセスライブラリの選択肢としてとりあえずオーソドックスな "Entity Framework Core" (以下 EFCore)。

EFCore およびその前身である "Entity Framework" の面白いところは、データベースクエリの結果をオブジェクトに "マップ" する O/R マッパーというだけでなく、C# コードとして記述されたラムダ式木に基づく SQL クエリビルダーでもあるという側面がある。

さてそんな EFCore であるが、だがしかし、期待していたのとは異なる SQL が発行される可能性も少なくない。

とくに EFCore の ver.2.x だと、GROUP JOIN ですら、簡素な SQL を発行して早々にデータベースから多量のレコードをオブジェクトとして読み込んでしまい、オンメモリで残りの処理を実行することもあるという。

なお、本ブログ執筆時点では未だリリースされていない、次バージョン EFCore 3.x では、このあたりの挙動が変更され、SQL に変換できないクエリは例外を発生させることになるらしい。

この辺りの話題は、下記などが参考になる。

そんなこともあり、とくにアプリ開発中は、EFCore が発行する SQL 文を確認したいところである。

なお、コンソールアプリなどで EFCore 使用時に、その発行する SQL を確認するには、その目的のロギング機構を組み立てて適用すればよい。

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

実は開発時ログ出力には、既に含まれている

さてさて、ASP.NET Core アプリ開発中は、一般的なプロジェクトテンプレートから起こしたプロジェクトであれば特に、すでにロギング機構が組み込まれており、且つ、開発時向けのログレベル構成が適用済みである。

下記は開発時用構成ファイルである appSettigs.Development.json 中のログレベル構成だ。

{

"Logging": {

"LogLevel": {

"Default": "Debug",

"System": "Information",

"Microsoft": "Information"

}

}

この構成だと、Visual Studio で開発中であれば、Visual Studio の出力ウィンドウに色々ログが流れているのが確認できる。

(※デバッガなし実行でも表示される)

また、dotnet CLI を使ってる場合も "dotnet run" などで実行すると、コンソールにログが流れるのを見ることができる。

実は既に、EFCore が出力する SQL 文は、このログの中に表示されているのだ。

よーく見ると、EFCore が出力する SQL 文が、ログの中に表示されているのを見つけることができる (下図、赤丸のところ)。

大量のログ出力に埋もれてしまう...

しかしである。

上図でもわかるように、このままでは、ブラウザ等からの要求ごとの ASP.NET Core 関連ログが大量に発生し、EFCore の SQL 文ログがそれらログに埋もれてしまう。

(ないしは、あっという間にスクロールアウトしてしまう)

実際問題として、この構成のままでは、大量のログの中から EFCore が出力する SQL 文を探し出して確認するという作業はあまり現実的ではない。

これは個人的な意見であるが、実のところ、ASP.NET Core 関連の要求処理時の情報ログは、あまり必要を感じない。

どのようなリクエストがブラウザから発生しているかを見るときは、どちらかといえば、ブラウザの開発者ツールで確認するだけで用が足りることがほとんどだ。

EFCore 以外のログレベルを調整

ということで、appSettings.Development.json を改訂し、"Microsoft" カテゴリのログレベルを "Information (情報)" から "Warning (警告)" レベルに引き上げてしまうと良かろう。

そうすることで、ASP.NET Core 関連の大量の情報ログが表示されなくなる。

ただしそれだけだと、EFCore の SQL 文出力も同じく表示されなくなってしまう。

そこで、EFCore の SQL 出力だけはログ出力されるよう、"Microsoft.EntityFrameworkCore.Database.Command" カテゴリのログレベルを、再び "Information" としてオーバーライドするとよい。

最終的な appSettigs.Development.json は下記のような感じになる。

{

"Logging": {

"LogLevel": {

"Default": "Debug",

"System": "Information",

"Microsoft": "Warning",

"Microsoft.EntityFrameworkCore.Database.Command": "Information"

}

}

}

これで下図のような感じで、EFCore の出力する SQL 文だけが都度流れるようになる。

自分の開発スタイルとしてはこれくらいのログレベルでちょうどいい感じだ。

以上、すべてのケースでこのログレベル構成が最適とは言わないが、同じような境遇の人にこの情報が役に立てば幸いである。

補足

データベースアクセスのためには、EFCore 以外にも選択肢はいろいろあるので、発行される SQL を完全に制御したい場合などは、無理に EFCore を使う必要もない。

下記など参考にされたし。

ASP.NET Core での単体テスト内で、オプションおよびサービスプロバイダを作成する

C# による ASP.NET Core プログラミングにおける、単体テストを実装していての話題。

ネットで検索すればすぐに見つけられるような内容かとも思うが、自分の為の備忘録を兼ねてここに記す。

さて、前述のとおりの単体テストを実装している際、IOption<T> をコンストラクタ引数に求めるオブジェクトをテスト対象とすることがある。

さらにたまーにではあるが、コンストラクタ引数に IServiceProvider を直に要求するオブジェクトを扱うこともある。

このようなケースで、どのように IOption<T> ならびに IServiceProvider をテストプログラム中でインスタンス化すればよいか、という話である。

IOption<T>

ASP.NET Core におけるオプション構成は、通常は Startup クラス中の ConfigureServices メソッド内で初期化するのが通常だ (下記は MyOptions 型のオプションを appSettings.json などの構成情報から読み取って取得する例)。

public class Startup

{

private IConfiguration Configuration { get; }

public Startup(IConfiguration configuration)

{

Configuration = configuration;

}

public void ConfigureServices(IServiceCollection services)

{

services.Configure<MyOptions>(this.Configuration.GetSection("My"));

...

こうしておくと、MVC/API コントローラなどで MyOptions 型のオプション情報が必要な場合は、そのコンストラクタ引数として IOptions<MyOptions> 型の引数を用意しておけば、依存性注入機構によって引き渡されるようになっている (下記例)。

public class MyController : Controller

{

private IOptions<MyOptions> MyOptions { get; }

public MyController(IOptions<MyOptions> myOptions)

{

this.MyOptions = myOptions;

...

さてこのような IOption<T> を自前のテストコード中で直に生成するには、Microsoft.Extensions.Options 名前空間の Options クラスの Create<T>(T options) 静的メソッドを用いる。

この Create<T>(T options) 静的メソッドの引数に、任意の型 T のオブジェクトを渡せば、その戻り値で IOption<T> が返る　(下記例)。

using Microsoft.Extensions.Options;

...

IOptions<MyOptions> myOptions = Options.Create(new MyOptions {...});

IServiceProvider

IServiceProvider を自前のテストコード中で生成するには、Microsoft.Extensions.DependencyInjection 名前空間の、ServiceCollection クラスを使う。

手順としては、まずは ServiceCollection クラスをインスタンス化する。

次にこの ServiceCollection オブジェクトに対し、AddSingleton<T1,T2>() などをはじめとしたおなじみのメソッドを呼び出して、そのテストで必要となるサービスを登録しておく。

(すなわち、IServiceProvider を要求しているテスト対象のコード中では、その IServiceProvider に対して GetService<T1>() とか呼び出して、サービスを入手しているであろうため)

以上の準備が整ったら、ServiceCollection オブジェクトの BuildServiceProvider() メソッドを呼び出す。

そうすると、BuildServiceProvider() メソッドの戻り値として、IServiceProvider が返る。

var services = new ServiceCollection();

services.AddSingleton<IMyService, MyServiceMock>());

...

var serviceProvider = services.BuildServiceProvider();

使い終わったら、Dispose() メソッドを呼び出してリソース破棄しておくことを忘れずに。

以上!

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 での実行時について書かれてないけど?

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