【BS4】時は来たれり。今こそ .NET 6 へ移行する時。

日本マイクロソフト
Digital Sales 事業本部
Digital Cloud Solution Architect
上坂貴志
時は来たれり。
今こそ .NET 6 へ移行する時。

.NET Framework から .NET 6 へ
本セッションは、
の移行についてのセッションです

Agenda
Agenda
 .NET 6 への移行全体像
 移行事前作業
 PackageReference 対応
 SDKスタイル対応
 依存先の調査
 移行
 ターゲットフレームワークを .NET 6 へ変更
 依存先を Upgrade
 API への対応
 移行用のツール（.NET Upgrade Assistant）
 フレームワーク別の対応
 .NET 対応フレームワークの移行
 .NET 非対応フレームワークの移行
 Appendix
 時は本当に来たのか
 WinForm/WPF の移行
 ASP.NET MVC の移行
 Xamarin の移行
 WCF の移行
 使用不可になった .NET Framework テクノロジ解説
 .NET Portability Analyzer
 .NET Upgrade Assistant Analyze Command

Migration to .NET 6 overview
.NET 6 への移行
全体像

To understand the migration overview
移行の全体像を把握するには個人的なおススメ
1. 移行のタスクの順番とその内容を知る
2. 移行を手動で行う場合の方法を知る
3. 移行ツールをどう使えばよいのかを知る

Migration to .NET 6 overview
.NET 6 への移行全体像
ソリューションファイル
プロジェクトファイルプロジェクトファイル
コード
設定ファイル
プロジェクト専用ファイル
~.csproj
~.vbproj
~.fsproj
~.sln
~.csproj
~.vbproj
~.fsproj
App.config
Web.config
packages.confg
Global.asax
etc
設定ファイル
プロジェクト専用ファイル
App.config
Web.config
packages.config
etc
コード
~.dll
~.dll
~.cs
~.vb
~.fs
~.cs
~.vb
~.fs
~.dll
~.dll
NuGet 非管理パッケージ
(loose Assembly)
APIへの対応
依存先への対応
フレームワーク別の対応
移行するプロジェクト移行プロジェクトが参照するプロジェクト

Basic migration flow
基本的な移行の流れ
1. packages.config を PackageReference に変更
2. プロジェクトファイルを SDK スタイルに変更
3. ビルド＆稼動確認
4. 依存先の .NET 6 対応可否を調査
5. （オプション）.NET Portability Analyzer で実装コードの API 互換をチェック
• 移行事前作業
1. Target Framework を .NET 6 に変更
2. 依存先を .NET 6 での稼働が問題がないバージョンに（必要なら） Upgrade
3. ビルド
4. エラー修正（.NET 6 API 対応）
5. ビルド
• 移行
＋フレームワーク対応がどこかに追加

Change to PackageReference
PackageReference 対応
packages.config を PackageReference に変更

PackageReference
PackageReference 形式
Visual Studio 2017 登場時、依存関係の管理はそれまでに使用されていた packages.config ではなく、
プロジェクトファイル内部に PackageReference として保持するようになった。
.NET 6 では PackageReference 形式による依存の管理が必須である。
<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Newtonsoft.Json" version="13.0.1" targetFramework="net40" />
</packages>
packages.config
<ItemGroup>
<PackageReference Include="Newtonsoft.Json">
<Version>13.0.*</Version>
</PackageReference>
</ItemGroup>
～.csproj
旧
新
https://docs.microsoft.com/ja-jp/nuget/consume-packages/migrate-packages-config-to-package-reference

Transitive dependency
推移的な依存
直接指定した依存先が依存している先のことを推移的な依存という。
推移的な依存先の依存先も推移的な依存となる。（再帰的にすべて推移的な依存）
packages.config パッケージA
パッケージB
パッケージC
パッケージD
依存の依存の依存・・・もすべて
推移的な依存
直接依存
推移的な依存
～.csproj
or
推移的な依存が全て記載
されている場合がある

Migrate your NuGet packages to PackageReference
packages.config から PackageReference へ移行
packages.config による管理からプロジェクトファイル内の PackageReference へ移行が必須
• https://docs.microsoft.com/ja-jp/nuget/consume-packages/migrate-packages-config-to-
package-reference
Visual Studio の移行機能を使うと推移的な依存を削除確認しながら移行できる→直接依存＋αだけの管理に
未使用なら今後は不要！

SDK Style
SDKスタイル対応
プロジェクトファイルを SDK スタイルに変更

SDK Style
SDKスタイル
Visual Studio 2017登場時にリリースされた新しいプロジェクトファイルの形式。
<Project Sdk="Microsoft.NET.Sdk">
...
</Project>
• プロジェクトフォルダ内のファイルはプロジェクトで使用するもの。だからデフォル
トでプロジェクトで使用するファイル、とみなす
• 既定で除外されるものもある。リンク先を参照
• https://docs.microsoft.com/ja-jp/dotnet/core/project-sdk/overview#default-includes-and-excludes
• 初期設定をそのまま使うことがほとんどで、設定する箇所は一部しかない。だったら
その設定した値だけをプロジェクトファイルに保持することにした
プロジェクトファイルが次の要素で囲まれて入れば SDK スタイル。
って理解すればOK

SDK Style
SDKスタイル
フレームワークとSDKが紐づけられるようになった。表のID値を指定する
ID 説明リポジトリ
Microsoft.NET.Sdk .NET SDK https://github.com/dotnet/sdk
Microsoft.NET.Sdk.Web .NET Web SDK https://github.com/dotnet/sdk
Microsoft.NET.Sdk.BlazorWebAssembly .NET Blazor WebAssembly SDK
Microsoft.NET.Sdk.Razor .NET Razor SDK
Microsoft.NET.Sdk.Worker .NET Worker Service SDK
Microsoft.NET.Sdk.WindowsDesktop .NET デスクトップ SDK。これには Windows
フォーム (WinForms) と Windows Presentation
Foundation (WPF) が含まれています。*
https://github.com/dotnet/winforms およ
び https://github.com/dotnet/wpf
https://docs.microsoft.com/ja-jp/dotnet/core/project-sdk/overview#available-sdks
Windows フォームおよび Windows Presentation Foundation (WPF) プロジェクトでは、Microsoft.NET.Sdk.WindowsDesktop ではな
く .NET SDK (Microsoft.NET.Sdk) を指定し、TargetFramework を net6.0-windows に、UseWPF または UseWindowsForms を true に設定
するように変更された
...
</Project>

非SDKスタイル SDKスタイル
eShopLegacyMVCSolution
https://github.com/dotnet-architecture/eShopModernizing
.NET FrameworkでもOK！

SDK Style Details
SDK スタイルの詳細
https://docs.microsoft.com/ja-jp/dotnet/core/project-sdk/msbuild-props?view=aspnetcore-6.0
SDK スタイルのプロジェクトファイルに記載できる要素・属性については以下を参照
⚫ .NET SDK プロジェクトの MSBuild リファレンス
⚫ ASP.NET Core Web SDK
⚫ .NET Desktop SDK プロジェクトの MSBuild リファレンス（日本語版は情報が古いままなので注意）
https://docs.microsoft.com/en-us/dotnet/core/project-sdk/msbuild-props-desktop?view=aspnetcore-6.0
⚫ ASP.NET Core Razor SDK
https://docs.microsoft.com/ja-jp/aspnet/core/razor-pages/web-sdk?view=aspnetcore-6.0
https://docs.microsoft.com/ja-jp/aspnet/core/razor-pages/sdk?view=aspnetcore-6.0

Investigation of dependents
依存先の調査
依存先の .NET 6 対応可否を調査

Three patterns of dependents
依存先の3パターン
1. NuGet パッケージ 2. プロジェクト参照
3. DLL のみ存在する
非 NuGet パッケージ

Analyze your package dependencies
NuGet パッケージの .NET 6 対応の確認方法
NuGet ギャラリー
更新候補のバー
ジョンを指定
.NET Standard
or .NET Core の依
存があれば、.NET
6 で機能する
Versions 選択 Dependencies 選択
Dependencies の調査は fuget.org
の方がやりやすい
https://www.fuget.org/

Do not go along with breaking changes to libraries
NuGet パッケージ更新時の破壊的変更
• メジャーバージョンアップは、破壊的変更になる場合が多い
ライブラリの破壊的変更によるエラーの修正は厄介なことが多い
.NET 6 移行によるエラーと混在すると解決が困難になる
ライブラリの Upgrade は別の機会でやりましょう

Examples of breaking changes in libraries
ライブラリの破壊的変更例
ex: MahApps.Metro
WPF の共通コントロールを Modern UI に上書きするライブラリ
Ver 1.6.5から Ver 2.x へ移行できそう
Webで確認すると
破壊的変更が大量に！
全然わか
らない！

Library of project references
プロジェクト参照先のライブラリも移行するか
• 一緒に .NET 6 へ移行しなくても良い場合がある
.NET プロジェクト
.NET Framework
プロジェクト
プロジェクト参照先のライブラリ
が .NET Framework の場合
クラスライブラリ

.NET Framework compatibility mode
.NET Framework 互換モード
.NET Framework で作成されたライブラリは移行不要の可能性あり
.NET Standard
プロジェクト
.NET Framework
プロジェクト
.NET Standard 2.0
として参照
.NET Framework 4.8
.NET Framework 4.7.x
.NET Framework 4
.NET Framework 3.5
.NET Framework 3.0
.NET Framework 2.0
ただし、互換モードは完璧な移植ではない。例えば Windows
Presentation Foundation (WPF) API を使用している場合などは機
能しないので注意
https://docs.microsoft.com/ja-jp/dotnet/core/porting/third-party-deps#net-framework-compatibility-mode

Non-NuGet dependencies
DLL のみ存在する非 NuGet パッケージ
サードパーティ製のライブラリが GAC （Global Assembly Cache）にインストールされていた場合
や、社内開発のライブラリ・フレームワークなどは NuGet管理されていない可能性がある
1. 開発元 / 開発者に連絡して対応可否を問い合わせる
2. .NET Portability Analyzer で解析する
ちなみにGACは .NET Core以降は
非推奨になっている
• .NET 6 で動くかどうかをどうやって確認するか
• .NET 6 で動かない場合、どうするか
確認方法
確認した結果、.NET 6 では稼働しない、または稼働するか不明だった場合
1. 他の .NET 対応済みライブラリに差し替えて再実装
2. 移行を諦める（！）

Examples of .NET Portability Analyzer use
.NET Portability Analyzer の使用例
MahApps.Metro Version=1.6.5.1 が .NET 5 に移行できるかを解析（互換性 100% となっているので問題ない）

Check so far
ここまでを確認

Basic migration flow
基本的な移行の流れ
1. packages.config を PackageReference に変更
2. プロジェクトファイルを SDK スタイルに変更
3. ビルド＆稼動確認
4. 依存先の .NET 6 対応可否を調査
5. （オプション）.NET Portability Analyzer で実装コードの API 互換をチェック
• 移行事前作業
1. Target Framework を .NET 6 に変更
2. 依存先を .NET 6 での稼働が問題がないバージョンに（必要なら） Upgrade
3. ビルド
4. エラー修正（.NET 6 API 対応）
5. ビルド
• 移行
再掲
＋フレームワーク対応がどこかに追加

Migrate to .NET 6
.NET 6 へ変更
ターゲットフレームワークを .NET 6 へ変更

Migrate to .NET 6
.NET 6 へ変更
使用フレームワークによって少し設定値が異なる場合がある（.NET 5+ OS 固有の TFM）
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net472</TargetFramework>
<RootNamespace>ConsoleApp</RootNamespace>
<AssemblyName>ConsoleApp</AssemblyName>
<GenerateAssemblyInfo>false</GenerateAssemblyInfo>
</PropertyGroup>
</Project>
<PropertyGroup>
<TargetFramework>net6.0</TargetFramework>
<RootNamespace>ConsoleApp</RootNamespace>
<AssemblyName>ConsoleApp</AssemblyName>
</PropertyGroup>
</Project>
Consoleアプリケーション
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<OutputType>WinExe</OutputType>
<UseWPF>true</UseWPF>
<RootNamespace>WpfApp</RootNamespace>
<AssemblyName>WpfApp</AssemblyName>
</PropertyGroup>
</Project>
<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">
<PropertyGroup>
<TargetFramework>net6.0-windows</TargetFramework>
<RootNamespace>WpfApp</RootNamespace>
<AssemblyName>WpfApp</AssemblyName>
</PropertyGroup>
</Project>
https://docs.microsoft.com/ja-jp/dotnet/standard/frameworks
WPF アプリケーション

Migrate dependencies
依存先を
Upgrade
依存先を .NET 6 での稼働が問題がないバージョンに（必要な
ら） Upgrade

Migrate dependencies
依存先を .NET 6 対応バージョンに
Upgrade
事前に調査しておいた通りに必要なものを、必要なバージョンにまで Upgrade する
⚫ Visual Studio の NuGet パッケージの管理 GUI
⚫ NuGet CLI
⚫ Visual Studio の NuGet パッケージマネージャーコンソール
https://docs.microsoft.com/ja-jp/nuget/reference/ps-reference/ps-ref-update-package
EX: Update-Package -Id Elmah -Version 1.1.0
https://docs.microsoft.com/ja-jp/nuget/reference/cli-reference/cli-ref-update
EX: nuget update -Id Elmah -Version 1.1.0

Actions for API
API への対応

Actions for API
API への対応
.NET で使用できない .NET
Framework テクノロジがあ
る
.NET で常に例外をスローす
る API がある
挙動が変更された API
がある

Actions for API
API への対応
• .NET で使用できない .NET Framework テクノロジがある
• .NET で常に例外をスローする API がある
再実装が必要。中には破壊的変更としてマークされているものも
あるため、警告表示される。使用できなくなった .NET
Framework テクノロジのうちの一部は、ビルドは通るが実行時
に例外をスローするものもあるため要注意
https://docs.microsoft.com/ja-jp/dotnet/core/porting/net-framework-tech-unavailable
https://docs.microsoft.com/ja-jp/dotnet/core/compatibility/unsupported-apis

Actions for API
API への対応
• 挙動が変更された API がある
• .NET Framework と .NET 間であっても、下位互換性を維持するよ
うに破壊的変更に対してポリシーが策定されている
• しかし、ビルドが通っても挙動が変わっている可能性はゼロでは
ない
• 破壊的変更となり得る箇所については警告が表示される
https://docs.microsoft.com/ja-jp/dotnet/core/compatibility/
https://docs.microsoft.com/ja-jp/dotnet/core/compatibility/fx-core

Tools for migration
移行用のツール
.NET Upgrade Assistant

Reduce time and difficulty modernizing
older .NET codebases
Guided, step-by-step experience
Multiple project types supported
C# & VB.NET languages
Supports .NET 6
Learn more: aka.ms/dotnet-upgrade-assistant

Projects supported by this tool
.NET Upgrade Assistant の対応フレームワーク
• Windows Forms
• Windows Presentation Foundation (WPF)
• ASP.NET MVC
• コンソールアプリケーション
• クラスライブラリ
今後、もっと増える予定あり

複数プロジェクトへの対応
• どのプロジェクトがアップグレードが必要かを特定し、アップグレードする順序をお勧めします
SDKスタイルへの対応
• プロジェクトファイルをSDKスタイルのプロジェクトに更新します
依存関係への対応
• packages.configに存在している可能性のある推移的なNuGetパッケージの依存関係を削除します
• NuGetパッケージの依存関係を、.NET 現行、LTS、またはプレビューと互換性のあるバージョンに更新します
ターゲットフレームワークへの対応
• プロジェクトを.NET 現行、LTS、またはプレビューに再ターゲットします
APIへの対応
• Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzersパッケージなど、アップグレードに役立つアナライ
ザーへの参照を追加します
• C＃ソースコードを簡単に更新して、.NET Framework で機能していたパターンを現行、LTS、またはとプレビューと
同等なものに置き換えます
• 一部のアプリモデル（ASP.NETアプリなど）では、共通のテンプレートファイル（startup.csなど）を追加し、認識
された web.config または app.config の値に基づいて簡単な更新を行います
• Windowsを対象とするプロジェクトの場合、Microsoft.Windows.Compatibilityパッケージへの参照を追加します
What the .NET Upgrade Assistant solves
.NET Upgrade Assistant の提供するタスク

Upgrade Command
Upgrade コマンド
1. バックアップ
2. SDK スタイルへの変更
3. NuGet 参照のクリーンアップ（＋Upgrade 用コードアナライザ追加）
4. ターゲットフレームワークの変更
5. NuGet パッケージの更新
6. テンプレートファイルの追加
7. フレームワーク別の処理
• Config ファイルの変換
• 名前空間の変更
• 単純に置換で対応可能なソース修正
• など
• 処理順と内容
• 手順をスキップすることができる
• 途中で止めることができる（後で途中から再開もできる）
重要！
ツールに任せた
い箇所
ツール頼みは危
険な個所
共通処理
フレームワーク別の処理

Upgrade command
Upgrade コマンドの例
1. Back up project
2. Convert project file to SDK style
3. Clean up NuGet package references
4. Update TFM
5. Update NuGet Packages
6. Add template files
7. Update Winforms Project
a. Default Font API Alert
b. Winforms Source Updater
8. Upgrade app config files
a. Convert Application Settings
b. Convert Connection Strings
c. Disable unsupported configuration sections
9. Update source code
a. Apply fix for UA0002: Types should be upgraded
b. Apply fix for UA0012: 'UnsafeDeserialize()' does not exist
10. Move to next project
Windows From に対して最初に実行
した時に表示される結果 1. Back up project
2. Convert project file to SDK style
3. Clean up NuGet package references
4. Update TFM
5. Update NuGet Packages
6. Add template files
7. Upgrade app config files
a. Convert Application Settings
b. Convert Connection Strings
c. Disable unsupported configuration sections
d. Convert system.web.webPages.razor/pages/namespaces
8. Update Razor files
a. Apply code fixes to Razor documents
b. Replace @helper syntax in Razor files
9. Update source code
a. Apply fix for UA0001: ASP.NET Core projects should not reference ASP.NET namespaces
b. Apply fix for UA0002: Types should be upgraded
c. Apply fix for UA0005: Do not use HttpContext.Current
d. Apply fix for UA0006: HttpContext.DebuggerEnabled should be replaced with
System.Diagnostics.Debugger.IsAttached
e. Apply fix for UA0007: HtmlHelper should be replaced with IHtmlHelper
f. Apply fix for UA0008: UrlHelper should be replaced with IUrlHelper
g. Apply fix for UA0010: Attributes should be upgraded
h. Apply fix for UA0012: 'UnsafeDeserialize()' does not exist
10. Move to next project
ASP.NET Core 2.2 (.NET Framework 4.6.1)に対して
最初に実行した時に表示される結果
共通処理
フレームワーク別の処理

How to use the .NET Upgrade Assistant
.NET Upgrade Assistant の使いどころ
ツール頼みでの100%移行は難しい。手動による移行の補助として使うことをおススメ
基本的な移行タスクは全てやってくれる！でも細かいところは手動でやらなければならない
場合も多い
• 依存パッケージ数が多すぎると推移的な依存を削除できずエラーになることがある
• なぜか未対応のフレームワークと判定されて処理してくれないことがある
• ASP.NET Core（MVC）の場合はフレームワークが大幅に変更されているため、ツールによるフレームワーク別の
処理の適用タイミングを計らないと修正箇所が多すぎて大変
ツールがうまく適用できない場合の例

Actions by framework type

• .NET Framework Windows Form / WPF アプリケーション
• .NET Framework ASP.NET MVC アプリケーション
• Xamarin.Form, Xamarin ネイティブ
• .NET Framework コンソールアプリケーション
• .NET Framework クラスライブラリ
• など
Actions by framework type
• .NET 非対応フレームワーク
• .NET 対応フレームワーク
• ASP.NET Web Form
• ASP.NET Web Pages
• WCF サービス（サーバーサイド）
• ワークフローに関連するサービス
• Windows Workflow Foundation (WF)
• ワークフローサービス (1 つのサービスに WCF と WF) および WCF Data Services (旧
称: ADO.NET Data Services)
要するに非対応フレーム
ワーク以外

.NET – enabled framework migration
.NET 対応フレーム
ワークの移行

Migration policy by framework
フレームワーク別対応方針
• .NET Framework Windows Form / WPF アプリケーション
• .NET Framework ASP.NET MVC アプリケーション
• Xamarin.Form、Xamarin ネイティブ
• .NET Framework コンソールアプリケーション
• .NET Framework クラスライブラリ
• など
コンソールアプリケーションとクラスライブラリは「基本的な移行の流れ」で移行可能。ただし、
Linux など Windows 以外のプラットフォームでも稼働するようにしたい場合は .NET Platform
Compatibility Analyzer で確認すると「PlatformNotSupportedException 」をスローする API を
使用しているかどうかがわかる
https://docs.microsoft.com/ja-jp/dotnet/standard/analyzers/platform-compat-analyzer
この後説明

Windows Form / WPF
Windows Form / WPF の移行
「基本的な移行の流れ」で紹介した通りで移行可能だが、Windows 固有の API を使用してい
る場合は（大抵の場合はそう） Windows 互換性パッケージの参照を加える
※ 移行作業の実際については、Appendixを参照
<ItemGroup>
<PackageReference Include="Microsoft.Windows.Compatibility" Version="6.0.0" />
</ItemGroup>
Windows 互換性パッケージ
https://docs.microsoft.com/ja-jp/dotnet/core/porting/windows-compat-pack
SDK 形式のプロジェクトファイルにこの PackageReferece を追加

ASP.NET Core MVC
ASP.NET Core MVC の移行
ASP.NET, ASP.NET Core はバージョン間の破壊的変更が激しいので移行が難しい
ASP.NET MVC 3~5 ASP.NET Core MVC 2.2 ASP.NET Core MVC 3.1 ASP.NET Core MVC 6
そこで、ASP.NET Core MVC 2.2 の特徴を活かす
この移行方法は個人的にお勧めするものです
.NET Framework 4.x
.NET Core 2.2 .NET Core 3.1 .NET 6
ASP.NET Core MVC 2.2 だけが、現在は唯一
.NET Framework も .NET Core でも稼働する
※ただし、.NET Core 2.2 は既にサポートが切れているので、あくまで移行途中に使う

Migration Path
移行パス
ASP.NET MVC 3~5
.NET Framework 4.x
ASP.NET Core MVC 2.2
.NET Framework 4.x
.NET Core 2.2
Visual Studio 2017
Visual Studio 2019/2022
.NET Core 3.1
Visual Studio 2022
.NET 6
ASP.NET Core MVC 6
Visual Studio 2010/2013/2015/2017
Visual Studio 2017/2019
変更量大
変更量小～中変更量小～中
変更量小
• ASP.NET Core MVC 2.2 プロジェク
トを作成（SDKスタイル＋Package
Reference）し、手動で移行
• 直接参照しているパッケージのみ
をだけを参照するように修正
• Upgrade-AssistantでTFM更新をス
キップして他タスクをすべて処理
• TFMを手動で netcoreapp2.2に変更
• Upgrade-Assistantで全タスク実行
※この移行パスは個人的なお勧めです
• TFMを netcoreapp3.1に変更

VS 2017 だけが作成可能な ASP.NET Core MVC 2.2
SDKを Install する場合は x64 版を
ASP.NET MVC から ASP.NET Core MVC 2.2 への移行
https://docs.microsoft.com/ja-jp/aspnet/core/migration/mvc?view=aspnetcore-2.2

.NET MAUI (Multi-platform App UI)
Xamarin.Forms migration
Xamarin.Forms の移行
1 つの共有コードベースから Android、iOS、macOS、Windowsで実行できるアプリを開発可能
.NET MAUIは、データの表示、アクションの開始、アクティビティの表示、コレクションの表示、データ
のピックなどに使用できるコントロールのコレクションを提供。
PREVIEW
Xamarin.Forms の移行先は .NET MAUI。
でもまだ Preview だから
移行してはダメ。
https://devblogs.microsoft.com/dotnet/update-on-dotnet-maui/

What about the Xamarin native migration?
Xamarin ネイティブの移行は？
その前に、.NET MAUI の内部について少し理解する
.NET MAUI API を使用してコードを実装する
.NET MAUI は各プラットフォーム API を使用する
プラットフォームのAPIを直接叩く実装も可能
1
2
3
ということは、プラットフォーム API だけを
使って実装するテンプレートがあるはず
https://docs.microsoft.com/ja-jp/dotnet/maui/what-is-maui#how-net-maui-works 各プラットフォーム用のAPI

Xamarin ネイティブの移行は？
これだ！
テンプレートがある

Visual Studio 2022 Preview にテンプレートもある（プレビューだけど）
名前が変更されたが、
推移的な依存先として
今までの SDKをまだ使
用しているみたい

.NET – non enabled framework migration
.NET 非対応フレーム
ワークの移行

Migration policy by framework
フレームワーク別対応方針
• ASP.NET Web Form
• ASP.NET Web Pages
• WCF サービス（サーバーサイド）
• ワークフローに関連するサービス
• Windows Workflow Foundation (WF)
• ワークフローサービス (1 つのサービスに WCF と WF) および WCF
Data Services (旧称: ADO.NET Data Services)
この後説明
この後説明
◆ ASP.NET Web Pages は ASP.NET Core Razor Pages が移行先となり得るが、移行に関する情報が
公式にはないため、手動で頑張ることになる。これを機に ASP.NET Core MVC へ移行もアリ

別のフレームワーク
Basic migration policy
基本的な移行方針
• フレームワーク依存の箇所以外を別プロジェクトへ移動
.NET Standard 2.0
ライブラリ
.NET Framework
プロジェクト
表示
ロジック
ビジネス
ロジック
データ
アクセス
※再構築対象はできるだけ小さくする！

ASP.NET Web Form migration
ASP.NET Web Form
の移行

ASP.NET Web Form migration
ASP.NET Web Form の移行
• Blazor WebAssembly へ移行する
• ビジネスロジックは、ASP.NET Core ベースの WebAPI にして、Blazor
から WebAPI を呼び出す
表示ロジックは Blazor へ移植する
方法その１
• Blazor Serverへ移行する（ASP.NET Web Formと非常に相性が良い）
方法その２
おすすめ！
要件については要確認
• クライアントのブラウザのバージョンは問題ないか
• ブラウザとの通信に用いられる SignalR で通信可能か

Porting to Blazor Server
Blazor Server に移植する
Blazorに移植された Web Form コントロールがある！
オープンソースコミュニティプロジェクト
https://fritzandfriends.github.io/BlazorWebFormsComponents/
Editor Controls
• AdRotator
• Button
• HiddenField
• HyperLink
• Image
• ImageButton
• Label
• LinkButton
• Literal
Data Controls
• DataList
• FormView
• GridView
• ListView
• Repeater
Validation Controls
• CustomValidator
• RegularExpressionValidator
• RequiredFieldValidator
• ValidationSummary
Navigation Controls
• TreeView
Utility Features
• Databinder
• ViewState

Blazor WebForms Components
Blazor WebForms Components
ASP.NET WebForm からの移行についての解説ページがある
ASP.NET WebForms のコントロールほどの機能は持っていないものが多いような
ので、使用にあたってはよく検討が必要

Details about porting to Blazor
Blazor に移植する方法の詳細情報
ASP.NET Web Forms 開発者向け Blazor
https://docs.microsoft.com/ja-jp/dotnet/architecture/blazor-for-web-forms-developers/

WCF (server-side) migration policy
WCF（サーバーサイド）の移行方針
※WCFクライアントは、Windows互換パッケージに含まれているので .NET 6 へ移行可能！
方法その１おすすめ！
• gRPC による再構築
• CoreWCFの採用
方法その２

Rebuilding with gRPC
gRPC による再構築
gRPCの再構築のイメージ
WCFの構成
[DataContract]
・[DataMember]
・[DataMember]
・[DataMember]
[ServiceContract]
・[OperationContract]
service
service
service
message
message
message
～.proto
～.cs
～.cs
～.cs
抽象サービスクラス
データのコンテナクラス
VSが自動生成
~.config
クライアントクライアント
サービス参照からProxyクラスを自動生成サービス参照からProxyクラスを自動生成
要実装
gRPC による再構築時の注意
• サーバーは http/2が必須。ホスティング環境に注意
• クライアントサイドも gRPC に対応が必要

Information of gRPC for .NET
.NET の gRPC 情報
https://docs.microsoft.com/ja-jp/aspnet/core/grpc/?view=aspnetcore-6.0
⚫ .NET の gRPC の概要
⚫ ASP.NET Core を使用した gRPC サービス
https://docs.microsoft.com/ja-jp/aspnet/core/grpc/aspnetcore?view=aspnetcore-6.0&tabs=visual-studio
⚫ WCF 要求 - 応答サービスを gRPC 単項 RPC に移行する
https://docs.microsoft.com/ja-jp/dotnet/architecture/grpc-for-wcf-developers/migrate-request-reply
おすすめ！
⚫ WCF 開発者向け ASP.NET Core gRPC
https://docs.microsoft.com/ja-jp/dotnet/architecture/grpc-for-wcf-developers/

Adoption of Core WCF
Core WCF の採用
https://github.com/CoreWCF/CoreWCF
Core WCFは、Windows Communication Foundation (WCF) の.NET Coreへの移植版です。このプロ
ジェクトの目標は、既存のWCFプロジェクトが.NET Coreに移行できるようにすることです。
※新規開発用ではない、ということ
あくまでもコミュニティベースであることをお忘れなく

aka.ms/msdevday2022-migrate
セッション資料のダウンロードはこちらから

◼ 本書に記載した情報は、本書各項目に関する発行日現在の Microsoft の見解を表明するものです。Microsoftは絶えず変化する市場に対応しなければならないため、ここに記載した情報に
対していかなる責務を負うものではなく、提示された情報の信憑性については保証できません。
◼ 本書は情報提供のみを目的としています。 Microsoft は、明示的または暗示的を問わず、本書にいかなる保証も与えるものではありません。
◼ すべての当該著作権法を遵守することはお客様の責務です。Microsoftの書面による明確な許可なく、本書の如何なる部分についても、転載や検索システムへの格納または挿入を行うこと
は、どのような形式または手段（電子的、機械的、複写、レコーディング、その他）、および目的であっても禁じられています。これらは著作権保護された権利を制限するものではあり
ません。
◼ Microsoftは、本書の内容を保護する特許、特許出願書、商標、著作権、またはその他の知的財産権を保有する場合があります。Microsoftから書面によるライセンス契約が明確に供給さ
れる場合を除いて、本書の提供はこれらの特許、商標、著作権、またはその他の知的財産へのライセンスを与えるものではありません。
◼ Microsoft, Windows, その他本文中に登場した各製品名は、Microsoft Corporation の米国およびその他の国における登録商標または商標です。
その他、記載されている会社名および製品名は、一般に各社の商標です。
aka.ms/msdevday2022-migrate
セッション資料のダウンロードはこちらから

Has the time really come?
時は本当に来たのか

 .NET Framework 4.8 が最後のメジャーバージョンとなる予定
 サポートライフサイクルポリシーは変更なし
 インストール先の Windows OS と同じライフサイクルポリシーが適用
 Windows OS のコンポーネントとしてサポート (更新プログラム等)
 (参考) ライフサイクルに関する FAQ – .NET Framework :
https://support.microsoft.com/ja-jp/help/17455/lifecycle-faq-net-framework
.NET Framework の今後について
じゃあ移行しなくて良い
じゃないか！

.NET 6 へ移行するモチベーション
パフォーマンスの劇的な改善
圧倒的にこれ！
でもどれぐらい改善したのか次第ではないか？

.NET 6 benchmark
.NET 6 ベンチマーク
JIT
インライン化
| Runtime | Mean | Ratio | Code Size |
|------------------- |----------:|------:|----------:|
| .NET 6.0 | 9.256 ns | 0.38 | 577 B |
| .NET Core 3.1 | 21.230 ns | 0.87 | 1,628 B |
| .NET Framework 4.8 | 24.400 ns | 1.00 | 1,126 B |
環境
BenchmarkDotNet=v0.13.1, OS=Windows 10.0.22000
Intel Core i7-8665U CPU 1.90GHz (Coffee Lake), 1 CPU, 8 logical and 4 physical cores
.NET Framework 4.8 (4.8.4420.0), X64 RyuJIT
.NET 6.0.1 (6.0.121.56705), X64 RyuJIT
.NET Core 3.1.22 (CoreCLR 4.700.21.56803, CoreFX 4.700.21.57101), X64 RyuJIT
.NET Framework 4.8 (4.8.4420.0), X64 RyuJIT
JIT
インライン化＋値型への自動仮想化解除
|------------------- |----------:|------:|----------:|
| .NET 6.0 | 2.856 ns | 0.15 | 186 B |
| .NET Core 3.1 | 8.829 ns | 0.47 | 214 B |
| .NET Framework 4.8 | 18.816 ns | 1.00 | 240 B |
MS公式ではなく個人の実験結果です！

JIT
インライン化＋ボクシング自動回避＆仮想化解除
|------------------- |----------:|------:|----------:|
| .NET 6.0 | 0.2344 ns | 0.03 | 27 B |
| .NET Core 3.1 | 5.3980 ns | 0.59 | 66 B |
JIT
インライン化＋PGO有効（profile-guided optimization)
|------------------- |----------:|------:|----------:|
| .NET 6.0 | 0.6383 ns | 0.36 | 105 B |
| .NET Core 3.1 | 2.2463 ns | 1.51 | 32 B |
JIT
境界チェック
|------------------- |----------:|------:|----------:|
| .NET 6.0 | 2.584 ns | 0.23 | 103 B |
| .NET Core 3.1 | 4.783 ns | 0.43 | 141 B |
JIT
ボクシング最適化
|------------------- |----------:|------:|----------:|
| .NET 6.0 | 62.20 ns | 0.31 | 522 B |
| .NET Core 3.1 | 134.96 ns | 0.62 | 164 B |
JIT
除算最適化
|------------------- |----------:|------:|----------:|
| .NET 6.0 | 0.1264 ns | 0.51 | 21 B |
| .NET Core 3.1 | 0.2525 ns | 1.18 | 23 B |
JIT
偶数チェック
|------------------- |----------:|------:|----------:|
| .NET 6.0 | 0.0000 ns | ? | 10 B |
| .NET Core 3.1 | 0.3200 ns | ? | 19 B |
| .NET Framework 4.8 | 0.1933 ns | ? | 19 B |

JIT
配列の境界チェック
|------------------- |----------:|------:|----------:|
| .NET 6.0 | 0.2999 ns | 0.09 | 48 B |
| .NET Core 3.1 | 1.3982 ns | 0.87 | 89 B |
Threading
Task.WaitAsyncSemaphoreSlim.WaitAsync
| Method | Runtime | Mean | Ratio | Code Size |
|-------------------------------- |------------------- |---------:|------:|----------:|
| WithCancellationToken | .NET 6.0 | 1.632 us | 0.36 | 1,352 B |
| WithCancellationToken | .NET Core 3.1 | 1.887 us | 0.42 | 1,239 B |
| WithCancellationToken | .NET Framework 4.8 | 4.501 us | 1.00 | 1,154 B |
| | | | | |
| WithTimeout | .NET 6.0 | 1.739 us | 0.34 | 1,270 B |
| WithTimeout | .NET Core 3.1 | 2.373 us | 0.48 | 1,221 B |
| WithTimeout | .NET Framework 4.8 | 4.918 us | 1.00 | 1,104 B |
| | | | | |
| WithCancellationTokenAndTimeout | .NET 6.0 | 1.867 us | 0.32 | 1,289 B |
| WithCancellationTokenAndTimeout | .NET Core 3.1 | 2.555 us | 0.48 | 1,238 B |
| WithCancellationTokenAndTimeout | .NET Framework 4.8 | 5.892 us | 1.00 | 1,192 B |

Threading
CancellationToken
System Types
Guid
|---------------------------------- |------------------- |----------:|------:|----------:|
| CreateTokenDispose | .NET 6.0 | 11.37 ns | 0.74 | 328 B |
| CreateTokenDispose | .NET Core 3.1 | 13.31 ns | 0.86 | 385 B |
| CreateTokenDispose | .NET Framework 4.8 | 16.01 ns | 1.00 | 201 B |
| | | | | |
| CreateRegisterDispose | .NET 6.0 | 92.04 ns | 0.43 | 1,069 B |
| CreateRegisterDispose | .NET Core 3.1 | 133.91 ns | 0.65 | 1,205 B |
| CreateRegisterDispose | .NET Framework 4.8 | 215.67 ns | 1.00 | 618 B |
| | | | | |
| CreateLinkedTokenDispose | .NET 6.0 | 68.30 ns | 0.49 | 989 B |
| CreateLinkedTokenDispose | .NET Core 3.1 | 85.81 ns | 0.53 | 518 B |
| CreateLinkedTokenDispose | .NET Framework 4.8 | 169.19 ns | 1.00 | 637 B |
| | | | | |
| CreateManyRegisterDispose | .NET 6.0 | 62.23 ns | 0.48 | 1,173 B |
| CreateManyRegisterDispose | .NET Core 3.1 | 53.93 ns | 0.41 | 1,372 B |
| CreateManyRegisterDispose | .NET Framework 4.8 | 131.67 ns | 1.00 | 637 B |
| | | | | |
| CreateManyRegisterMultipleDispose | .NET 6.0 | 277.77 ns | 0.46 | 2,090 B |
| CreateManyRegisterMultipleDispose | .NET Core 3.1 | 287.58 ns | 0.48 | 2,424 B |
| CreateManyRegisterMultipleDispose | .NET Framework 4.8 | 613.95 ns | 1.00 | 1,230 B |
|------------------- |----------:|------:|----------:|
| .NET 6.0 | 38.08 ns | 0.13 | 167 B |
| .NET Core 3.1 | 117.96 ns | 0.40 | 181 B |
System Types
Version
|------------------- |----------:|------:|----------:|
| .NET 6.0 | 66.25 ns | 0.30 | 202 B |
| .NET Core 3.1 | 186.50 ns | 0.89 | 244 B |

System Types
Random.Next
| Method | Runtime | Mean | Ratio Code Size |
|---------------- |------------------- |-------------------:|------:----------:|
| Ctor | .NET 6.0 | 151.135 ns | 0.18 149 B |
| Ctor | .NET Core 3.1 | 2,401.338 ns | 2.83 623 B |
| Ctor | .NET Framework 4.8 | 855.371 ns | 1.00 415 B |
| | | | |
| Next | .NET 6.0 | 2.228 ns | 0.23 61 B |
| Next | .NET Core 3.1 | 10.573 ns | 1.11 18 B |
| Next | .NET Framework 4.8 | 9.711 ns | 1.00 18 B |
| | | | |
| NextMax | .NET 6.0 | 3.782 ns | 0.32 71 B |
| NextMax | .NET Core 3.1 | 12.559 ns | 1.08 23 B |
| NextMax | .NET Framework 4.8 | 11.686 ns | 1.00 23 B |
| | | | |
| NextMinMax | .NET 6.0 | 2.736 ns | 0.23 251 B |
| NextMinMax | .NET Core 3.1 | 13.231 ns | 1.19 26 B |
| NextMinMax | .NET Framework 4.8 | 11.622 ns | 1.00 26 B |
| | | | |
| NextDouble | .NET 6.0 | 3.929 ns | 0.38 64 B |
| NextDouble | .NET Core 3.1 | 10.737 ns | 1.05 17 B |
| NextDouble | .NET Framework 4.8 | 10.385 ns | 1.00 17 B |
| | | | |
| NextBytes_Array | .NET 6.0 | 1,746,021.566 ns | 0.02 90 B |
| NextBytes_Array | .NET Core 3.1 | 105,932,542.570 ns | 1.45 35 B |
| NextBytes_Array | .NET Framework 4.8 | 75,829,165.686 ns | 1.00 35 B |
System Types
Environment
|------------------- |---------:|------:|----------:|
| .NET 6.0 | 10.24 us | 0.70 | 1 KB |
| .NET Core 3.1 | 19.89 us | 1.25 | 1 KB |
| .NET Framework 4.8 | 15.82 us | 1.00 | 1 KB |
System Types
Enum
|---------- |------------------- |----------:|------:|----------:|
| IsDefined | .NET 6.0 | 141.85 ns | 0.57 | 155 B |
| IsDefined | .NET Core 3.1 | 134.53 ns | 0.54 | 163 B |
| IsDefined | .NET Framework 4.8 | 253.01 ns | 1.00 | 155 B |
| | | | | |
| GetName | .NET 6.0 | 64.70 ns | 0.39 | 185 B |
| GetName | .NET Core 3.1 | 75.30 ns | 0.45 | 162 B |
| GetName | .NET Framework 4.8 | 166.93 ns | 1.00 | 156 B |
| | | | | |
| GetNames | .NET 6.0 | 38.89 ns | 0.53 | 121 B |
| GetNames | .NET Core 3.1 | 41.53 ns | 0.54 | 129 B |
| GetNames | .NET Framework 4.8 | 74.25 ns | 1.00 | 122 B |
System Types
DateTime.UtcNow
|------------------- |---------:|------:|----------:|
| .NET 6.0 | 27.27 ns | 0.41 | 109 B |
| .NET Core 3.1 | 75.95 ns | 1.16 | 115 B |

https://devblogs.microsoft.com/dotnet/performance-improvements-in-net-6/
パフォーマンス改善点は他にも山のようにある
詳細はこちら
.NET Framework と比べると
明らかに速い。
.NET Core 3.1 と比べても
やっぱり速い。
移行する価値はある。

WinForm/WPF Migration
WinForm/WPF を移行
する

WinForm/WPF Migration
Windows Form / WPF の移行
1. Windows Form / WPF は .NET Core 3.0 からオープンソースに
• https://github.com/dotnet/winforms
• https://github.com/dotnet/wpf
• それぞれのコードは .NET Framework のフォークなので、時間経過とともに違いが存在
する可能性があり、アプリの移行が困難になる可能性がある
2. Windows固有のAPIを使用している場合はWindows 互換性パッケージを使用する
• https://docs.microsoft.com/ja-jp/dotnet/core/porting/windows-compat-pack
https://docs.microsoft.com/ja-jp/dotnet/desktop/winforms/migration/?view=netdesktop-6.0
• コードページ
• CodeDom
• 構成
• ディレクトリサービス
• 描画
• ODBC
• アクセス許可
• ポート
• Windows アクセス制御リスト (ACL)
• Windows Communication Foundation (WCF)
• Windows 暗号化
• Windows EventLog
• Windows Management Instrumentation (WMI)
• Windows パフォーマンスカウンター
• Windows レジストリ
• Windows ランタイムキャッシュ
• Windows サービス

Migration path
移行パス（手動）
https://docs.microsoft.com/ja-jp/dotnet/desktop/winforms/migration/?view=netdesktop-6.0
1. .NET Portability Analyzer で使用不可になったAPIを使っている箇所を洗い出し
2. packages.config を Package Reference に変更する
• Visual Studio 2017以降の移行機能を使う（推移的依存関係は含めないようにする）
3. csproj ファイルをバックアップ
4. csproj を SDK スタイルに変更する
① csprojをアンロードし、編集。csprojの内容をすべて削除
② WindowsForm / WPF 用の SDKスタイルのテンプレを貼り付ける
③ RootNamespace と AssemblyName 要素を PropertyGroup 要素内へコピー
④ プロジェクト参照の移行
• ProjectReference を含む ItemGroup を Project 要素内へコピー
• ProjectReference の持つ Project 要素と Name 要素は不要なので削除
⑤ パッケージ参照の移行
• PackageReference を含む ItemGroup を Project要素内へコピー
5. Windows互換性パッケージを追加する
• Version=6.0.0以上
6. csproj を再読み込み
7. app.configを修正
• supportedRuntime 要素を削除
8. 稼働確認
• リンク先ではリソースの移行手順があるが、プロジェクトディレクトリ
配下の code ファイルは自動的に含まれる仕様に変わったため設定不要
• オプトイン（必要なものを指定）からオプトアウト（不要なものを指
定）への仕様変更、と表現されている
※VBプロジェクトは追加設定が必要（リンク先参照）

Template of SDK
SDK スタイルのテンプレート
<PropertyGroup>
<UseWindowsForms>true</UseWindowsForms>
</PropertyGroup>
</Project>
WindowsForm 用の SDKスタイルのテンプレ WPF 用の SDKスタイルのテンプレ
<PropertyGroup>
<Nullable>enable</Nullable>
</PropertyGroup>
</Project>

Migration example
移行例（Windows Form）
https://github.com/dotnet/samples/tree/main/windowsforms/matching-game/net45
サンプルプロジェクト
MatchingGame.Logic
.NET Framework 4.5.2
Windows Form
MatchingGame
神経衰弱みたいなゲーム

Results of the analysis
.NET Portability Analyzer
ApiPort.exe analyze -t ".NET, Version=5.0" -t ".NET + Platform Extensions" -r HTML -f “path¥to¥project¥directory"
サードパーティ製の
MetroFrameworkの互換性が担保
されていない、という結果に

Convert packages.config to a package reference
packages.config を Package Reference に変換

Backup csproj file
csproj ファイルをバックアップ
後でこのバックアップファイルから
項目をコピーするので、VSCodeで開いておく

Migrate csproj to SDK style
csproj を SDK スタイルに変更する
① csprojをアンロードし、編集。
csprojの内容をすべて削除
② WindowsForm 用の SDKスタイル
のテンプレを貼り付ける

③ RootNamespace と AssemblyName 要素を PropertyGroup 要素内へコピー
<PropertyGroup>
<RootNamespace>MatchingGame</RootNamespace>
<AssemblyName>MatchingGame</AssemblyName>
</PropertyGroup>
</Project>
Assembly.Info は既にあ
るので、自動生成させ
ない設定

④ プロジェクト参照の移行
• ProjectReference を含む
ItemGroup を Project 要
素内へコピー
• ProjectReference の
持つ Project 要素と
Name 要素は不要な
ので削除
⑤ パッケージ参照の移行
• PackageReference を含む
ItemGroup を Project要素
内へコピー
<PropertyGroup>
</PropertyGroup>
<ItemGroup>
<ProjectReference Include="..¥MatchingGame.Logic¥MatchingGame.Logic.csproj" />
</ItemGroup>
<ItemGroup>
<PackageReference Include="MetroFramework">
<Version>1.2.0.3</Version>
</PackageReference>
</ItemGroup>
</Project>

5. Windows互換性パッケージ
を追加する
• Version=6.0.0以上
<PropertyGroup>
</PropertyGroup>
<ItemGroup>
</ItemGroup>
<ItemGroup>
</PackageReference>
</ItemGroup>
<ItemGroup>
</ItemGroup>
</Project>

app.config を修正
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
</configSections>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
</configuration>
6. csproj を再読み込み
7. app.configを修正
• supportedRuntime 要素を削除

Rebuild and Run
リビルドして稼働確認
無事に稼働！
※今回はたまたま MetroFramework が実行時エラーとなる機
能を使用していなかった。MetroFramework は .NET 対応版が
無かったので、エラーとなった場合は実装し直す必要があっ
た

Use Upgrade-Assistant
Upgrade-Assistant で移行してみる
サンプルプロジェクトは
一発で移行に成功

手動と Upgrade-Assistant 使用の比較
<PropertyGroup>
</PropertyGroup>
<ItemGroup>
</ItemGroup>
<ItemGroup>
</PackageReference>
</ItemGroup>
<ItemGroup>
</ItemGroup>
</Project>
<PropertyGroup>
<ImportWindowsDesktopTargets>true</ImportWindowsDesktopTargets>
<WarningLevel>4</WarningLevel>
</PropertyGroup>
<ItemGroup>
</ItemGroup>
<ItemGroup>
<PackageReference Include="MetroFramework" Version="1.2.0.3" />
<PackageReference Include="Microsoft.CSharp" Version="4.7.0" />
<PackageReference Include="System.Data.DataSetExtensions" Version="4.5.0" />
<PackageReference
Include="Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzers"
Version="0.3.261602">
<PrivateAssets>all</PrivateAssets>
</PackageReference>
</ItemGroup>
</Project>
手動 Upgrade-Assistant

Migrate ASP.NET MVC
ASP.NET MVC
を移行する

恐らく最も破壊的変更が多い移行
1. ASP.NET MVC から ASP.NET Core MVC というフレームワークの移行
2. .NET Framework から .NET への移行
2つの異なる移行を同時に実現しなければならないが、Upgrade-Assistant は ASP.NET MVC
から ASP.NET MVC Core への移行は変更点が多すぎて全て対応しきれない。手動による作業
がかなり発生する

Differences between ASP.NET MVC and ASP.NET Core MVC
ASP.NET MVCと ASP.NET Core MVC の違い（一部）
• エントリポイントが明確になった
• Windows 以外でも稼働するようになった
• 既定では Kestrel Web サーバーでホスティングし、IIS, Nginx をリバースプロキシにする
• Global.asax が廃止
• OWINによく似た仕組みが ASP.NET Coreに組み込まれており、
ミドルウェアで対応する
• Dependency Injection が用意され、その使用が前提になった
• machine.config, web.configが廃止
• 既定の構成を appsettings.json で上書きする
• 構成へのアクセスが DI で簡単に
• 静的ファイルの扱い
• Pathに存在するファイルはルーティングしない挙動だった
• ミドルウェアで有効にする必要がある
（既定でミドルウェア組み込み済み）
ASP.NET MVC ASP.NET Core MVC

Example of migration
移行例
https://github.com/dotnet-architecture/eShopModernizing
eShopLegacy.Utilities
eShopPorted

移行例
VS2017を使用
.NET Framework 4.6.1か
らスタート
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Autofac.Extensions.DependencyInjection" Version="4.4.0" />
<PackageReference Include="Microsoft.AspNetCore" Version="2.2.0" />
<PackageReference Include="Antlr" Version="3.5.0.2" />
<PackageReference Include="Autofac" Version="4.9.1" />
<PackageReference Include="Autofac.Mvc5">
<Version>4.0.2</Version>
</PackageReference>
<PackageReference Include="log4net">
</PackageReference>
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.2.0" />
<PackageReference Include="Microsoft.EntityFrameworkCore" Version="2.2.6" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Design" Version="2.2.6" />
<PackageReference Include="Microsoft.EntityFrameworkCore.Relational" Version="2.2.6" />
<PackageReference Include="Microsoft.EntityFrameworkCore.SqlServer" Version="2.2.6" />
</PackageReference>
<PackageReference Include="WebGrease">
</PackageReference>
</ItemGroup>
<ItemGroup>
<ProjectReference Include="..¥eShopLegacy.Utilities¥eShopLegacy.Utilities.csproj" />
</ItemGroup>
</Project>
• SDKスタイル
• Package Reference

Upgrade-Assistant使用
TFM変更だけスキップする
※本当はこの作業の前に依存
関係を1つずつ調べて .NET 対
応しているかどうかを確認す
る必要がある。今回は依存関
係を最新化しても問題ないの
でこの手順でOK

エラー箇所を修正
稼動確認する→OK

移行例 <Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.AspNetCore" Version="2.2.0" />
</PackageReference>
</PackageReference>
<PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.2.0" />
<PackageReference Include="Microsoft.AspNetCore.StaticFiles" Version="2.2.0" />
</PackageReference>
</PackageReference>
<PackageReference Include="Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzers"
Version="0.3.261602">
</PackageReference>
</ItemGroup>
<ItemGroup>
</ItemGroup>
</Project>
ターゲットフレームワークを
.NET Core 2.2に変更する

移行例
※ここからVS2019を使う
<PropertyGroup>
</PropertyGroup>
<ItemGroup>

</PackageReference>
</PackageReference>

</PackageReference>
</PackageReference>
<PackageReference Include="Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzers" Version="0.3.261602">
</PackageReference>
</ItemGroup>
<ItemGroup>
</ItemGroup>
</Project>
ASP.NET Core 3.x 以降はSDKに
フレームワークが含まれるた
め、これらのパッケージ参照
は削除
ビルドはOK、稼動確認
すると、実行時エラー
となる
ターゲットフレームワークを
.NET Core 3.1 にする

実行時エラーを修正

Upgrade-Assistant 使用
ここで Upgrade-Assistant を使用して、
ASP.NET Core MVC 6(.NET 6)にし、そ
れに合わせてコード修正も適用する
ここから先は .NET 6 なので VS2022
を使用する

Upgrade-Assistant使用前後
<PropertyGroup>
</PropertyGroup>
<ItemGroup>
</PackageReference>
<PackageReference
Version="0.3.261602">
</PackageReference>
<PackageReference Include="Antlr4" Version="4.6.6" />
<PackageReference Include="Microsoft.AspNetCore.Mvc.NewtonsoftJson" Version="3.1.22" />
</ItemGroup>
<ItemGroup>
</ItemGroup>
</Project>
<PropertyGroup>
</PropertyGroup>
<ItemGroup>
</PackageReference>
</PackageReference>
</PackageReference>
</PackageReference>
<PackageReference
Version="0.3.261602">
</PackageReference>
</ItemGroup>
<ItemGroup>
</ItemGroup>
</Project>
使用前使用後

エラーを修正
System.Web.Mvc から
Microsoft.AspNetCore.Mvc に
名前空間が変更されているためのエラー

稼動確認
移行終了！！

Migrate Xamarin
Xamarin を移行する

Migrate from Xamarin.Forms
Xamarin.Forms の移行パス
https://github.com/jsuarezruiz/xamarin-forms-to-net-maui
https://devblogs.microsoft.com/xamarin/whats-new-in-xamarin-and-visual-studio-2022/#preparing-your-transition-to-net-6
その他 Xamarin.Forms から .NET MAUIへの移行情報
devblogs の移行情報
1. .NET Upgrade-Assistant を使用して、プロジェクトファイル（csproj）を SDK スタイルに変換する
2. .NET Upgrade-Assistant を使用して、すべての依存関係を .NET 6 と互換性のあるバージョンに更新
• Xamarin Community Toolkit の .NET 6 と互換性のあるバージョンの使用を検討
• https://devblogs.microsoft.com/xamarin/introducing-net-maui-compatibility-for-the-xamarin-community-toolkit/
• ※2022/11廃止が予定されている
3. (オプション)手順2で .NET Upgrade-Assistant で依存関係を更新しなかった場合は手動で実施
※Upgrade-Assistant はまだ正式に Xamarin プロジェクトに対応していないので注意！
（まだ書いてあるほどうまくは移行してくれない）

Xamarin ネイティブの移行パス
https://devblogs.microsoft.com/xamarin/whats-new-in-xamarin-and-visual-studio-2022/
1. .NET Upgrade-Assistant を使用して、プロジェクトファイル（csproj）を SDK スタイルに変換する
2. .NET Upgrade-Assistant を使用して、すべての依存関係を .NET 6 と互換性のあるバージョンに更新
• Xamarin Community Toolkit の .NET 6 と互換性のあるバージョンの使用を検討
• https://devblogs.microsoft.com/xamarin/introducing-net-maui-compatibility-for-the-xamarin-community-toolkit/
• ※2022/11廃止が予定されている
devblogs の移行情報
※Upgrade-Assistant はまだ正式に Xamarin プロジェクトに対応していないので注意！
Xamarin.Forms の移行手順１，２と同じ

Information about the Xamarin native migration
Xamarin ネイティブの移行の情報
https://github.com/dotnet/maui/wiki/Migrating-from-Xamarin.Forms-(Preview)
Only works with Xamarin.Forms .slns
(Xamarin.Android and Xamarin.iOS only solutions
coming later)
Xamarin ネイティブ向けの移行情
報が公開される予定

Migrate WCF
WCF を移行する

Migrate WCF to gRPC
WCF を gRPC へ移行
WCF 開発者向け ASP.NET Core gRPC
https://docs.microsoft.com/ja-jp/dotnet/architecture/grpc-for-wcf-developers
1. WCFプロジェクトにはServiceBehavior(.svc)、ServiceContact, OperationContactなどのWCF定義を担う
クラスだけを残し、ビジネス・データアクセスロジックは .NET 6 または .NET Standard 2.0 のクラス
ライブラリへ移植する
2. WCFプロジェクトを gRPCプロジェクトに作り直し、ビジネス・データアクセスロジックのクラスラ
イブラリを使用するようにする
3. WCFのクライアントプロジェクトを .NET Core 3.1 以上に Upgrade する
4. WCFのクライアントプロジェクトから、「接続サービスの管理」-「接続済みサービス」-「サービス
参照」-「サービス参照の追加」にて、gRPCを選択。gRPCプロジェクト内部に作成したprotoファイ
ルを選択
5. protoファイルより自動生成された接続クラスを使うように修正

Rebuilding the WCF into gRPC
WCF の gRPC 再構築
サンプル：PortfolioSample
https://docs.microsoft.com/ja-jp/dotnet/architecture/grpc-for-wcf-developers/migrate-request-reply
WCF
プロジェクト
TraderSys.Portfolios TraderSys.PortfolioData
プロジェクト
.NET Framework 4.7.2 .NET Framework 4.7.2
移行前
移行後
.NET 6
gRPC プロジェクト
.NET Standard2.0
ライブラリ
Test

Rebuilding the WCF into gRPC
WCF の gRPC 再構築
サンプルには Client プロジェクトがないので、テスト用にコンソールプロジェクトを作成
class Program
{
static void Main(string[] args)
{
var client = new PortfolioServiceClient();
var guid = Guid.NewGuid();
Console.WriteLine($"Call GetAll Method, Guid : {guid.ToString()}"); Console.WriteLine();
Portfolio[] portfolios = client.GetAll(guid);
foreach (var portfolio in portfolios)
{
Console.WriteLine($"Id : {portfolio.Id}, TraderId : {portfolio.TraderId.ToString()},ItemsCount : {portfolio.Items.Length}");
if (portfolio.Items.Length > 0)
{
foreach (var item in portfolio.Items)
{
Console.WriteLine($" Id : {item.Id}, ShardId : {item.ShareId}, Holding : {item.Holding}, Cost : {item.Cost}");
}
}
}
Console.ReadLine();
}
}
サービス参照の追加で自動生成した Proxy クラス

Result of console project for test
テスト用のコンソールプロジェクト実行結果

Migrate to .NET Standard 2.0
Data用クラスライブラリを.NET Standard 2.0 へ移行
そのままコピー
新しい.NET Standard 2.0
プロジェクト

Switch to use .NET Standard 2.0
.NET Standard 2.0版に切り替えて WCF 実行
エラーになる？？

It's for testing, so just run it.
テスト用なのでとりあえず動かす
コピー

Launch the console application for testing
テスト用のコンソールアプリを起動して確認

Create gRPC Project
gRPC プロジェクトを作成 (VS 2022)

Implement IF definition in proto file
proto ファイルに IF 定義を実装
syntax = "proto3";
option csharp_namespace = "TraderSys.Portfolios.Protos";
package PortfolioServer;
message GetRequest {
string trader_id = 1;
int32 portfolio_id = 2;
}
message GetResponse {
Portfolio portfolio = 1;
}
message GetAllRequest {
}
message GetAllResponse {
repeated Portfolio portfolios = 1;
}
service Portfolios {
rpc Get(GetRequest) returns (GetResponse);
rpc GetAll(GetAllRequest) returns (GetAllResponse);
}
message PortfolioItem {
int32 id = 1;
int32 share_id = 2;
int32 holding = 3;
int32 cost_cents = 4;
}
message Portfolio {
int32 id = 1;
repeated PortfolioItem items = 3;
}
DataContract/DataMemberに相当
ServiceContract/ OperationContractに相当
gRPC では引数と戻り値を1つにまとめる必要があるための定義

Reconstruct service class
サービスクラスを再実装
public override async Task<GetAllResponse> GetAll(GetAllRequest request, ServerCallContext context)
{
if (!Guid.TryParse(request.TraderId, out var traderId))
{
throw new RpcException(new Status(StatusCode.InvalidArgument, "traderId must be a UUID"));
}
var portfolios = await _repository.GetAllAsync(traderId);
var response = new GetAllResponse();
response.Portfolios.AddRange(portfolios.Select(Portfolio.FromRepositoryModel));
return response;
}
}
}
using Grpc.Core;
using TraderSys.PortfolioData;
using TraderSys.Portfolios.gRPC;
using TraderSys.Portfolios.Protos;
namespace TraderSys.Portfolios.gRPC.Services
{
public class PortfolioService : Protos.Portfolios.PortfoliosBase
{
private readonly ILogger<PortfolioService> _logger;
private readonly IPortfolioRepository _repository;
public PortfolioService(ILogger<PortfolioService> logger, IPortfolioRepository
repository)
{
_logger = logger;
_repository = repository;
}
public override async Task<GetResponse> Get(GetRequest request, ServerCallContext
context)
{
if (!Guid.TryParse(request.TraderId, out var traderId))
{
throw new RpcException(new Status(StatusCode.InvalidArgument, "traderId
must be a UUID"));
}
var portfolio = await _repository.GetAsync(traderId, request.PortfolioId);
return new GetResponse
{
Portfolio = Portfolio.FromRepositoryModel(portfolio)
};
}
リポジトリから取得したPOCOオブジェクトを
gRPC の扱う Protobuf のクラスに詰め替え直す
Standard2.0に移行したクラスライブラリをプロジェクト参照

Set up Dependency Injection
Dependency Injectionを設定
using TraderSys.PortfolioData;
using TraderSys.Portfolios.gRPC.Services;
var builder = WebApplication.CreateBuilder(args);
// Additional configuration is required to successfully run gRPC on macOS.
// For instructions on how to configure Kestrel and gRPC clients on macOS, visit
https://go.microsoft.com/fwlink/?linkid=2099682
builder.Services.AddScoped<IPortfolioRepository, PortfolioRepository>();
// Add services to the container.
builder.Services.AddGrpc();
var app = builder.Build();
// Configure the HTTP request pipeline.
app.MapGrpcService<PortfolioService>();
app.MapGet("/", () => "Communication with gRPC endpoints must be made through a gRPC client.
To learn how to create a client, visit: https://go.microsoft.com/fwlink/?linkid=2086909");
app.Run();

Migrate to SDK Style
テストクライアントを SDK 形式に変更
<PropertyGroup>
<RootNamespace>ClientForTest</RootNamespace>
<AssemblyName>ClientForTest</AssemblyName>
<TargetFrameworkVersion>v4.7.2</TargetFrameworkVersion>
</PropertyGroup>
<ItemGroup>
<WCFMetadata Include="Connected Services¥" />
</ItemGroup>
<ItemGroup>
<WCFMetadataStorage Include="Connected Services¥TraderSys.Portfolios¥" />
</ItemGroup>
<ItemGroup>
<None Update="Connected Services¥TraderSys.Portfolios¥PortfolioService.disco" />
</ItemGroup>
<ItemGroup>
<None Update="Connected Services¥TraderSys.Portfolios¥configuration91.svcinfo" />
</ItemGroup>
<ItemGroup>
<None Update="Connected Services¥TraderSys.Portfolios¥configuration.svcinfo" />
</ItemGroup>
<ItemGroup>
<None Update="Connected Services¥TraderSys.Portfolios¥Reference.svcmap">
<Generator>WCF Proxy Generator</Generator>
<LastGenOutput>Reference.cs</LastGenOutput>
</None>
</ItemGroup>
</Project>

Migrate to .NET 6
テストクライアントを .NET 6 に移行
<PropertyGroup>
<RootNamespace>ClientForTest</RootNamespace>
<AssemblyName>ClientForTest</AssemblyName>
</PropertyGroup>
<ItemGroup>
<WCFMetadata Include="Connected Services¥" />
</ItemGroup>
<ItemGroup>
<WCFMetadataStorage Include="Connected Services¥TraderSys.Portfolios¥" />
</ItemGroup>
<ItemGroup>
<None Update="Connected Services¥TraderSys.Portfolios¥PortfolioService.disco" />
</ItemGroup>
<ItemGroup>
<None Update="Connected Services¥TraderSys.Portfolios¥configuration91.svcinfo" />
</ItemGroup>
<ItemGroup>
<None Update="Connected Services¥TraderSys.Portfolios¥configuration.svcinfo" />
</ItemGroup>
<ItemGroup>
<None Update="Connected Services¥TraderSys.Portfolios¥Reference.svcmap">
<Generator>WCF Proxy Generator</Generator>
<LastGenOutput>Reference.cs</LastGenOutput>
</None>
</ItemGroup>
</Project>

Add gRPC service reference
gRPC のサービス参照を追加

Add gRPC service reference
gRPC のサービス参照を追加
gRPC プロジェクト
の .protoファイル

Fix the test client
テスト用クライアントを修正
static async Task Main(string[] args)
{
using (var channel = GrpcChannel.ForAddress("https://localhost:7090"))
{
var client = new Portfolios.PortfoliosClient(channel);
// var client = new PortfolioServiceClient();
var guid = Guid.NewGuid();
Console.WriteLine($"Call GetAll Method, Guid : {guid.ToString()}"); Console.WriteLine();
GetAllResponse allResponse = await client.GetAllAsync(new GetAllRequest() { TraderId = guid.ToString() });
foreach (var portfolio in allResponse.Portfolios)
{
Console.WriteLine($"Id : {portfolio.Id}, TraderId : {portfolio.TraderId.ToString()},ItemsCount : {portfolio.Items.Count}");
if (portfolio.Items.Count > 0)
{
foreach (var item in portfolio.Items)
{
Console.WriteLine($" Id : {item.Id}, ShardId : {item.ShareId}, Holding : {item.Holding}, Cost : {item.CostCents}");
}
}
}
};
Console.ReadLine();
}
引数をProtobuf のクラスに詰め、戻り値も
Protobuf のクラスを受け取る

. NET Framework technologies that are no longer available
使用不可になった .NET
Framework テクノロジ
（MS 公式なものではなく、個人的な解説）

使用できなくなった .NET Framework テクノロジ
1. アプリケーションドメイン (AppDomain)の廃止
• １つのプロセス内部で複数のアプリケーション境界を保持する仕組み。プロセス切り替えまたはプ
ロセス間通信に比べてパフォーマンスが向上、またエラーが発生した特定のAppDomain は他の
AppDomain に影響を与えないため、アプリケーション全体へのエラーの影響を最小限にできる
（MicroServicesにちょっと似ている）、などメリットは多かったがリソースの消費が激しかった
• 対応方針：
• 移行のために API を全て削除するのではなく、エラーを投げるもの、obsolute 属性＋処理しな
いもの、正常に稼働するもの（ExecuteAssembly, Exceptionなど）が用意されている
• どのAPIがどの挙動になるのかは公開されているソースを確認する必要がある
• https://github.com/dotnet/runtime/blob/release/6.0/src/libraries/System.Private.CoreLib/src/Sys
tem/AppDomain.cs
• 別の AppDomain を追加作成して使用している場合、別プロセス or コンテナを検討
個人的な解説であることに注意

2. リモート処理の廃止
• プロセス間通信、アプリケーションドメイン間（ネットワーク越し含む）の通信に使用されてい
たものだが、.NET Framework の頃から Web API や WCF への移行が推奨されていたレガシーな技
術。旧バージョンとの互換性のためだけにサポートされていた
• 対応方針：破壊的変更:リモート API は旧型式 - .NET | Microsoft Docs
3. コードアクセスセキュリティ (CAS)の廃止
• インターネット、イントラネット、ネットワーク共有などからコンポーネントをダウンロードし
て実行するシナリオにおいて、アクセス許可を与えるためのセキュリティモデルだったが、扱い
が難しく、特権昇格が発生する場合が多かったためセキュリティ境界としては無意味だった
• .NET Framework 4.0 以降では既に廃止されていた
• 対応方針：破壊的変更: ほとんどのコードアクセスセキュリティ API は旧型式 - .NET | Microsoft
Docs

4. セキュリティ透過性の廃止
• CASが廃止された後に採用された。基本クラスライブラリ (BCL)やMS提供のフレームワークの
メソッドに下記３つの属性が付いた。これにより、危険なコードを含むアプリケーション（ア
センブリ）を部分信頼として実行するとセキュリティ例外が発生するようになった。これは既
にSilverlight で使用されていた仕組みを採用したもの。だが完全信頼として読み込み、稼働させ
る場合が多かったためにセキュリティ境界としては無意味だった
① SecurityTransparent 属性（安全なコード）
② SecuritySafeCritical 属性（安全に扱えるように無害化された危険なコード）
③ SecurityCritical 属性（危険なコード）
5. System.EnterpriseServices 名前空間が廃止
• .NET オブジェクトに COM+ サービスへのアクセスを提供するクラス群はすべて廃止
• 対応方針：COMラッパーにて対応可能になっている
• https://docs.microsoft.com/ja-jp/dotnet/standard/native-interop/com-wrappers

6. リフレクションによって生成されたアセンブリの保存できなくなった
• System.Reflection.Emit API によって生成されたアセンブリの保存はサポートされない
• AssemblyBuilder.Save メソッドも使用できない
• 対応方針：.NET 以降で使用可能なメタプログラミングはいくつかある。再実装が必要
• CodeDOM
• Reflection
• Expression Tree
• SourceGenerator
• etc
7. マルチモジュールアセンブリの読み込みの廃止
• 基本的には１つのアセンブリには１つのモジュールしか含まないが、１つのアセンブリに複数
のモジュールを含めることも可能だった。この複数モジュールを含めたアセンブリが廃止と
なった（マニフェストを含むものがアセンブリ、含まないものがモジュール）
• 対応方針：モジュールをアセンブリに含めるようにソースレベルで修正が必要

使用されている API のうち指定したターゲットには存在しない API を表示するツール
.NET Portability Analyzer (別名 ApiPort)
• https://docs.microsoft.com/ja-jp/dotnet/standard/analyzers/portability-analyzer
• https://github.com/microsoft/dotnet-apiport
• アセンブリを指定して解析＝バイナリレベルで確認
• 出力形式は Excel, HTML, JSON などから複数選択可能
• ツールには Exe 版と Visual Studio Extension 版がある（VS版は 2017/2019 のみ – 2022/1現在）
• Exe 版
• https://aka.ms/apiportdownload
• Visual Studio Extension 版
• https://www.vsixgallery.com/extension/55d15546-28ca-40dc-af23-dfa503e9c5fe

ApiPort.exe analyze -t “.NET Standard, Version=2.0” -r HTML –r Excel -f "E:¥CSWinFormSplashScreen-.net35"
ApiPort.exe analyze -t ".NET, Version=5.0" -t ".NET + Platform Extensions" -r HTML -f "E:¥CSWinFormSplashScreen"
ApiPort.exe analyze -t “ターゲット, Version=X.X” -r 出力形式 -f “フォルダ or アセンブリのPath"
⚫ -t, -r, -f 各オプションは複数指定可能
ex: ApiPort.exe -t “targetA” -t “targetB” –f ”assemblyA” -f “assemblyB”
コマンド実行サンプル
コマンド実行サンプル
⚫ ターゲットは “Name, Version=X.X” 形式で指定するが、Version指定はオプション
ex: -t “.NET, Version=5.0” -t “.NET + Platform Extensions”
Exe版の使用方法

2022/1現在
対応ターゲットの一覧
対応出力形式の一覧
Name: .NET
Versions: 5.0
Name: .NET + Platform Extensions
Versions: 5.0
Name: .NET Core
Versions: 1.0; 1.1; 2.0; 2.1; 2.2; 3.0; 3.1*
Name: .NET Core + Platform
Extensions
Versions: 2.0; 2.1; 2.2; 3.0; 3.1*
Name: .NET Framework
Versions: 1.0; 1.1; 2.0; 3.0; 3.5; 4.0; 4.5;
4.5.1; 4.5.2; 4.6; 4.6.1; 4.6.2; 4.7; 4.7.1;
4.7.2; 4.8
Name: .NET Standard
Versions: 1.0; 1.1; 1.2; 1.3; 1.4; 1.5; 1.6;
2.0; 2.1
Name: .NET Standard + Platform
Extensions
Versions: 1.6; 2.0*
Name: ASP.NET Core
Versions: 1.0; 1.1; 2.0
Name: Mono
Versions: 2.0; 3.5; 4.0; 4.5; 5.0
Name: Silverlight
Versions: 2.0; 3.0; 4.0; 5.0
Name: UWP
Versions: 8.0; 8.1; 10.0; 10.1
Name: Windows Phone
Versions: 8.1
Name: Windows Phone Silverlight
Versions: 7.0; 7.1; 8.0; 8.1
Name: Xamarin Android
Versions: 1.0.0
Name: Xamarin iOS
Versions: 1.0.0.0
- Excel
- HTML
- Json
- DGML

.NET Upgrade Assistant Analyze command
Analyze Command
.NET Upgrade Assistant の Analyze コマンドについて

Two commands in .NET Upgrade Assistant
２つのコマンド
実は .NET Upgrade Assistant には２つのコマンドがある
> upgade-assistant analyze
• 依存関係の解析
• Upgrade
> upgade-assistant upgrade

依存関係を解析する
• 選択した TFM（現行、LTS、プレビュー）にプロジェクトをアップグレードするために、削除/追加/アップグレード
が必要なパッケージの依存関係、プロジェクト参照、フレームワーク参照
Analyze command
Analyze コマンド
• 得られる結果
In order analyze package dependencies for a project or a solution use the analyze command with
the tool like so :
upgrade-assistant analyze <Path to csproj or sln to analyze>
今のところは依存関係の解析だけ
https://github.com/dotnet/upgrade-assistant#analyze-path

Analyze command
.NET Upgrade Assistant analyze
解析結果は .sarif という json フォーマットのファイル。Visual Studio 2017 / 2019 にはこれを読
むための拡張機能がある（Visual Studio Code にもある）
{
"ruleId": "UA103",
"message": {
"text": "Reference to System.Web needs to be deleted."
},
"locations": [
{
・・・
}
]
},
{
"ruleId": "UA106",
"message": {
"text": "Package System.Configuration.ConfigurationManager,
Version=5.0.0 needs to be added."
},
"locations": [
{
・・・
}
]
},
・・・（続く）
.sarif ファイル Visual Studio 2019 で .sarif を開く

Analyze command
（個人的な予想）
{
"tool": {
"driver": {
"name": "API Upgradability",
"semanticVersion": "0.3.261602",
"informationUri": "https://docs.microsoft.com/en-
us/dotnet/core/porting/upgrade-assistant-overview"
}
},
"results": [],
"columnKind": "utf16CodeUnits"
},
{
"tool": {
"driver": {
"name": "Component Analysis",
"semanticVersion": "0.3.261602",
"informationUri": "https://docs.microsoft.com/en-
us/dotnet/core/porting/upgrade-assistant-overview"
}
},
"results": [],
"columnKind": "utf16CodeUnits"
}
解析結果の .sarif ファイル内部にはこんな箇所がある
今後、API の互換性を解析した結果や使用し
ているコンポーネントの .NET での存在有無
などを解析してくれる？
（.NET Portability Analyzer を取り込む？）

【BS4】時は来たれり。今こそ .NET 6 へ移行する時。

More Related Content

What's hot

Similar to 【BS4】時は来たれり。今こそ .NET 6 へ移行する時。

More from 日本マイクロソフト株式会社

Recently uploaded

【BS4】時は来たれり。今こそ .NET 6 へ移行する時。