.NET MAUI Preview 14 更新情報

.NET MAUI Preview 14 の更新情報についてご紹介します。

なお、オリジナルの記事はこちらです。
devblogs.microsoft.com
　
.NET MAUI Preview 13 の更新情報はこちらです。
hiro128.hatenablog.jp
　
.NET MAUI の Xamarn.Forms からの改良ポイントはこちらです。
hiro128.hatenablog.jp　
　

目次

Microsoft.Maui.Essentials（.NET MAUI Preview 14）

Microsoft.Maui.Essentials は Xamarin.Essentials の後継のクロスプラットフォーム API です。
以下の機能のネイティブ API のラッパーでであり、共有コードから簡単に利用できます。
（当該の機能のネイティブ実装がない場合は当然利用できません）

• 加速度計 – 3 次元空間内のデバイスの加速度データを取得します。
• アプリ アクション – アプリケーションのショートカットを取得して設定します。
• アプリ情報 – アプリケーションに関する情報を見つけます。
• アプリのテーマ –アプリケーションに対して要求されている現在のテーマを検出します。
• バロメーター – 負荷の変化のバロメーターを監視します。
• バッテリ – バッテリ レベル、ソース、および状態を簡単に検出します。
• クリップボード – クリップボード上のテキストをすばやく簡単に設定したり読み取ったりします。
• 色の変換機能 – System.Drawing.Color のヘルパー メソッド。
• コンパス – コンパスの変化を監視します。
• 接続 – 接続状態を確認し、変更を検出します。
• 連絡先 –デバイス上の連絡先に関する情報を取得します。
• シェイクの検出 – デバイスを振る動きを検出します。
• デバイス ディスプレイ情報 – デバイスの画面のメトリックと向きを取得します。
• デバイス情報 – デバイスの詳細を簡単に確認します。
• 電子メール – 電子メール メッセージを簡単に送信します。
• ファイル ピッカー - ユーザーがデバイスからファイルを選択できるようにします。
• ファイル システム ヘルパー – アプリ データにファイルを簡単に保存します。
• 懐中電灯 – 懐中電灯のオン/オフを簡単に切り替える方法です。
• ジオコーディング – ジオコードとリバース ジオコードのアドレスおよび座標。
• 位置情報 – デバイスの GPS 位置情報を取得します。
• ジャイロスコープ – デバイスの 3 つの主軸の周りの回転を追跡します。
• 触覚フィードバック – クリックと長押しの Haptic を制御します。
• ランチャー – アプリケーションがシステムで URI を開くことができるようにします。
• 磁力計 – 地球の磁場を基準としたデバイスの向きを検出します。
• メイン スレッド – アプリケーションのメイン スレッドでコードを実行します。
• マップ – 特定の場所にマップ アプリケーションを開きます。
• メディア ピッカー – ユーザーが写真やビデオを選択したり、撮影したりできるようにします。
• ブラウザーを開く – ブラウザーで特定の Web サイトをすばやく簡単に開きます。
• 向きセンサー – 3 次元空間内のデバイスの向きを取得します。
• アクセス許可 – ユーザーからのアクセス許可を確認して要求します。
• 電話ダイヤラー – 電話ダイヤラーを開きます。
• プラットフォーム拡張 – Rect、Size、Point を変換するためのヘルパー メソッド。
• ユーザー設定 – 永続的なユーザー設定をすばやく簡単に追加します。
• スクリーンショット – アプリケーションの現在の表示をキャプチャします。
• セキュリティで保護されたストレージ – データを安全に格納します。
• 共有 – 他のアプリにテキストや Web サイトのリンクを送信します。
• SMS – 送信用の SMS メッセージを作成します。
• テキスト読み上げ – デバイス上のテキストを音声化します。
• 単位変換機能 – 単位を変換するためのヘルパー メソッド。
• バージョンの追跡 – アプリケーションのバージョンとビルド番号を追跡します。
• バイブレーション – デバイスをバイブレーションさせます。
• Web Authenticator - Web 認証フローを開始し、コールバックをリッスンします。

公式情報：Announcing .NET MAUI Preview 14 - .NET Blog
　
　

シェル WinUI の実装を移行（.NET MAUI Preview 14）

シェルWinUIの実装を移行し、シェル以外のアプリと同じコンポーネントの約90%を再利用するようにしました。
公式情報：Shell WinUI Handler by PureWeen · Pull Request #4501 · dotnet/maui · GitHub

シェルはほとんどのアプリケーションで必要となる基本的な UI 機能を提供する Page です。
シェルについての詳細は以下を参照ください。
docs.microsoft.com
　
　

iOS の画像キャッシュ機能の実装（.NET MAUI Preview 14）

公式情報：Implement image caching functionality for iOS by rachelkang · Pull Request #4515 · dotnet/maui · GitHub
　
　

すべてのパブリックAPIの名前を「Native」から「Platform」に変更（.NET MAUI Preview 14）

例）

• NativeView --> PlatformView
• NativeImage --> PlatformImage
• NativeArrange --> PlatformArrange

公式情報：Renaming public APIs Native --> Platform by rachelkang · Pull Request #4599 · dotnet/maui · GitHub
　
　

Shape 固有のハンドラー実装 （.NET MAUI Preview 14）

以下の Shape に対する固有のハンドラーを実装しました。

• Line
• Rectangle
• RoundRectangle
• Path
• Polyline
• Polygon

公式情報：Shapes Handlers by jsuarezruiz · Pull Request #4472 · dotnet/maui · GitHub
　
Xamarin.Forms のレンダラーアーキテクチャは、.NET MAUI ではハンドラーアーキテクチャーに進化しました。
ハンドラーについての詳細は以下を参照ください。
docs.microsoft.com
　
　

文字列を使用して XAML でStrokeShapeを定義できるようにする （.NET MAUI Preview 14）

TypeConverter を追加して、StrokeShape を以下ように設定できるようにしました。

StrokeShape="Rectangle"
StrokeShape="Ellipse"
StrokeShape="Polygon 0 48, 0 144, 96 150, 100 0, 192 0, 192 96, 50 96, 48 192, 150 200 144 48"
StrokeShake="RoundRectangle 20, 0, 20, 0"

公式情報：Allow to use string to define StrokeShape in XAML by jsuarezruiz · Pull Request #3256 · dotnet/maui · GitHub
　
　

WebView に Cookieプロパティを実装 （.NET MAUI Preview 14）

公式情報：Implement Cookies property in WebView by jsuarezruiz · Pull Request #4419 · dotnet/maui · GitHub
　
　

デスクトップアプリケーション用の MenuBar を実装 （.NET MAUI Preview 14）

公式情報：Menubar by PureWeen · Pull Request #4839 · dotnet/maui · GitHub
　
　

Window RTL(Right-to-left writing) 対応 （.NET MAUI Preview 14）

FlowDirection を IWindow に追加し、ユーザーが Window のフロー方向を指定できるようにします。
デスクトップアプリで、閉じる、開く、最小化ボタンをRTLにしたい場合に有効です。

公式情報：Windows FlowDirection by PureWeen · Pull Request #4936 · dotnet/maui · GitHub
　
　

.NET Framework から .NET 6 への移行時に便利なツール、.NET アップグレード アシスタント（利用方法）

目次

　
.NET アップグレード アシスタントの概要については以下を参照ください。
hiro128.hatenablog.jp
　
　

使い方

.NET アップグレード アシスタントは .NET CLI ツールです。PowerShell のようなコマンド シェル上で利用します。
インストール、アンインストールの方法は以下の通りです。
　

インストール

dotnet tool install -g upgrade-assistant

アンインストール

dotnet tool uninstall -g upgrade-assistant

　
-g パラメーターを指定すると、PATH 環境変数に自動的に追加される既定の場所（%USERPROFILE%\.dotnet\tools）にツールがインストールされます。

インストール手順に関する Microsoft Docs は、以下を参照下さい。
docs.microsoft.com
　

ツールのアップデート

ツールをしばらく使用してなかった場合は、アップデートをしておきます。

dotnet tool update -g upgrade-assistant

アプリケーションのアップグレードの方法

アップグレードを行うには、PowerShell のようなコマンド シェルを開き、アップグレードを行いたいソリューションやプロジェクトが配置されているフォルダーに移動します。

アップグレードを行いたいソリューションやプロジェクトを指定して、 以下のコマンドを実行します。

upgrade-assistant upgrade .\WinFormsAppNetFramework.sln

　
以下のような感じで、これからアップグレードで行う処理の一覧と現在のステップで行う処理に対する選択肢が表示されます。
それぞれのステップで希望する選択肢を選んでいくとアップグレードが完了します。

それぞれのステップの処理の内容は以下の通りです。

1. Back up project	プロジェクトをバックアップします
2. Convert project file to SDK style	csprojファイルを .NET Framework の非SDKスタイルから .NET の SDKスタイルへ変換します
3. Clean up NuGet package references	パッケージ参照を分析し、packages.config ファイルから不要な参照を削除します
4. Update TFM	TFM（ターゲット フレームワーク モニカー）を適切なものに更新します
5. Update NuGet Packages	プロジェクトのNuGetパッケージを、必要に応じてステップ4で変更されたTFMをサポートするバージョンに更新します
6. Add template files	テンプレートファイルがある場合に自動で追加します
7. Update Winforms Project	Windowsフォーム固有の処理を行います
a. Default Font API Alert	デフォルトフォントが変更されたため対処が必要であることをこのツールを使っているユーザーに認識してもらうためにツールの画面表示で通知します。（アプリケーションのソースコードは変更されません。）
b. Winforms Source Updater	Program.cs に、高DPIモードを設定するSetHighDpiModeメソッドの呼び出しを追加します
8. Upgrade app config files	app.config ファイルの内容を更新します
a. Convert Application Settings	appsettings.jsonファイルに移行する必要がある設定が存在すれば移行します
b. Convert Connection Strings	appsettings.jsonファイルに移行する必要がある接続文字列が存在すれば移行します
c. Disable unsupported configuration sections	.NET 6 でサポートされない設定が存在すれば無効化します
9. Update source code	ソースコードを更新します
a. Apply fix for UA0002: Types should be upgraded	（本ツールで認識できる）更新が必要な型が存在すれば更新します
b. Apply fix for UA0012: 'UnsafeDeserialize()' does not exist	.NET でサポートされていない UnsafeDeserialize()が存在すれば更新します
10. Move to next project	ソリューション内の次のプロジェクトに移動します

　
上記の通り、かなりの定型的作業を自動化してくれます。
　
アップグレードの手順に関する Microsoft Docs は以下を参照ください
docs.microsoft.com
　
　

変換後のソリューションを Visual Studio 2022 で開く

変換後のソリューションを Visual Studio 2022 で開くと以下の画像ように、問題がある箇所に警告が出ます。また、自動で変換できなかった箇所に問題があればビルドするとエラーになります。

　
この

• 警告が出ている箇所
• ビルドエラーが出る箇所

が手作業で修正が必要な部分となりますので、集計することで必要な手作業のおおよその作業量がわかります。
また、実際の移行を行うときはこれらの箇所を修正します。
　
　

NET Framework から .NET 6 への「移行計画（手間・コストの見積り）」の作成に便利なツール

目次

はじめに

　
.NET6は.NET Framework が .NET に統合されて初めてのLTSリリースとなります。第一回でも述べた通り今後も.NET Frameworkのサポートは続きますが、あくまでも「既存環境の維持」のためのサポートであり、今後積極的な機能追加がされることはありません。

また、セキュリティパッチも継続的に提供されますが、.NETランタイムのセキュリティ脆弱性の緩和策ロードマップにあるHardware-enforced Stack Protection（ハードウェア強制型スタック保護）やW^X（write xor execute：書き込みと実行の排他）のように.NETランタイムの構造に手を入れるような対策は.NET 6以降にのみ実装されます。基本的に.NET Frameworkでは提供されません。

このような状況から考えて今は.NET 6への移行を進めるには絶好のタイミングであり、実際に.NET Frameworkアプリの.NET6への移行を検討されている方も多いことでしょう。

　
参考：.NET 6 の新機能の情報は以下をご覧ください。
hiro128.hatenablog.jp
　
　

移行における最大の障壁

　
.NETに限らず、アプリを最新の環境に移行する場合の最大の障壁は「移行に要する予算の確保」です。新規アプリ開発には予算が付きやすいものですが、既存アプリの移行に対して高額な予算の承認を得るのは困難です。

SIer、自社開発などにかかわらず移行を実行するには、移行に関する (1)作業内容 (2)リスク (3)実施計画 (4)コストをまとめた「移行計画」をステークホルダーにわかりやすく説明し、理解と承認を得ることが必要です。

しかし、移行先の環境の知見が少ない段階で、これら(1)～(4)を網羅した精度の高い移行計画を作成するのは非常に困難であり、すなわちステークホルダーの理解を得るのも困難となる問題に悩まされます。
　
　

ツールを使用して移行に必要な作業量を見積る

　
.NET Framework から .NET への移行についてはすべてを手作業で行う必要はなく、一部作業を自動化できるツールも存在します。つまり、移行時に大きな負担になるのは「ツールで移行できず必ず手作業が必要になる移行作業」です。

よってこの「必ず手作業が必要になる移行作業」がどのくらいの作業量があるかがわかれば、コストも見積もることができ精度の高い移行計画を立案できます。

この問題を解決するのに適したツールが、.NET Portability Analyzer と .NET アップグレード アシスタントです。本来この2つのツールは実際の移行時に使うツールなのですが、使い方の視点を変えることによって、移行計画の作成に効果的に利用できます。

.NET Portability Analyzerは、移行先の環境（今回であれば.NET 6）で使用できない（ビルドが通らず代替が必要な） API を特定するツールです。

.NET Portability Analyzer の詳細については以下を参照ください。
docs.microsoft.com
　
.NET Portability Analyzer - Visual Studio 拡張機能は以下よりダウンロードできます。
marketplace.visualstudio.com

注意：
2022/03/01 現在、.NET Portability Analyzerは移行先のプラットフォームとして .NET 5 までしか対応していません。
（なお、.NET Framework からの移行という観点では 移行先を .NET 5 に設定して利用しても実害はほとんどありません。）

.NET アップグレード アシスタントは、csprojファイルの書式変更や syntax・名前空間の問題でビルドが通らないコードを、移行先の環境（今回であれば.NET 6）の新しい構文に変換するツールです。

.NET アップグレード アシスタントの詳細については以下を参照ください。
docs.microsoft.com

.NET アップグレード アシスタントのインストール方法については以下を参照ください。
docs.microsoft.com

一般的な移行で行う作業と、そのうち.NET Portability Analyzer と .NET アップグレード アシスタントが自動で行ってくれる作業との関係は以下の通りです。

1. ソリューション内で.NET6対応に書換える必要がある箇所をリストアップ
   1. *.csファイルのアプリコードにおいて移行先でAPIが非サポートのため書き換えが必要な箇所のリストアップ→.NET Portability Analyzer で自動化可能
   2. *.csprojファイルの書式や構文が変更されたため書き換えが必要な箇所のリストアップ→（2.の工程で.NET アップグレード アシスタントで自動変換できるのでリストアップする必要がない）
2. *.csprojの書き換え、*.csファイルのアプリケーションコードの書き換え
   1. 自動で書き換え可能な箇所　→.NET アップグレード アシスタントで自動化可能
   2. 手動でのみ書き換え可能な箇所
3. 全機能のテスト

　
　
上記の手順とツールによるサポートを考慮すると、「必ず手作業が必要になる移行作業」の作業量を見積もるには、実際にツールで試験的に移行作業を行い、
1.1.　*.csファイルのアプリコードにおいて移行先でAPIが非サポートのため書き換えが必要な箇所
2.1. 　手動でのみ書き換え可能な箇所
について具体的にどのような作業を行う必要があるか精査すればよいことになります。

もちろん、これですべての移行作業が見積もれるわけではありませんが、ツールを利用する前のどこから手を付ければよいかわからない状態に比べて、このようにツールを利用することによって、移行作業を見積もる負荷は大きく下げることができます。
　
　

ツールの利用方法

.NET Frameworkアプリの.NET6への移行で特に負担が大きいのは、歴史が古く開発時の情報が残っていない塩漬けの資産が多い Windows フォーム と ASP.NET Web フォームです。このうち、ASP.NET Web フォームは残念ながら、.NET 6 ではサポートされておらず移行できませんが、実はWindows フォームはかなり手厚くサポートされており.NET6へ移行して充分に利用可能です。

.NET Portability Analyzer と .NET アップグレード アシスタントの利用方法はそれぞれ以下の記事を参照ください。
　

.NET Portability Analyzer

hiro128.hatenablog.jp

.NET アップグレード アシスタント

hiro128.hatenablog.jp
　
　

ツールの結果から「必ず手作業が必要になる移行作業」を見積もる

これまで述べた通り、

• .NET Portability Analyzer でリストアップされた箇所
• .NET アップグレード アシスタントで変換後に警告やビルドエラー発生した箇所

は、手作業で修正が必要な箇所となりますが、もう一つ、

• 全機能のテストでグリーンにならなかった箇所

も手作業で変更が必要な箇所となります。

よって、この3つの作業量の合計が「必ず手作業が必要になる移行作業」となります。
　
なお、全機能のテストは非常に重い作業ですので、自動テストが導入されていない場合、テストにかかるコストを見積もることはできても、そのコストが大きすぎて問題になる事が予想されます。ですが、テストにかかる手間を劇的に削減する方法はありませんので、以下でご説明しますように地道に対応していくことが必要です。
　
　

自動テストについて

古い Windows フォームアプリの場合、自動テストが導入されていない場合が多く全機能のテストは非常に負担が大きい作業です。理想的なのはUIとロジックを分離し自動テストを導入することですが、これには大きな手間とコストが必要になり現実的にはなかなか導入できない場合もあります。

ですが、今後の .NET のサポートポリシーでは.NET 6 のような LTS バージョンでもサポートは3年間（2024年11月8日まで）です。次の LTS は .NET 8 の予定で2023年秋のリリース予定となっています。よって、.NET 8 のリリースから.NET 6 のサポート切れまで約1年しかありません。

この1年以内で全機能のテストを行い移行を完了させなければいけないという状況から考えると、段階的にでも自動テストできる環境を整えないと今後の継続的なアプリケーションのメンテナンスは不可能になってしまいます。

全機能においてUIとロジックを分離し自動テストを導入するのが厳しい場合、まずは手動テストのシナリオをそのまま使い、UIを自動操作することで自動テストを行うことが有効です。後ほどUIとロジックを分離したとしても、UIから行う総合テストとロジック部分をテストする単体・結合テストは別に行うべきものですので、無駄になることもありません。段階的に一部機能だけでもUIとロジックの分離を進め、残りはUIからのテストを行うなどの方法も考えられます。

Microsoft のツールではないですが、UIを自動操作する（正確には内部 API 呼び出し）ことで自動テストをする際に有効なツールとして、Friendly があります。
Friendly についての詳細は以下を参照下さい。
github.com

このツールを使うことで、Windowsアプリケーション(Windowsフォーム, WPF, Win32)を簡単にC#のコードで操作でき、導入も非常に簡単ですので、全く自動テストが導入されていないアプリケーションに最初に自動テスト導入する際にもとても有効なツールです。
　
　

.NET Framework から .NET 6 への移行時に便利なツール、.NET アップグレード アシスタント

目次

　
.NET Framework から .NET 6 への移行を行うときに便利なツールの一つに .NET アップグレード アシスタントがあります。
このツールを使うと、.NET Framework のソリューションを .NET 6 に変換してくれます。
　
公式ドキュメントは以下です。
docs.microsoft.com
　
　

なにができるの

主に、以下のような自動変換と、自動で変換できなかった（手作業が必要な）箇所への支援を提供してくれます。
　

自動変換

• .NET Framework の csproj ファイル（非SDK形式）を .NET 6（SDK形式） に変換します。
• .NET Framework から .NET 6 への移行で必ず必要になる定型的なコード変換を実施してくれます。

Windows アプリで .NET Framework のコードが引き続き動作するようにする支援

• Windows 互換機能パックMicrosoft.Windows.Compatibilityパッケージが追加されることで多数のAPIセットが追加され、引き続き Windows 上でアプリを動作させる場合、既存のコードの大部分がそのまま利用できるようになります。

手作業が必要な箇所への支援

• アナライザー Microsoft.DotNet.UpgradeAssistant.Extensions.Default.Analyzersパッケージが追加され、移行で問題が検出されたソースコードに警告が表示されるようになり、その後の手作業を支援してくれます。

　
支援内容の詳細は以下をご覧ください。
github.com
　
補足 1
Windows 互換機能パックは、.NET Framework のみに存在する API およびテクノロジを .NET でも利用できるようにするパッケージです。これは簡単に言えば .NET Framework の Windows 依存の API を .NET により再実装したものです。
これにより、.NET Framework のコードを .NET に移行しWindows 上で動作させる場合、既存のコードがほとんどそのままで動作します。
docs.microsoft.com
　
　

どこが便利なの

ツールで実施できる移行作業を簡単に試すことができるため、ツールでカバーできる移行がどこまでであるか、また、ツールでの変換後に必要な手作業のボリュームがどのくらいあるかを容易に確認できます。
変換の所要時間は数分から数十分程度なので、簡単に変換後に必要となる作業の量の見当をつけることができます。
　
.NET Portability Analyzer とセットで利用すると、移行計画を作成するときにとても便利です。
.NET Portability Analyzer については以下の記事を参照下さい。
hiro128.hatenablog.jp
　
　

使い方

使い方については、以下の記事を参照下さい。
hiro128.hatenablog.jp
　
　
.NET Framework から .NET 6 への移行計画については以下を参照ください。
hiro128.hatenablog.jp
　
NET Portability Analyzer については以下を参照ください。
hiro128.hatenablog.jp

.NET Framework から .NET 6 への移行時に便利なツール、.NET Portability Analyzer

目次

　
.NET Framework から .NET 6 への移行を行うときに便利なツールの一つに .NET Portability Analyzer があります。
このツールは、以下の2つの種類があって、使い方が少し違います。

• Visual Studio のエクステンション
  • Visual Studio 上から GUI で、プロジェクトごとに分析できる。

• コンソールアプリ（クリックするとダウンロードされます）
  • path を指定してファイルやディレクトリごとに分析できる

　
　
公式ドキュメントは以下です。
docs.microsoft.com
　
　　

なにができるの

移行先のプラットフォーム（今回なら .NET 6） で使用できない（ビルドが通らず代替が必要な） API を特定できます。
　
　

どこが便利なの

サポートされていなく手動で代替が必要な箇所を探す時に、ドキュメントを読んでサポートされていない API を手動でリストアップして、ソースコードを自分で解析するというような作業が不要で、メニューからツールを実行するだけで遅くとも数分程度でレポートを作成してくれるので、簡単に移行を実施した時に発生すると想定される作業量の見当をつけることができます。
　
このツールは移行計画を作成するときにとても便利です。
　
　

注意点

2022/02/08 現在、移行先のプラットフォームとして .NET 5 までしか対応していません。
（.NET Framework からの移行という観点では 移行先を .NET 5 に設定して利用しても実害はほとんどありません。）
　
　

使い方

Visual Studio の [ツール] -> [オプション] で設定画面が表示されるので、移行先のプラットフォームを（.NET 6 がまだないので、.NET 5）をチェックします。

　
　
プロジェクトの右クリックメニューから、[Analyze Project Portability] を実行します。

　
　
分析が始まります。

　
　
レポートが作成されるので開いてみましょう。

　
　
移植性のサマリーの値が 「98.45％」になっているので、移植できない API が含まれていることがわかります。

　
　
サポートされていない API が何かを確認するには、「Details」のシートを確認するとわかります。
DataGridとそのメンバーが Not supported になっています。

よって、このアプリではDataGridを .NET６で利用できる API に変更しなければいけないことがわかります。
このような手順で、サポートされていない API をリストアップすることができます。

リストアップできたら、そのAPIについて調査します。
例えばDataGridについて docs.microsoft.com でリファレンスを確認すると「代わりに DataGridViewコントロールを使用してください。」と記載されておりますので、DataGridをDataGridViewに置き換えればよいことになります。
　
　

今回のサンプルコード

.NET Portability Analyzer を利用すると、このような感じでサポートされていない API を簡単にリストアップできます。
なお、今回ツールを実行したプロジェクトのサンプルコードは以下にありますので、試してみたい方は参照してみてください。
github.com
　
　
.NET Framework から .NET 6 への移行計画については以下を参照ください。
hiro128.hatenablog.jp
　
.NET アップグレード アシスタントについては以下を参照ください。
hiro128.hatenablog.jp