はじめに

　Azure DevOps プロジェクトを ASP.NET Core 2.1 へアップグレード（前編）に引き続き、今回は作成したプロジェクトを .NET Core 2.1 へアップグレードしていきたいと思います。

　Visual Studio 2017 をお持ちでない場合は Community Edition が無償でダウンロードできます。こちらを事前にローカルの開発端末にインストールしておきます。

Repos からソースコードのクローンを取得

Azure Repos からローカル端末にプロジェクトのクローンを取得します。
Visual Studio が起動してくるので、任意の場所に複製を取ります。
ソリューションファイル(.sln)をダブルクリックして、ソリューションを開きます。

ASP.NET Core 2.1 へアップグレード

[プロジェクト] のプロパティにて、ターゲットフレームワークを 2.1 に変更します。ソリューションには３つプロジェクトが含まれているので各プロジェクトで設定を変更します。
[依存関係] を右クリックし、ショートカットメニューより [NuGet パッケージの管理] を起動します。更新プログラムをすべてのパッケージに対して更新します。こちらも３つのプロジェクトそれぞれに実施します。
下記のエラーが出力される場合には、[NuGet パッケージの管理] より Microsoft.NET.Sdk.Razor をインストールします。
[ビルド] メニューから、ソリューションのリビルドを実行し、エラーなく完了できることを確認します。

　以上で .NET Core 2.1 でのビルドが正常に完了しました。デバッグ実行でローカルでのアプリケーション動作を確認します。

変更済みプロジェクトを Repos へ同期

[チームエクスプローラー] タブに切り替え、[家マーク] のホームボタンをクリックし、[変更] を選択します。コメント欄に「Update to .NET Core 2.1」と入力し、[すべてをコミット] をクリックします。
　
[同期] をクリックし、遷移した次画面で、再度 [同期] をクリックします。

　以上で、ローカルでの変更が Repos へ反映されました。

ビルド Pipelines の確認

　ローカルの変更が Repos へ反映されると、それをトリガに Azure DevOps の Pipelines が自動的に実行されます。今回変更した「Update to .NET Core 2.1」はビルドが失敗していることがステータスからわかります。

　「Update to .NET Core 2.1」をクリックして Build Job のどのタスクで失敗したかを確認します。

　更に「Restore」をクリックし、ログからエラーの要因を特定します。以下の画面では切れて見えていませんが、次のエラーが原因とわかります。

error NU1003: PackageTargetFallback and AssetTargetFallback cannot be used together. Remove PackageTargetFallback(deprecated) references from the project environment.

　これは以下の公式ドキュメントにも記載のある「Package Target Fallback プロパティの名前変更」に該当しています。

ASP.NET Core 1.x から 2.0 への移行
https://docs.microsoft.com/ja-jp/aspnet/core/migration/1x-to-2x/?view=aspnetcore-2.1

プロジェクトの修正

　ローカルの開発端末に戻り、Visual Studio でプロジェクトを右クリックし、ショートカットメニューより、プロジェクトの編集を選びます。

　プロジェクトファイルの下記赤枠３か所に記載のある PackageTargetFallback を AssetTargetFallback に変更します。プロジェクトは３つあるので、それぞれで該当箇所がないか確認します。

修正プロジェクトを Repos へ再コミット

[チームエクスプローラー] タブに切り替え、[家マーク] のホームボタンをクリックし、[変更] を選択します。コメント欄に「Modify PackageTargetFallback to AssetTargetFallback.」と入力し、[すべてをコミット] をクリックします。
　
[同期] をクリックし、遷移した次画面で、再度 [同期] をクリックします。

ビルド Pipelines の再確認

　今回はビルド Pipeline が正常に完了したことが示されています。

　Azure ポータル上でも DevOps Projects の CI/CD プロセスがデプロイまで含め全て正常に完了しているのがわかります。Application endpoint をクリックして、デプロイ済みのアプリケーションにアクセスしてみます。

　**残念ながらうまく動作していないようです。**今回利用した Linux Web Apps へのデプロイでは、Pipelinse の Release プロセスで統合テストフェーズが入っていないため、CI/CD の段階で実行時エラーが検出されておりません。これに関しては、また別の機会に詳細な解説をしたいと考えています。

実行時エラーの解決

今回、実行環境として利用している App Service (Linux Web App) をクリックします。
アプリケーションの設定で、ランタイムを .NET Core 2.1 に変更して [保存] をします。
再度、アプリケーションにアクセスして、以下のように成功する事を確認します。

Pipelines の Release 設定の変更

　上記はマニュアル操作で、App Services のランタイムスタックを変更しましたが、本質的には Azure DevOps の Release パイプラインの設定を変更します。

Releases の Edit をクリックします。
赤枠の job/tasks をクリックします。
Deploy Azure App Service の Runtime Stack で、.NET Core 2.1 を選択して [Save] します。

　以上の変更により、これ以降の CI/CD プロセスでは、App Services のランタイムスタックが .NET Core 2.1 としてデプロイが実施されます。

　次回は、Release フェーズで統合テストを実行することで、今回のような実行時エラーを CI/CD プロセスで事前検出する試しみを行いたいと思います。