C#、ASP.NET、TypeScript、AngularJS を中心にプログラミングに関した話題を諸々。
by @jsakamoto
検索
リンク
北海道のITコミュニティ - CLR/H 無聊を託つ
タグ
カテゴリ
最新の記事
気が付いたら Visual ..
at 2018-05-23 22:34
Azure AD のユーザー..
at 2018-04-29 22:33
最近お気に入りの Visua..
at 2018-03-26 22:41
ASP.NET Core S..
at 2018-02-27 12:39
Visual Studio ..
at 2018-01-29 23:02
最新のコメント
助かりました。ありがとう..
by あああ at 21:32
いえす、F#! F#! :)
by developer-adjust at 21:46
F#はAzure Not..
by 幻のK泉さん at 18:37
> 今、Setcronj..
by developer-adjust at 08:25
今、Setcronjob..
by Kibe at 03:23
Jichym 改め yi..
by yi at 23:00
バッチファイル(.bat..
by Jichym at 01:26
なるほど、そこにテコ入れ..
by developer-adjust at 21:25
キャッシュを制御するディ..
by Hallo Brother. at 13:08
おっと、これはぬかりまし..
by developer-adjust at 23:57
記事ランキング
最新のトラックバック
Web API における..
from 松崎 剛 Blog
[Other]Code2..
from KatsuYuzuの日記
Developer @ ..
from .NET Clips
asp.netでrail..
from 4丁目より
F#でASP.NET M..
from ナオキにASP.NET(仮)
[B!] これはいい h..
from Twitter Mirror
[報告] Microso..
from .NET Clips
Developer @ ..
from .NET Clips
[F#]F# でブログア..
from 予定は未定Blog版
ASP.NET MVC ..
from ナオキにASP.NET(仮)
以前の記事
2018年 05月
2018年 04月
2018年 03月
2018年 02月
2018年 01月
2017年 12月
2017年 11月
2017年 10月
2017年 09月
2017年 08月
2017年 07月
2017年 06月
2017年 05月
2017年 04月
2017年 02月
2017年 01月
2016年 12月
2016年 11月
2016年 10月
2016年 09月
2016年 08月
2016年 07月
2016年 06月
2016年 05月
2016年 04月
2016年 03月
2016年 02月
2016年 01月
2015年 12月
2015年 11月
2015年 10月
2015年 09月
2015年 08月
2015年 07月
2015年 05月
2015年 04月
2015年 03月
2015年 02月
2015年 01月
2014年 12月
2014年 11月
2014年 10月
2014年 09月
2014年 08月
2014年 06月
2014年 04月
2014年 03月
2014年 02月
2014年 01月
2013年 12月
2013年 10月
2013年 09月
2013年 08月
2013年 07月
2013年 06月
2013年 05月
2013年 04月
2013年 03月
2013年 02月
2013年 01月
2012年 12月
2012年 11月
2012年 10月
2012年 09月
2012年 08月
2012年 07月
2012年 06月
2012年 05月
2012年 04月
2012年 03月
2012年 02月
2012年 01月
2011年 12月
2011年 11月
2011年 10月
2011年 09月
2011年 08月
2011年 07月
2011年 06月
2011年 05月
2011年 04月
2011年 03月
2011年 02月
2011年 01月
2010年 12月
2010年 11月
2010年 10月
2010年 09月
2010年 08月
2010年 07月
2010年 06月
2010年 05月
2010年 04月
2010年 03月
2010年 02月
2010年 01月
2009年 12月
2009年 10月
2009年 09月
2009年 07月
2009年 06月
2009年 05月
2009年 04月
2009年 03月
2009年 02月
2009年 01月
2008年 12月
2008年 11月
2008年 10月
2008年 09月
2008年 08月
2008年 07月
2008年 06月
2008年 05月
2008年 04月
2008年 03月
2008年 02月
2008年 01月
2007年 12月
2007年 11月
2007年 04月
2007年 03月
2007年 02月
2007年 01月
2006年 11月
2006年 10月
2006年 09月
2006年 08月
2006年 07月
ファン
ブログジャンル
画像一覧
2018年 01月 29日

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

Visual Studio の外部ツールメニューに PowerShell を登録

自分は Visual Studio IDE の外部ツールに、下記のような感じで PowerShell の起動を登録してある。
d0079457_22494999.png
さらにこの外部ツール登録に対し、キーボードショートカット 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 | Trackback | 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 | Trackback | Comments(0)
2017年 12月 21日

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

ClosedXML とその .NET Core 対応状況

C# などの .NET 環境において、Excel ファイルを読み書きするライブラリとしては、自分が知っている範疇では以下を挙げられる。このうち、自分は ClosedXML をよく使っている。

ところが残念なことに、2017年12月21日現在は、ClosedXML はまだ .NET Core に正式対応していない。

.NET Core 2.0 のプロジェクトに、ClosedXML の NuGet パッケージをインストールすることはできる(ただし、依存している NuGet パッケージが解決できないため、さらに手作業で DocumentFormat.OpenXml と FastMember.Signed の 2 つの NuGet パッケージを明示的にプロジェクトに追加する必要がある)。

しかしそのプログラムを実行して、実際に何か Excel ファイルを読み込む処理を実行すると、
「Could not load type 'System.Drawing.ColorTranslator' from assembly 'System.Drawing, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'」
という実行時例外が発生してしまう。
.NET Core 2.0 ランタイム上では、System.Drawing.ColorTranslator クラスは実装されていないためだ。

ということで、2017年12月21日現在時点では、残念ながら .NET Core 上では ClosedXML は使えないということとなっている。

なお、ClosedXML に代わって、.NET Core 上でも利用可能な Excel ファイル読み書きライブラリとしては、EPPlus のベータ版があるようだ。

しかしながら自分はこれまで EPPlus を使ったこともなく、今から EPPlus に乗り換えるのもちょっと億劫に感じていた。

ClosedXML も .NET Core 上での利用に向けて対応が進行中

ところで、ClosedXML の .NET Core というか .NET Standard 2.0 対応は、実は Issue も立てられてて、別途進行中ではある模様だ。

そこで、この進行中のコードを持ってきて、私家版の ClosedXML NuGet パッケージを生成すれば、自分の .NET Core プロジェクトでも ClosedXML が使えるようになる。

ということで実際にやってみたので、その手順を以下に記す。

.NET Core 対応 私家版 ClosedXML パッケージのビルド手順

自分の環境は Windows OS。
用意するものは git と Visual Studio 2017 だ。

自分は Visual Studio の Pro Edition でこの作業を行ったが、条件を満たせば無償で利用可能な Visual Studio Community Edition でも大丈夫ではないかと思う。
また、本質的には Visual Studio は必須ではなく、.NET Core 2.0 の SDK さえあれば、dotnet コマンドで、以下で説明しているのと同じことを実行可能なはず(そしておそらくは macOS などでも)、と考えている。

さておき、ClosedXML の .NET Standard 2.0 対応は、本家の ClosedXML GitHub リポジトリから fork した、igitur 氏の GitHub リポジトリで進行している模様だ。

そこで、この igitur 氏 fork 版の GitHub リポジトリをローカル環境に git clone する。> git clone git@github.com:igitur/ClosedXML.git
> cd ClosedXML
そして、.NET Standard 2.0 対応は、netstandard2 ブランチで進行している様子。
なので、netstandard2 ブランチをチェックアウトする。> git checkout netstandard2次に、ソリューションファイル ClosedXML.sln を Visual Studio 2017 で開く。

Visual Studio でソリューションを開いたら、ソリューションのコンフィギュレーションを Release に選択変更し、ソリューションエクスプローラ上でプロジェクト「ClosedXML」を右クリックして「パッケージ」をクリックする。
d0079457_21311975.png
すると、ひととおりビルドが始まって、最終的に ./ClosedXML/bin/Release フォルダに ClosedXML.0.9.0.nupkg ができあがる。
d0079457_21315666.png

パッケージ ID の変更

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

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

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

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

ここでパッケージ ID やバージョンなどを、適宜、私家版ビルドにふさわしいものに改変する。
d0079457_21314843.png
その上でもういちど、プロジェクト「ClosedXML」の右クリックからのパッケージ再実行で、改変後のパッケージ ID で NuGet パッケージファイル (.nupkg) ができあがる。

取り扱い上の注意

この改変後の私家版 ClosedXML パッケージだが、さすがに nuget.org に公開するのはまずいであろう。

なので、ローカルディスクであったり、あるいは会社内の LAN 上の共有フォルダに置いておくか、はたまた Visual Studio Team Service で使えるプライベート NuGet リポジトリに収録するなどして、プライベート用途に限定して非公開で配備するのがよかろうかと思う。

あと、言わずもがなだが、いくら GitHub 上で公開されているとはいえ、この私家版ビルド対象のコミットは、まだ .NET Standard 2.0 対応の仕掛中のものだ。

コミッタの igitur 氏も、私家版ビルドとはいえ、この netstandard2 ブランチからパッケージ作成して利用されることは想定していないことと思う。

まだ作業中であるが故の、igitur 氏本人にとっては既知の、これから取り掛かろうとしていた不具合修正などが多々残されてるかもしれないことは想像に難くない。
このあたりの背景や状況をよく踏まえた上で、利用可否の判断をすべきと思われる。

また、折角の機会なので、ClosedXML の .NET Standard 2.0 対応にあたり、何か助力できることがあれば、フィードバックするに越したことはないだろう。


# by developer-adjust | 2017-12-21 22:00 | .NET | Trackback | Comments(0)
2017年 12月 15日

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

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

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

今回はその方法について説明する。

レガシー jQuery 拡張をモジュールバンドルすると実行時エラーが起きる仕組み

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

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

CommonJS の仕組みにおいては、jQuery オブジェクトに用事があるモジュールは、そのモジュール内で "require('jquery')" を実行してその戻り値としての jQuery オブジェクトを使用する必要がある。

解決方法

ここまでわかれば、レガシー jQuery 拡張を CommonJS モジュール対応させるのは簡単だ。

グローバル名前空間にある jQuery シンボルを参照しようとするのをやめ、代わりに require('jquery') で jQuery モジュールを正規にインポートしたものを参照すればよい。(function ($) {
$.fn.xxxx = ...
})(require('jquery')); // グローバル変数 jQuery ではなく、
// require() の結果を引数に渡す!
これで webpack + TypeScript な構成でも、この改造後の jQeuery 拡張を import しモジュールバンドルできるようになる。

下位互換も維持するには

なお、このような改造を施した jQuery 拡張ライブラリは、今度は、旧来どおり素で script タグでブラウザに読み込ませるような構成だと動作しないことになる。

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

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

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

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

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


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

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

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

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

補足

ちなみにこの実装方法は、カラーピッカーとして (多分) 有名な jQuery 拡張である Spectrum のソースコードを参照してて知った。

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







# by developer-adjust | 2017-12-15 20:02 | Web系一般 | Trackback | Comments(0)
2017年 12月 14日

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

前提

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

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

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

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

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

この bundle.js を HTML コンテンツ中から script タグで参照・読み込むよう記述するわけだ。
(例えば下記 ./wwwroot/index.html のように。)<html>
<body>
<p id="p1"></p>
<p id="p2"></p>
<script src="/js/bundle.js"></script>
</body>
</html>

命題

さてここで、下記のような実装がされた、クラシカルな jQuery 拡張ライブラリ ( 架空の例として ./wwwroot/js/jquery.fizzbuzz.js ) を使う必要に迫られたとする。// ./wwwroot/js/jquery.fizzbuzz.js
(function($) {
$.fn.fizbuzz = function(n) {
...
}
})(jQuery);
先に述べた構成・開発環境において、どうやってこの古典的な jQuery 拡張を使用するのか、というのが本稿の命題だ。

まずは externals 化

このクラシック実装な jQuery 拡張は、上記のとおり、JavaScript のモジュール機構など考慮していない実装なので、app.ts で下記のように// ./src/app.ts
import * as $ from 'jqeury';

import '../wwwroot/js/jquery.fizz.buzz';

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

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

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

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

まず webpack.config.js に以下のように externals プロパティを記述する。// webpack.config.js
module.exports = {
entry: ['./src/app.ts'],
output: {
filename: './wwwroot/js/bundle.js'
},
resolve: { extensions: ['.js', '.ts'] },
module: {
loaders: [
{
test: /\.ts$/, use: [
{ loader: 'ts-loader' }
]
}
]
},
devtool: 'source-map',

externals: {
"jquery": '$'
}
};
そして index.html には以下のとおりに script タグを追加する。<html>
<body>
<p id="p1"></p>
<p id="p2"></p>

<!-- 別途、下記 src 属性で指定されたパスに
当該 JavaScript ファイルを配置しておくこと -->

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


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

これで実行時に jquery.fizzbuzz.js が初期化失敗することはなくなった。

TypeScript における型定義の解決

アプリケーションコードをTypeScript ではなく素の JavaScript で記述していたのであれば、以上、webpack の externals 指定を構成するだけで対応完了となる。

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

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

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

$(() => {
let randomNum = Math.round(100 * Math.random());
$('#p1').text(randomNum);
$('#p2').fizzbuzz(randomNum); // ← この行がコンパイルエラー
});
TypeScript コンパイラには、jquery.fizzbuzz.js によって fizzbuzz メソッドが増えるということがわからない・知らされていないためだ。

型定義情報を記述

「jQuery に fizzbuzz メソッドが増えている」ことを TypeScript コンパイラに知らしめるためには、型定義を自前で書けばよい。

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

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


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

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




# by developer-adjust | 2017-12-14 23:10 | Web系一般 | Trackback | Comments(0)
2017年 12月 11日

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

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

こんなシナリオである。

プロジェクトの新規作成テンプレートで、SPA ではない種類のテンプレートを選んでプロジェクト作成し、開発に着手。
d0079457_22442342.png
そしてその後で、webpack による TypeScript のビルド & バンドル環境を手動で構築した。

"webpack -w" コマンドを実行するとウォッチモードで webpack が常駐し、TypeScript ファイル (.ts) を編集・保存すると自動ビルド & バンドルが行われることを確認し、しばし TypeScript ファイルの編集を継続していた。

サーバー側実装のビルドを実行した以後、.ts をいくら変更しても...

しかしそのあと、サーバー側実装を変更して Ctrl + Shift + B で Visual Studio からのビルドを実行したところ、以降、TypeScript ファイルをいくら編集 & Ctrl + S で上書き保存しても、ちっともバンドル結果の JavaScript ファイルに反映されなくなった。

webpack が何らかの原因でウォッチ停止したのかと確認してみたが、そんなことはなかった。

ウォッチをいったん停止させて、ただの "webpack" を実行してみても、webpack の表示は「正常にビルド & バンドルできましたよ」といった内容。
ということで、webpack やそのビルド環境が壊れた様子ではない。

よくよく Visual Studio の画面を見直していると、おやおや、TypeScript ファイルと対応する同名の JavaScript ファイルができあがっているではないか。
d0079457_22440267.png
どうやら Visual Studio のビルドを実行すると、ソリューションエクスプローラ上では TypeScript ファイルのビルドアクションが「なし (None)」になっていても、TypeScript コンパイラが走ってしまうらしい。

その結果、他の箇所の TypeScript コード中における import 文が、このうっかり走ってしまった TypeScript コンパイルによって生成された JavaScript のほうを読み込んでしまい、それで元となる .ts ファイルをいくら編集してもバンドル結果に読み込まれないこととなってしまったようだ。

Visual Studio からのビルド実行で不用意な TypeScript コンパイルを避けるには?

Visual Studio からのプロジェクト新規作成において、Angular などの SPA 系のテンプレートを選んでプロジェクトを新規作成した場合はこんなことはなかった覚えがある。

そこで、SPA 系テンプレートから新規作成したプロジェクトと今回問題となっているプロジェクトとで、どこが違うか、.csproj ファイルの中身を開いて見てみた。

すると、SPA 系テンプレートから作成した .csproj にはあって、今回の .csproj にはない設定が見つかった。
<TypeScriptCompileBlocked>true</TypeScriptCompileBlocked>という設定である。

"TypeScript のコンパイルをブロックする" という、いかにもな感じの設定項目だ。

早速、今回の .csproj に上記設定を書き加えて保存したのちに、改めて Visual Studio 上でビルドを実行してみた。
d0079457_22443762.png
結果、上記処置で余計な TypeScript コンパイルは実行されなくなった。

解決!
 

# by developer-adjust | 2017-12-11 22:50 | .NET | Trackback | Comments(0)