LTS版の.NET6.0が正式リリースされたので、当サイトもこれで4回目のマイグレーションです。
前回と同様、今回も少し手こずりましたので記事にしておこうと思います。
ASP.NET Core 6.0へのアップグレード
プロジェクトのTargetを.NET6に、Dockerfileを新規ASP.NET Core MVCプロジェクトを参考に.NET6.0のイメージに変更しました。
これはあっさり起動。ビルドも心なしか速い気がします。
VS2022が64bitになったせいですかねぇ。でも、メモリ消費量が多いのか、私の非力なマシンではUI周りがもたつく感じがあります。Windows10は2025年まで大丈夫ですが、もうちょっといいマシンが欲しい。
Windows7の頃のマシンなので今回のWindows11へのアップグレードはダメそうです。
このままAzure Piplineに流してしまえ~と、思ってやってみたのですが、ビルドでエラー。
もちろんAzure PiplineのAgentをwindows-2022
に変えるのもちゃんとやったんですが...
buildで失敗していたので、ログを見てみると非推奨なパッケージがいくつかあるようです。
エラー自体はnode-sassが原因でした。ふーむ。
ひとまず.NET周りから順番に。
まずはnuget で全部アップデートしちゃいます。
と言っても使ってるパッケージはそれほど多くなくて...。
<ItemGroup>
<PackageReference Include="linq2db.PostgreSQL" Version="2.9.4" />
<PackageReference Include="Markdig" Version="0.18.0" />
<PackageReference Include="Serilog.AspNetCore" Version="3.2.0" />
<PackageReference Include="Serilog.Sinks.Console" Version="3.1.1" />
<PackageReference Include="Serilog.Sinks.RollingFile" Version="3.3.0" />
<PackageReference Include="SixLabors.ImageSharp" Version="1.0.0-beta0007" />
<PackageReference Include="WindowsAzure.Storage" Version="9.3.3" />
</ItemGroup>
ちょっとイロモノが目立ちますか?
- linq2db.PostgresSQL ... ORマッパーです。GitHub
- EF Coreがまだまだ安定していなかったのでこれを使ってみました。可もなく不可もなし。
- Markdig ... Markdownパーサです。これはちょっと有名ですよね。
- Serilog ... ロガー。あまり活用できてません。
- SixLabors.ImageSharp ... 画像のサムネイルを自動作成するのに使ってます。これも可もなく不可もなし。
- WindowsAzure.Storage ... 画像はConoHaのVPSではなくAzure Storageに格納して運用してます。
さて、この中でWindowsAzure.Storageはdepricateだそうで、Azure.Storage.Blobに変えろと警告されました。
まぁ、ついでなので全部アップグレードしてしまえー。と、やってしまったのが運の尽き...
linq2dbのアップグレードではまることになりました...
linq2dbのアップグレード断念
linq2dbをアップグレードしたら、依存しているNpgsqlもアップグレードされました。
これがハマりポイントでした...約2時間悩みまくった。
知っている人は知っているのかもしれませんが、postgreSQLがどこかのバージョンでenumを定義出来るようになっているんですね。
これまでは.NETのEnumからDBのintegerのカラムにマッピングしていたのですが、これがエラーになるようになりました...
NotSupportedException: The CLR enum type TaxonomyTypeEnum must be registered with Npgsql before usage, please refer to the documentation.
TaxonomyTypeEnumというのが定義している.NETのEnum型名なのですが、postgreSQL側のenum名とマッピングしろって言われるんですよね...
Npgsqlのページ
linq2db側でもマッピングをカスタマイズできるようなのですが、これが何故かうまく動いてくれない...
2時間悩んで、パッケージを戻すことにしました。
戻したらあっさり動いた。ふぅ。怖い怖い。
でも、いずれ問題になりそうです。
データ件数的に大したことないのでRDBをやめるということも含めて後で考えることにします。
Azure.Storage.Blobs
こちらはAPIがガラリと変わります。
実はAzure Static Web App & Azure Funtionsでちょっと遊んでいた時にAzure.Storage.Blobsについては調査済み。
書き換えも楽勝でした。
新しいAPIは前よりずっと使いやすい感じです。
node-sass
.NET側はひとまず動作確認出来たので、Azure Piplineでエラーが出ていた根本原因のnode-sassの方を調べます。
node-sass自体がdepricatedみたいですねぇ。
Azure Static Web Appで遊んでた時にViteというバンドラーを使っていたのですが、sassの変換にnode-sassではなくsassというnpmパッケージを入れろと書いてありました。
このサイトのシステムではSPAと違ってCSSと少々のJSをバンドルするだけなので、fuse-boxというこれまたマイナー(?)なバンドラーを使っていました。
webpackより高速っていうのが売りだったのですが、webpack4の登場であまり変わらなくなったと記憶しています。
いずれデファクトスタンダードなwebpackにするかなぁ。なんて思っていました。
これを機にViteに変えました。
Viteいいですねぇ。覚えることが少なくて使いやすい。
typescriptのトランスパイルはesbuildを使用しているのと、開発時はバンドルしないという仕様のため、これまた高速というのが売りっぽいです。
私的にはゼロコンフィグな点が気に入りました。
ASP.NET Coreで使うには、全く書く必要が無いわけではありませんが、webpackに比べたら大したことありません。
以下のサイトを参考にSPAに関係ない部分を変えて対応出来ました。
Integrating Vite with ASP.NET Core – a winning combination?
再びAzure Pipeline
node-sassの件も解決したので、今度こそとgit push
したのですが、またまたエラーに...
dotnet publishコマンドでエラーになっている模様...。
原因は単純で、viteが出力するファイルはハッシュ値みたいなものが付くので毎回ファイル名が変わるのですが、これをgitの管理対象にしていたので、ファイルが見つからないというエラーでした。
gitignoreに登録して、publish時にのみ作成されるようにしたらエラーが消えました。ふぅ。
手元でもpublishまでやっとかないとダメですな...
まとめ
大体、2年に一度のマイグレーションなので、ツールセットが刷新されてたりすることに起因するトラブルばっかりです。
実は、今回のマイグレーションはやる予定ではなくて、Azure Static Web Apps & Azure Functionsにリプレースしようと考えていました。
ところが、こちらも調べてみると色々問題が出てきていて、ちょっと方向転換が必要になったので急遽マイグレーションを先に済ませようと考えて実行してみたら、2日もかかってしまいました。
甘く考えてはダメですな...
ひとまず動いて良かった。
では恒例のセリフですが、誰かの参考になることを祈って締めとしたいと思います。
実は、この記事を書いたのは1週間ほど前なのですが、トラブルで記事投稿が出来ませんでした。
気になる方は番外編も見て頂けるとうれしいです。