C#、ASP.NET、TypeScript、Angular を中心にプログラミングに関した話題を諸々。
by @jsakamoto
検索
リンク
北海道のITコミュニティ - CLR/H 無聊を託つ
タグ
カテゴリ
最新の記事
Azure Storage ..
at 2019-06-09 13:15
node のバージョンあげた..
at 2019-05-24 19:43
.NET HTTP REPL..
at 2019-04-23 00:19
C# プログラムでの Exc..
at 2019-03-31 22:44
ASP.NET Core W..
at 2019-02-26 22:01
最新のコメント
Mac(Chrome)で..
by Macユーザー at 00:46
すみません、記事書きかけ..
by developer-adjust at 22:36
続きはないんですか?
by hanamo at 13:03
助かりました。ありがとう..
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
記事ランキング
最新のトラックバック
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(仮)
以前の記事
2019年 06月
2019年 05月
2019年 04月
2019年 03月
2019年 02月
2019年 01月
2018年 12月
2018年 11月
2018年 10月
2018年 09月
2018年 08月
2018年 07月
2018年 06月
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年 11月 09日

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" の内容をコンソール出力するようにした。
d0079457_22161070.png
これでもういちど webpack を実行すると、エラーの詳細がコンソールに出力された!
d0079457_22165075.png
これでようやくわかったのは、

  • この検証エラーは 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 のエディタの支援によって、現在バージョンにおけるオプション指定をガイドしてもらうことができた。
d0079457_22172414.png
ということで、 UglifyJs プラグインの構成を下記に更新。
new UglifyJSPlugin({ parallel: true, cache: true })
これで再び webpack を実行すると、今度は無事成功した。
解決!

# by developer-adjust | 2018-11-09 22:28 | その他IT系 | Comments(0)
2018年 10月 28日

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

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

今回の .NET Framework の対象バージョンは 4.5 だったので、.csproj ファイルには "net45" と記した。
d0079457_00252265.png
これで、対象フレームワークは .NET Framework 4.5 としつつ、プロジェクト形式が SDK スタイルの、 C# + xUnit 単体テストプロジェクトが出来上がった。

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

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

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



あれ?

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

Visual Studio の出力ウィンドウをよく見てみると、
d0079457_00252238.png
xunit.execution.desktop.dll がないので単体テストを実行できません、というではないか。


たしかに、単体テストプロジェクトの出力フォルダを見てみると、言われた xunit.execution.desktop.dll ファイルは存在しない。
(.NET Core プロジェクトではなく .NET Framework のプロジェクトなので、GAC に存在しない必要なDLLファイルは出力フォルダに出現する)
d0079457_00252208.png

.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 のテストエクスプローラからテスト実行したところ、今度は期待どおりに実行されたのであった。
d0079457_00252231.png

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


まとめ

以上、とりあえず、

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

ということがわかった。


# by developer-adjust | 2018-10-28 00:59 | Visual Studio | Comments(0)