開発基盤部会 Blog

開発基盤部会 Blog >> 記事詳細

2019/09/11

Visual Studioや.NETのバージョンアップの度に苦しむStartupクラス修正問題

Tweet ThisSend to Facebook | by nishino
 前回に続き、今回は、Startupクラス周辺の変更についての話です。そもそも、Startupクラスってなんだっけ?みたいな話があるかと思いますが、簡単に言うと、Webアプリケーションの様々な初期化を行うクラスです。

 以前の.NET Framework版では基本的にWeb.configでCookieやSessionの設定を行い、OWIN Startupクラスが追加されて以降、ここでホスティング ランタイムとミドルウェアを指定することでルーティングやフィルタの設定を行うようになりましたが、.NET Coreになってから、Web.configは廃止されてCookieやSessionの設定、ルーティングや、DIによるフレームワーク選択などを、全て、この中で行うようになりました(Web.configの代替にappsettings.jsonがありますが、設定は自動的に反映されず、Startupで手動でappsettings.jsonを読み取って設定する必要があります)。

 そして、.NET Frameworkの頃はバージョンアップがあっても変更は、それ程、多くはなかったのですが、.NET Coreになってから、Startup周辺の変更が、ちょっと多い印象ですね。今回の移行作業のメモをしましたが、殆どが、このStartupクラスの修正でした。



 以下、特にハマった変更点を2つ程、列挙しようと思います。

 一つ目は、WebAPIのModel BindingでJSONの子階層が上手くPOCOにデシリアライズされない現象が起きたので、色々調査して、もしや?と思い、シリアライザを DI で、Microsoft. AspNetCore. Mvc. NewtonsoftJson に変更してみたら上手く動きました(.NET Core 3.0から標準のシリアライザが実装され、Newtonsoft.Json への依存が削除されている)。

 現時点では、標準シリアライザの問題なのか?、利用方法の問題なのか?、まだ切り分けが出来ていないので、この辺は継続的にウォッチして行きたいと考えています。

 二つ目は、以前は UWP をテスト・ドライバとして使用していたため顕在化しませんでしたが、今回はReactをテスト・ドライバとして使用したため、今まであまり意識していなかった、CORSの問題が顕在化しました。

 具体的には、以前から、Cross Originの受入はできていたようですが、

 「ResponseにAccess-Control-Allow-Originヘッダが設定されていなかったので、コレをチェックするクライアント(ブラウザ)では上手く動作しなくなっていた。また、'Content-Type' が 'application/x-www-form-urlencoded' ではなく 'application/json'の場合、Preflight requestが走るようで、この場合、Access-Control-Allow-Headersヘッダを返す必要があった。

 と言うもので、これは、ReactをDebugしていて、

 「Access to fetch at 'http://localhost:8888/...' from origin 'http://localhost:3000' has been blocked by CORS policy:

 というメッセージが出力されて気が付くことが出来ました(fetchの部分がXMLHttpRequestだったりするようなので、コレは、プラットフォーム側のエラーメッセージでしょうか。調べると多分、Chromeが出力している様に見えます)。

 などなど、.NET Core移行の後もバージョンアップの度に苦労しますが、この短いリリースサイクルと仕様変更、機能追加によって、プロダクトが早い速度で継続的に改善されるという恩恵を受けている訳ですし、ココを真面目にトラブルシュートすると、案外、得るものも多いのかもしれません。
09:00 | 投票する | 投票数(0) | コメント(0) | ご報告