個人的なメモ

Tomohiro Suzuki @hiro128_777 のブログです。Xamarin に関する事を中心に書いています。 Microsoft MVP for Development Technologies 2017- 本ブログと所属組織の公式見解は関係ございません。

.NET MAUI Update の整理(随時更新中)

.NET MAUI の Preview 14 がリリースされました。Preview 1 から Preview 14 まで段階的に情報や新機能がリリースされており、情報が分散して探しにくいので重要な更新情報を整理してみました。
  
公式情報も更新されているため、内容は随時更新中です。
 
.NET 6 の新機能の情報は以下をご覧ください。
hiro128.hatenablog.jp
 
 

.NET MAUI、 Xamarn.Forms からの改良ポイント

.NET MAUI、 Xamarn.Forms からの改良ポイントの記事はこちらです。
hiro128.hatenablog.jp
 

.NET MAUI Preview 14 の更新情報

.NET MAUI Preview 14 の更新情報はこちらです。
hiro128.hatenablog.jp
 

.NET MAUI Preview 13 の更新情報

.NET MAUI Preview 13 の更新情報はこちらです。
hiro128.hatenablog.jp
 

.NET MAUI Preview 12 の更新情報

.NET MAUI Preview 12 の更新情報はこちらです。
hiro128.hatenablog.jp
 

.NET MAUI Preview 11 の更新情報

.NET MAUI Preview 11 の更新情報はこちらです。
hiro128.hatenablog.jp
 

.NET MAUI Preview 10 の更新情報

.NET MAUI Preview 10 の更新情報はこちらです。
hiro128.hatenablog.jp
 

.NET MAUI Preview 9 の更新情報

.NET MAUI Preview 9 の更新情報はこちらです。
hiro128.hatenablog.jp
 

.NET MAUI Preview 8 の更新情報

.NET MAUI Preview 8 の更新情報はこちらです。
hiro128.hatenablog.jp 
 

.NET MAUI Preview 7 の更新情報

.NET MAUI Preview 7 の更新情報はこちらです。
hiro128.hatenablog.jp

 
以下、随時更新中です。
 
 

.NET MAUI、 Xamarn.Forms からの改良ポイント

.NET MAUI リリース

2022年5月23日(現地時間)ついに .NET MAUI が GAされました。Microsoft は「.NET MAUI は、.NET Multi-platform App UI の略称で、モバイル、タブレット、デスクトップにまたがるネイティブデバイスのアプリケーションを構築するためのフレームワークです。」と紹介しています。
 
2022年6月26日現在では、残念なことに .NET MAUI 自体は GA されたのですが、開発環境である Visual Studio は Windows 版も Mac 版も最新のプレビュー版での対応となっています。こちらは、ほどなく安定版の Visual Studio でも対応されるでしょう。
 
.NET MAUI は Xamarin.Forms から全く違う製品名に変わりましたが、何が違うのでしょうか。わかりやすく言えば、.NET MAUI は Xamarin.Forms の改良版です。では、具体的に .NET MAUI は Xamarin.Forms と比べどこが改良されたのか詳しく見ていきましょう。
 
 

Xamarin.Forms と .NET MAUIの主な違い

まず、Xamarin.Forms と .NET MAUI の主な違いをまとめてみました。色々違いがありますが、.NET 6 対応になりさまざまな点で改良されています。

Xamarin.Forms .NET MAUI
プロジェクトの構造 非 SDK スタイル(Franken-proj)
プラットフォームごとに個別のプロジェクトを使用
SDK スタイル
単一のプロジェクトで、複数プラットフォームをターゲットにできる
ツールチェーン .NETFramework .NET CLI
リソース管理 プラットフォームごとに個別管理
プラットフォーム固有のデバイスの解像度に応じたイメージを準備する必要がある
単一のプロジェクト内で一元管理
SVG を準備すれば各プラットフォームの解像度のPNGに変換でされる
スタートアップ 独自(App クラス) Generic Host 対応
ホットリロード 完全な XAML ホットリロード
(SDK5.x および Visual Studio 2019 16.9以降)
完全な .NET ホットリロード
完全な XAML ホットリロード
UI コントロールアーキテクチャ レンダラー ハンドラー

 
次に、.NET MAUI の改良点の中で特に注目したいポイントをご紹介します。
 
 

.NET MAUI のプロジェクト構成

.NET MAUI のプロジェクトは以下のようになっています。Xamarin.Forms のような「単一の共有プロジェクト + 複数のプラットフォーム固有プロジェクト」の構成ではなく、単一のプロジェクトで、複数プラットフォームをターゲットにできるようになりました。
 

 
 

Xamarin.Forms のアーキテクチャーに起因する問題点

Xamarin.Forms は登場当時、画期的なフレームワークでした。ですが、利用が進むにつれてアーキテクチャーに起因する問題点も顕在化していきました。
 

Xamarin.Forms のレンダラーアーキテクチャー

以下の図のようにレンダラーは共有プロジェクトの UI コントロール実装に依存しています。
 

 
 

Xamarin.Forms レンダラーアーキテクチャーの問題点

  • レンダラーが Xamarin.Forms の UI コンポーネントと密結合している。
  • アセンブリスキャンとリフレクションというコストの大きい処理を使用して UI コントロールのレンダラーを取得するため遅い。
  • 共有プロジェクトからネイティブ UI コントロールをカスタマイズする場合、たった1つのプロパティの変更であっても、共有プロジェクトとネイティブプロジェクトにまたがるレンダリングの仕組みを理解した上で、定型的な多くのコードを記述する必要があり、非常に手間がかかる。

 
 

.NET MAUI の最大の変更点

Xamarin.Forms からの最大の変更点は、レンダラーアーキテクチャーからハンドラーアーキテクチャーへの変更です。ハンドラーアーキテクチャの採用によってプラットフォーム固有のレンダリングの責務を、抽象化 UI フレームワークの実装から分離しました。
 

.NET MAUI で導入されたハンドラーアーキテクチャー

以下の図のようにハンドラーはインターフェースにのみ依存し、抽象化 UI コントロールの実装には依存しません。
また、共有コード内で複数のプラットフォームのネイティブ UI コントロールを直接操作できます。複数プラットフォーム対応のために条件付きコンパイルを使用しなければならないのは美しくないですが、残念ながらこれより良い手段は現在のところありません。

 

 
これによって以下に述べるようなアドバンテージが生まれました。
 

.NET MAUI ハンドラーアーキテクチャーのアドバンテージ

  • ハンドラーはアセンブリスキャンが不要となり速度が向上した。
  • 共有コード内でもでもネイティブ UI コントロールに直接アクセスしてプロパティを変更できる。
  • ハンドラーは、スタートアップコードの Generic Host 内に直接記述も可能で、簡単に実装および使用できるため、特定のコントロールまたはアプリ全体で使用されるすべてのコントロールのカスタマイズが簡単に実装できる。

 

(参考)Generic Host

Generic Host は、アプリの起動やシャットダウンのようなライフタイム管理やアプリの構成やロギング、DIのようなアプリのビジネスロジック自体とは関係ない基盤となる機能をカプセル化するオブジェクトです。これによって、アプリの基盤に関わる機能とビジネスロジックを分離できクリーンな構造になります。
 
Generic Host の詳細はこちらをご覧ください。
docs.microsoft.com
 
 

.NET MAUI のスタートアップコードの例

.NET MAUI では Generic Host に対応したため、スタートアップの処理が Xamarin.Forms とは大きく異なっています。
では、.NET MAUI のスタートアップコードのサンプルを見ていきましょう。
 
なお、以下コードは説明のために調整されたものですので、ベストプラクティスではありませんのでご注意ください。
 
まずは、コード全体を見ていきましょう。
Generic Host 内では、

  • 起動するアプリクラスの指定
  • フォントの登録
  • Dependency injection
  • ハンドラーを利用した UI のカスタマイズ

を行なっています。
 
スタートアップコードはMauiProgram.csに記述します。

 
MauiProgram.cs

using MauiUICustomizeSample.Controls;
using Microsoft.Maui.Handlers;
using Microsoft.Maui.Platform;

namespace MauiUICustomizeSample;

public static class MauiProgram
{
    public static MauiApp CreateMauiApp()
    {
        var builder = MauiApp.CreateBuilder();
        builder .UseMauiApp<App>()  // 起動するアプリクラスの指定
            .ConfigureFonts(fonts => // リソースフォルダ内のフォントの登録
            {
                fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
                fonts.AddFont("OpenSans-Semibold.ttf", "OpenSansSemibold");
            });

        // Dependency injection : AppSlell クラスを DI コンテナに登録
        builder.Services.AddTransient<AppShell>();

        // 全ての Label のカスタマイズ
        LabelHandler.Mapper.AppendToMapping(nameof(IView.Background), (handler, view) =>
        {
            if (view is Label)
            {
#if IOS
                handler.PlatformView.BackgroundColor = Colors.MediumSpringGreen.ToPlatform();
#elif ANDROID        
                handler.PlatformView.SetBackgroundColor(Colors.MediumSpringGreen.ToPlatform());
#endif
            }
        });

        // 特定のインスタンスの Button のカスタマイズ
        ButtonHandler.Mapper.AppendToMapping(nameof(IView.Background), (handler, view) =>
        {
            if (view is MyButton)
            {
#if IOS
                handler.PlatformView.BackgroundColor = Colors.LightCoral.ToPlatform();
                handler.PlatformView.SetTitleColor(Colors.White.ToPlatform(), UIKit.UIControlState.Normal);
                handler.PlatformView.Layer.CornerRadius = 7;
#elif ANDROID
                handler.PlatformView.SetBackgroundColor(Colors.LightCoral.ToPlatform());
#endif
            }
        });

        return builder.Build();
    }
}

 
 
次に個別の処理について詳しく見ていきます。
 

MAUI 用の Generic Host のビルダーを作成

MauiAppCreateBuilderメソッドで MauiAppBuilder のインスタンスが作成されます。

var builder = MauiApp.CreateBuilder();

 
 

起動するアプリクラス(このサンプルでは App クラス)を指定

MauiAppBuilderUseMauiAppメソッドの型パラメーターに起動するアプリクラスの型(App)を指定します。

builder.UseMauiApp<App>()

 
App クラスはApp.xaml.csで定義されています。

 
App.xaml.cs のコードは以下のようになっています。

namespace MauiUICustomizeSample;

public partial class App : Application
{
	public App(AppShell appShell)
	{
		InitializeComponent();
		MainPage = appShell;
	}
}

 
 

フォントの登録

プロジェクト内の /Resources/Fonts 内に配置されたフォントを登録します。

 
MauiAppBuilderConfigureFontsメソッド内のデリゲートで登録を行います。

.ConfigureFonts(fonts =>
{
    fonts.AddFont("OpenSans-Regular.ttf", "OpenSansRegular");
    fonts.AddFont("OpenSans-Semibold.ttf", "OpenSansSemibold");
});

 
 

AppSlell クラスを DI コンテナに登録

AppSlell クラスを DI コンテナに登録し、インスタンスが注入されるようにします。

builder.Services.AddTransient<AppShell>();

 
これによって、App.xaml.cs のコンストラクタの appShell パラメータにインスタンスが注入されます。

 
App.xaml.cs

namespace MauiUICustomizeSample;

public partial class App : Application
{
	public App(AppShell appShell)
	{
		InitializeComponent();
		MainPage = appShell;
	}
}

 
 

ハンドラーを利用した UI のカスタマイズ

サンプルでは、「特定の種類の UI コントロール全てをカスタマイズする場合」と「ある UI コントロールの特定のインスタンスのみをカスタマイズする場合」の2つのパターンの UI カスタマイズを行なっています。両者とも Xamarin.Forms の場合と比較して驚くほど簡単にカスタマイズができるようになっています。
 

特定の種類の UI コントロール全てをカスタマイズする場合

こちらでは、Label コントロール全ての背景色をMediumSpringGreenに変更します。
 

 
MauiProgram.cs

        // 全ての Label のカスタマイズ
        LabelHandler.Mapper.AppendToMapping(nameof(IView.Background), (handler, view) =>
        {
            if (view is Label)
            {
#if IOS
                handler.PlatformView.BackgroundColor = Colors.MediumSpringGreen.ToPlatform();
#elif ANDROID        
                handler.PlatformView.SetBackgroundColor(Colors.MediumSpringGreen.ToPlatform());
#endif
            }
        });

AppendToMappingActionデリゲート内で、UI コントロールの型が Labelの場合に、カスタマイズしたい色を設定します。

handler.PlatformViewには、iOS の場合 UILabel、Android の場合 AppCompatTextViewが割り当てられていますので、それぞれのネイティブ UI コントロールのプロパティを変更することで色を変更できます。設定する色はToPlatformメソッドによってそれぞれのプラットフォームのネイティブカラーに変換されます。
 
ここで注目したいことは、たった数行のコードで共有コード内のUILabel.BackgroundColorや、AppCompatTextView.SetBackgroundColorといったプロパティやメソッドが使用できていることです。

Xamarin.Forms でこのようなことをするには、各プラットフォームプロジェクト内でクラスを定義し定型的なコードを書く必要がありましたので、比較にならないほどシンプルになっているのがわかります。
 

ある UI コントロールの特定のインスタンスのみをカスタマイズする場合

こちらでは、Button コントロール特定のインスタンスの背景色をLightCoralに変更します。
 
Button のサブクラス MyButton を作成します。

MyButton.cs

namespace MauiUICustomizeSample.Controls
{
	public class MyButton : Button
	{
		public MyButton()
		{
		}
	}
}

 
MauiProgram.csMyButton に対してカスタマイズを適用します。

 
MauiProgram.cs

        // 特定のインスタンスの Button のカスタマイズ
        ButtonHandler.Mapper.AppendToMapping(nameof(IView.Background), (handler, view) =>
        {
            if (view is MyButton)
            {
#if IOS
                handler.PlatformView.BackgroundColor = Colors.LightCoral.ToPlatform();
                handler.PlatformView.SetTitleColor(Colors.White.ToPlatform(), UIKit.UIControlState.Normal);
                handler.PlatformView.Layer.CornerRadius = 7;
#elif ANDROID
                handler.PlatformView.SetBackgroundColor(Colors.LightCoral.ToPlatform());
#endif
            }
        });

AppendToMappingActionデリゲート内で、UI コントロールの型が MyButtonの場合に、カスタマイズしたい色を設定します。
 
handler.PlatformViewには、iOS の場合 UIButton、Android の場合 MaterialButtonが割り当てられていますので、それぞれのネイティブ UI コントロールのプロパティを変更することで色を変更できます。設定する色はToPlatformメソッドによってそれぞれのプラットフォームのネイティブカラーに変換されます。
 
カスタマイズしたコントロールを XAML 内で使用するには、xmlns:button="clr-namespace:MauiUICustomizeSample.Controls" のように名前空間を指定します。
 
MyButtonのみ背景色がカスタマイズされます。
 

 
MainPage.xaml

<?xml version="1.0" encoding="utf-8" ?>
<ContentPage xmlns="http://schemas.microsoft.com/dotnet/2021/maui"
             xmlns:x="http://schemas.microsoft.com/winfx/2009/xaml"
             xmlns:button="clr-namespace:MauiUICustomizeSample.Controls" 
             x:Class="MauiUICustomizeSample.MainPage">
			 
    <ScrollView>
        <VerticalStackLayout 
            Spacing="25" 
            Padding="30,0" 
            VerticalOptions="Center">

            <Image
                Source="dotnet_bot.png"
                SemanticProperties.Description="Cute dot net bot waving hi to you!"
                HeightRequest="200"
                HorizontalOptions="Center" />
                
            <Label 
                Text="Hello, MAUI!"
                SemanticProperties.HeadingLevel="Level1"
                FontSize="32"
                HorizontalOptions="Center" />
            
            <Label 
                Text="Welcome to .NET Multi-platform App UI"
                SemanticProperties.HeadingLevel="Level2"
                SemanticProperties.Description="Welcome to dot net Multi platform App UI"
                FontSize="16"
                HorizontalOptions="Center" />

            <HorizontalStackLayout 
                Spacing="10"  
                HorizontalOptions="Center">
                
                <Button 
                    x:Name="CounterBtn"
                    WidthRequest="120"
                    Text="Click me"
                    SemanticProperties.Hint="Counts the number of times you click"
                    Clicked="OnCounterClicked"
                    HorizontalOptions="Start" />

                <button:MyButton
                    x:Name="CustomizedBtn"
                    WidthRequest="120"
                    Text="Customized"
                    HorizontalOptions="End" />

            </HorizontalStackLayout>
        </VerticalStackLayout>
    </ScrollView>
 
</ContentPage>

 
iOS での実行結果は以下のようになります。
ラベルの全体の背景色と、右側のボタンの背景色がカスタマイズされています。
 

 
ハンドラーを使用したコントロールのカスタマイズの詳細はこちらをご覧ください。
docs.microsoft.com
 
 

まとめ

これまでご説明しましたように、.NET MAUI では、Xamarin.Forms の面倒だった部分が非常に扱いやすくなり、直感的でシンプルなコードで記述できるよう改善されました。また、アセンブリスキャンやリフレクションなどコストの高い処理を回避することで起動速度も向上しています。
 
つまり「 .NET MAUI = よりシンプルで使いやすくなった Xamarin.Forms」と言えます。というわけで、早速使ってみましょう!



 
 

.NET 6 で開発できるアプリケーションの整理

はじめに

.NET Framework が2002年にリリースされてから20年という歳月が流れ、当初はWindows 専用でコンソールアプリやデスクトップアプリ、Webアプリのみの対応であったものが、.NET 6では、WindowsやLinuxやMac、iOSやAndroidなど様々なプラットフォーム上で動作するアプリやWebアプリ、IoT、ゲームなど様々なアプリ開発できるようになりました。さらに、たとえばWebアプリを開発する場合でも複数のテクノロジーが利用可能となっています。
その反面、あまりにできることが多すぎて、アプリを開発するときに自分のシナリオにあったテクノロジーを選択するための全貌を把握するのが困難になっています。
 
今回は新規アプリを開発するシナリオでも.NET Frameworkから.NET 6へ移行するシナリオでも、どのワークロードを利用するのがよいか迷わないように開発できるワークロードの種類と特長について概要を整理します。
 
逆にワークロードごとの詳細な情報は公式ドキュメントも充実しており検索で多数でヒットしますので、そちらを参照していただけますと幸いです。
 
 

ワークロードごとの主要なアプリテンプレート対応一覧

ほとんどの.NET Frameworkのワークロードには対応した.NET 6のワークロードが準備されていますが、一部対応する.NET 6のワークロードがないものがあります。また.NET5や.NET 6で新規に登場したワークロードもあります。
 

移行前(.NET Framework / mono) 推奨移行先(.NET 6)
アプリの種類 ランタイム/SDK プラットフォーム アプリの種類 ランタイム/SDK プラットフォーム
コンソール アプリ コンソール .NET Framework Windows コンソール .NET 6 Windows/Linux/macOS
Windows アプリ Windows フォーム .NET Framework Windows Windows フォーム .NET 6 Windows
WPF .NET Framework Windows WPF .NET 6 Windows
UWP Universal Windows Windows WinUI Windows App SDK Windows
Web アプリ ASP.NET Web Forms .NET Framework Windows 移行先なし
ASP.NET MVC .NET Framework Windows ASP.NET Core MVC .NET 6 Windows/Linux/macOS
Blazor Server .NET 6 Windows/Linux/macOS
Blazor WebAssembly .NET 6 Windows/Linux/macOS
モバイルアプリ iOS Xamarin.iOS iOS iOS .NET 6 iOS
Android Xamarin.Mac Android Android .NET 6 Android
Xamarin.Forms Xamarin.Forms Android/iOS/Windows(UWP) .NET MAUI .NET MAUI .NET 6 Android/iOS/macOS/Mac Catalyst/Windows(WinUI)
macOS アプリ Mac Xamarin.Mac macOS Mac Catalyst .NET 6 macOS/Mac Catalyst
Azure Azure Functions .NET Framework Azure Functions (Runtime 1.x) Azure Functions .NET 6 Azure Functions (Runtime 4.x)
Azure WebJobs .NET Framework Azure WebJobs Azure WebJobs .NET 6 Azure WebJobs

 
では、ワークロードごとの特長について、それぞれ解説していきます。
なお、以下で移行についても述べますが、ここでの「移行」とは、あくまでも.NET Frameworkアプリのソースコードを.NET 6でビルドし動作できるようにする最低限度の移行作業を意味しています。アプリケーションのモダナイゼーションを本格的に進めるような場合は、さらに追加の作業が必要となるのでご留意ください。
 
 

コンソールアプリ

・.NET Upgrade Assistant対応

コンソールアプリは.NET6でも引き続きサポートされています。「最上位レベルのステートメント」「暗黙的なusingディレクティブ」「グローバルusingディレクティブ」といった新機能によって.NET Framework時代より非常に簡潔にアプリケーションコードが記述できるようになっています。
もちろん、以前と同じスタイルでアプリケーションコードを記述することも可能です。.NET Upgrade Assistantに対応しており、.NET Frameworkアプリからの移行に関する手間も少なく、比較的容易に移行が可能です。
.NET Framework時代はWindows専用でしたが、.NET6ではWindows / Linux / macOSでの利用が可能になりました。
 
 

Windowsフォームアプリ

・.NET Upgrade Assistant対応

Windowsフォームアプリはすでに過去のものというイメージがあるかもしれませんが.NET6世代でも新規コントロールの追加新機能の追加など手厚くサポートされておりまだまだ現役で利用可能です。
Windowsフォームの利点は何といっても初心者の開発者でも素早くアプリを開発できることなので、WPFやWinUI 3の難易度が高いと感じた場合や小規模のアプリであれば新規アプリに使用しても全く問題ありません。

MVVMのようなUIとロジックの分離についても公式のライブラリがないので多少手間がかかりますが、検索すれば多くの情報がヒットしますのでそれを参考にCommandやViewModelのベースを自前実装してしまえば分離可能です。

.NET FrameworkのWindowsフォームアプリからの移行先としても、.NET6のWindowsフォームアプリを第一の選択とすることをお勧めします。.NET Upgrade Assistantに対応しているため移行の一部も自動化できます。

.NET FrameworkのWindowsフォームアプリを.NET6のWPFに移行したいような場合は、結局大幅な改修となってしまうので移行ではなく新規開発としたほうがよいでしょう。
 
 

WPFアプリ

・.NET Upgrade Assistant対応

Windows デスクトップアプリを新規で開発するシナリオの場合、WPFかWinUI 3 にするかという選択になります。公式の推奨はWinUI 3なのですが、UWP系のGUIライブラリは短期間に方針が変わり迷走しているのでWinUI 3が今後も安定してサポートされ続け利用できるかということに少し疑問があります。(新たなライブラリが発表されWinUI 3が更新されなくなってしまう懸念)

逆にWPFは今後も長期間にわたってサポートされ続けると予想されますので、PC上でマウス操作するアプリを開発するならWPFが無難と言えます。(WPFはタッチ操作が一般的になる前にリリースされたライブラリのためタッチ操作にフレンドリーな設計になっていません。

タブレットでタッチ操作前提のアプリであればWinUI 3の方がお勧めとなります。
.NET FrameworkのWPFアプリの移行先としては.NET6のWPFアプリが推奨です。
 
 

UWPアプリ

これからUniversal Windows Platformアプリを新規で開発するならUWPアプリではなくWinUI 3アプリが推奨となります。
UWPはPC以外のWindowsデバイスでの動作も視野に入れていましたが、Windows Phoneが終了し、Surface Hubもあまり普及していませんのでUWPを新規で採用する理由はほぼありません。
マイクロソフトもUWPが実質的に互換性維持のために提供される状態へ入ったと意図する説明をしています。
既存アプリのアップグレードをする場合は、WinUI 3への移行となります。
 
 

WinUI 3アプリ

WinUI 3は2022年現在、開発に採用する場合においては少し慎重な判断が必要な立ち位置となっています。

WinUI 3はWindowsデスクトップアプリとUniversal Windows Platformアプリを開発可能です。
公式の推奨はWinUI 3なのですが、UWP系のGUIライブラリは短期間に方針が変わり迷走しているのでWinUI 3が今後も長期間安定して利用できるかということに疑問があります。ユーザーに受け入れられず、さらに新たなライブラリが発表され更新されなくなってしまう懸念があるので、ユーザーに受け入れられてしっかり普及するかどうか、もうしばらく様子見でもよいと考えられます。
また、WinUI 3はUWPをベースにしているため、使い勝手がWPFとは違う部分があるので、WPFに慣れておりWPFで事足りる場合はWPFを採用する方が無難です。
 
 

ASP.NET Web Forms アプリ

ASP.NET Web Formsは.NET Frameworkでのみ開発できます。.NET6に後継はありません。よって、現在、新規のWebアプリを開発するシナリオでASP.NET Web Formsを選択することはありません。

ASP.NET Web Formsアプリを.NET6に移行する場合、移行先としてはBlazor Server アプリが案内されていますが、実際には「移行」という範囲を超えたコードの書換えが必要になります。あくまでもBlazor Server アプリの設計思想がこれまでASP.NET Web Formsの開発者に理解しやすいという意味での案内となっています。
ASP.NET Web Forms は今後も.NET Framework 4.8のサポートが終了するまでサポートされますので、可能な限り現行のアプリを延命することが第一の選択になります。
どうしてもASP.NET Web Formsアプリを.NET6に移行したい場合、ASP.NET Core MVCアプリ、Blazor Serverアプリ、Blazor WebAssembly アプリのどれかに移行することになります。
 

ASP.NET MVC アプリ / ASP.NET Core MVC アプリ

・.NET Upgrade Assistant対応

ASP.NET Core MVC アプリを新規で開発するシナリオの場合、.NET6でもASP.NET Core MVCアプリとしてサポートされているので問題なく開発可能です。ただし、新規アプリを開発する場合には最初にサーバー上でロジックを実行しWebページのレンダリング結果をクライアントに送信する従来型のWebアプリかブラウザーでUIロジックの大部分を実行し、Web APIを介してサーバーと通信するシングルページアプリケーション (SPA) を選択する必要があります。
そのうえで、従来型のWebアプリであればASP.NET Core MVCをSPAであればBlazor ServerアプリまたはBlazor WebAssemblyを選択します。

Webアプリのテクノロジーの選択については以下の記事も参考になります。

参考情報:従来の Web アプリケーションかシングル ページ アプリケーション (SPA) を選択する
docs.microsoft.com


移行の場合であれば、.NET Upgrade Assistantに対応していますので、移行プロセスの一部は自動で実行可能です。なお、ASP.NET Core MVCでは起動プロセスの取り扱いとJavaScriptやCSSの配置方法が変更されているので書き換えが必要となります。
 
 

iOS アプリ

.NET でiOSアプリを開発するシナリオとして最も有効なのは、Windows アプリを iOS に移植したい場合でiOSらしいUXを実現したいというケースです。UIは再作成が必要ですが、ロジック部分はかなりの部分が流用可能です。

iOS アプリを新規で開発する場合、.NET6でもサポートされているので問題なく開発可能です。
2022年5月8日時点で.NET MAUIはRC2までリリースされていますので、近いうちにほとんど現状のままで正式版がリリースされると考えられます。
Visual Studio 上からはiOS アプリのテンプレートが選択できませんが、以下のようにコマンドでプロジェクトを新規作成できます。

dotnet new ios

移行の場合も、SDKの内容の変更はほとんどありませんので、.csprojファイルをSDKスタイルに書換えTFMを「net6.0-ios」に設定し、Visual Studio上のエラーや警告を修正すれば移行終了です。
今後正式版がリリースされた時点で何らかの自動アップグレードの手段が提供される可能性はあります。
 
 

Android アプリ

.NET でAndroidアプリを開発するシナリオとして最も有効なのは、Windows アプリを Androidに移植したい場合でAndroidらしいUXを実現したいというケースです。UIは再作成が必要ですが、ロジック部分はかなりの部分が流用可能です。

Androidアプリを新規で開発する場合、.NET6でもサポートされているので問題なく開発可能です。
2022年5月8日時点で.NET MAUIはRC2までリリースされていますので、近いうちにほとんど現状のままでGAされると考えられます。
Visual Studio 上からはAndroidアプリのテンプレートが選択できませんが、以下のようにコマンドでプロジェクトを新規作成できます。

dotnet new android

移行の場合も、SDKの内容の変更はほとんどありませんので、.csprojファイルをSDKスタイルに書換えTFMを「net6.0- android」に設定し、Visual Studio上のエラーや警告を修正すれば移行終了です。
今後正式版がリリースされた時点で何らかの自動アップグレードの手段が提供される可能性はあります。
 
 

Xamarin.Forms アプリ

Xamarin.Formsアプリを開発するシナリオとしては、Windows アプリを iOSとAndroidに移植したい場合でiOSやAndroidらしいUXにはそこまでこだわりがない場合があてはまります。UIは再作成が必要ですが、ロジック部分はかなりの部分が流用可能となります。
また、あまり複雑でないiOS/Androidのクロスプラットフォームアプリを開発したいが、開発者が.NETに慣れておりiOS/Androidには不慣れなケースもあてはまります。不慣れなことにチャレンジするよりはストレスなく始めることが可能となります。

なお、これからXamarin.Forms アプリを新規で開発する場合注意が必要です。
Xamarin.Formsは.NET MAUI の正式版がリリースされてから 1年後(2023年6月頃と予想されます)にサポートが終了するため、開発するアプリのリリース時期に応じて、一旦Xamarin.Forms で開発し.NET MAUIへ移行するか、今の時点で.NET MAUIのRC2を使って開発を進めてしまうか決めることになります。
 
 

.NET MAUI アプリ

.NET MAUIアプリを開発するシナリオとしては、(Xamarin.Formsと同じですが)Windows アプリを iOSとAndroidに移植したい場合でiOSやAndroidらしいUXにはそこまでこだわりがない場合があてはまります。UIは再作成が必要ですが、ロジック部分はかなりの部分が流用可能となります。
また、あまり複雑でないiOS/Androidのクロスプラットフォームアプリを開発したいが、開発者が.NETに慣れておりiOS/Androidには不慣れなケースもあてはまります。不慣れなことにチャレンジするよりはストレスなく始めることが可能となります。

.NET MAUIの正式版がリリースされた時点(2022年6月までにはリリースされる予定)からは.NET MAUI アプリを選択することが推奨になります。
 
 

Xamarin.Mac アプリ / Mac Catalyst アプリ

.NET でMacアプリを開発するシナリオとして最も有効なのは、Windows アプリを macOS に移植したいというケースです。UIやプラットフォームに依存のコードは再作成が必要ですが、プラットフォームに関係ないビジネスロジックのコードは流用可能です。

Macアプリを新規で開発する場合、.NET6でもサポートされているので問題なく開発可能です。
2022年5月8日時点で.NET MAUIはRC2までリリースされていますので、近いうちにほとんど現状のままで正式版がリリースされると考えられます。
Visual Studio 上からはMacアプリのテンプレートが選択できませんが、以下のようにコマンドでプロジェクトを新規作成できます。

dotnet new maccatalyst

移行の場合も、SDKの内容の変更はほとんどありませんので、.csprojファイルをSDKスタイルに書換えTFMを「net6.0-maccatalyst」に設定し、Visual Studio上のエラーや警告を修正すれば移行終了です。
今後正式版がリリースされた時点で何らかのXamarin.Macからの自動アップグレードの手段が提供される可能性はあります。

Blazor Serverアプリ/ Blazor WebAssembly アプリ

.NETでSPAを開発したいシナリオの場合Blazor Serverアプリを検討します。Blazorの場合Vueなどを利用する場合と比べてJavaScriptへの深い理解が不要となるため、.NETに慣れておりJavaScriptの経験が浅い開発者がSPAを開発するシナリオでは有効な選択肢となります。

Blazor Serverアプリでは アプリのロジックはC#で記述しサーバー上で実行されます。 クライアントのブラウザー側はプレーンなHTML とJavaScriptとなり、 UI の操作が行われることでロジックの動作や画面の更新などが必要になった場合はサーバーとSignalR 通信が行われ、返ってきたレスポンスでブラウザーのUIが更新されます。
この動作モデルがASP.NET WebForm と似ているため、公式ではASP.NET WebFormの移行先としてBlazor Serverアプリを推奨しています。

.NETでBlazor ServerアプリよりもさらにリッチなUIを提供したいシナリオや、サーバーとの通信が不要なWebアプリを提供したいシナリオではBlazor WebAssemblyアプリを検討します。(もちろん、Blazor WebAssemblyアプリでもサーバーとの通信は利用できます。)

Blazor WebAssemblyアプリはその名の通り、C#でWebAssemblyを開発できます。WebAssemblyはブラウザー上で動作する非常に高度なUIをJavaScriptに不慣れな開発者でもC#で記述することができます。コンセプトとしてはSilverlightに似ていますが、プラグインを使用ないことやオープンな Web 標準を使用している点がSilverlightより優れています。

Blazor ServerアプリとBlazor WebAssembly アプリのどちらを選択するかについては以下の記事も参考になります。

参考情報:どの Blazor ホスティング モデルを選択するか
docs.microsoft.com
 
 

Azure Functions

Azure Functionsの関数アプリを新規開発したい場合、.NET6での開発が推奨となります。
すでに稼働中の関数アプリを.NET6に移行したい場合は検証が必要ですが、関数アプリの性質上、互換性が問題となる影響があることはそれほど多くなく、発見された場合でも容易に修正が可能な場合が多いでしょう。

アプリケーションコードの移行については以下の記事も参考になります。

参考情報:既存のアプリのアップグレード
docs.microsoft.com
 
 

Azure WebJobs

・.NET Upgrade Assistant対応

WebJobsはApp Service上で定期的なプログラムを実行するシナリオやApp ServiceにデプロイされたWebアプリやAPIアプリ内からプログラムを実行させるシナリオで利用します。

WebJobsを新規開発したい場合、.NET6での開発が推奨となります。
.NET6の場合WebJobsのプロジェクトテンプレートが用意されていないので、コンソールアプリを作成し必要に応じてAzure WebJobs SDKインストールします。詳しい手順については以下の記事が参考になります。

参考情報:チュートリアル: イベント ドリブンのバックグラウンド処理に Azure WebJobs SDK の使用を開始する
docs.microsoft.com



.NET FrameworkのWebJobsからの移行先としては、要件によってはAzure Functionsに移行することも選択肢の一つとなります。

Functionsに移行すべきか、WebJobsのまま移行すべきかについては以下の記事も参考になります。

参考情報:Functions と WebJobs の比較
docs.microsoft.com
 
.NET6のWebJobsに移行する場合は.NET Upgrade Assistantに対応しているため移行の一部も自動化できます。
 
 

まとめ

.NET6はどんなプラットフォームで動くどんなアプリでも開発できるすばらしい開発環境になった反面、自分のシナリオに合ったワークロードの見極めが少々難しくなっています。

業務アプリケーションを開発する際に利用が想定されるワークロードについては一通り概要に触れることができました。
 
 

.NET MAUI Preview 7 の更新情報

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

なお、オリジナルの記事はこちらです。
devblogs.microsoft.com
 
.NET MAUI Preview 8 の更新情報はこちらです。
hiro128.hatenablog.jp
 
 

新しいレイアウト(.NET MAUI Preview 7)

新しいレイアウトはデフォルトで有効になっており、新しいレイアウトは 7 年間の Xamarin.Forms のレイアウトから得た知見を採用した新しい LayoutManager アプローチに基づいて、一貫性、パフォーマンス、メンテナンス性が最適化されています。
 
従来の Xamarin.Forms のレイアウトは、Xamarin.Formsからの移行プロジェクトとの互換性のために Microsoft.Maui.Controls.Compatibility 名前空間にのみ存在するようになりました。
 
公式情報:New Layouts
 
 

アクセシビリティの変更と改善(.NET MAUI Preview 7)

TabIndex および IsTabStop の削除(.NET MAUI Preview 7)

TabIndex と IsTabStopプロパティは、開発者がスクリーンリーダーで読まれるUI要素の順序を制御するために Xamarin.Forms で導入されたが、実際には混乱を招きニーズを満たしていませんでした。
 
.NET MAUI では、インターフェイスの構造をプログラムで操作するのではなく、読まれたいように UI を順序付ける設計アプローチを推奨しています。
.NET MAUI で順番をコントロールしなければならない場合には、コミュニティツールキットの SemanticOrderView を推奨しています。
 
公式情報:TabIndex and IsTabStop Removed
 

SetSemanticFocus とアナウンス(.NET MAUI Preview 7)

新しい SemanticExtensions クラスの一部として、スクリーンリーダーのフォーカスを特定の要素に移動させることができるように、新しい SetSemanticFocus メソッドが追加されました。
 
公式情報:SetSemanticFocus and Announce
 

フォントスケーリング(.NET MAUI Preview 7)

すべてのプラットフォームのすべてのコントロールで、フォントスケーリングがデフォルトで有効になりました。
 
これにより、OS 上でテキストスケーリングの設定を調整すると、その設定がアプリケーションの UI に反映され、デフォルトでよりアクセシブルなアプリケーションが実現できます。
 
公式情報:Font Scaling
 
 

その他の注目すべき変更と追加(.NET MAUI Preview 7)

公式情報:Additional Highlights

  • Xamarin.Forms からアップグレードするプロジェクトをサポートする Effects のサポートの追加 #1574
  • AppThemeBinding の改良による、ダークテーマとライトテーマのモードのサポート #1657
  • ScrollView ハンドラ #1669
  • Android シェルのコアへの移植 #979
  • 複雑なオブジェクトを渡すシェルのナビゲーション #204
  • XAML ホットリロードのためのビジュアルツリーヘルパーの追加 #1845
  • System.ComponentModel.TypeConverterへの切り替え #1725
  • ウィンドウ ライフサイクル イベント #1754
  • ページナビゲーションイベント #1812
  • CSS プレフィックスを -maui に更新 #1877

 
 

.NET MAUI Preview 8 の更新情報

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

なお、オリジナルの記事はこちらです。
devblogs.microsoft.com
 
.NET MAUI Preview 9 の更新情報はこちらです。
hiro128.hatenablog.jp
 
.NET MAUI Preview 7 の更新情報はこちらです。
hiro128.hatenablog.jp
 
 

.NET MAUI の GA の時期の遅延ついて(.NET MAUI Preview 8)

  • .NET MAUI の RC は2022年第1四半期に、GA は 2022年第2四半期の初めを目標とすることに延期されました。
  • Xamarin は引き続き強化され、本番用のモバイルアプリの構築には Xamarin が推奨となります。
  • .NET MAUIで提供される予定のすべての機能は、.NET 6 がGAされる2021年11月にプレビューとして利用可能になります。
  • その後は、引き続き品質向上やユーザーからのフィードバックへの対応に取り組む予定となっています。
  • .NET MAUIのプレビューは毎月リリースされ続けます。

公式情報:Update on .NET Multi-platform App UI (.NET MAUI) - .NET Blog
 
 

Visual Studio 2022 との統合(.NET MAUI Preview 8)

.NET MAUIをインストールするには、Visual Studio 2022 Preview 17.1 以上(Windows版)で「.NET によるモバイル開発」ワークロードにチェックを入れます。
 
将来のリリースでは、.NET MAUIは独自のトップレベルのワークロードに昇格する予定となっています。
 

なお、Visual Studio for Mac 2022 Preview ではまだ .NET MAUI はサポートされていません。
 
公式情報:Visual Studio 2022 Preview 4 Productivity
 
 

MAUI アプリの起動方法の更新(.NET MAUI Preview 8)

MAUI アプリの起動方法が更新され、各プラットフォームでは、MauiProgram.CreateMauiAppを呼び出すようになりました。
 
公式情報:.NET MAUI SDK Updates
 
 

Android のアップデート(.NET MAUI Preview 8)

Android 向けにビルドされた .NET 6 アプリケーションでは、Android 12(API 31)がデフォルトになります。
 
Android 12 を使用するには、JDK 11 を手動でインストールする必要がありますが、Visual Studio の Android ツールが JDK 11 をサポートするまでの間、Android デザイナー、SDK マネージャー、デバイスマネージャーに好ましくない影響を与える可能性があります。
 
Visual Studio の Androidツール が JDK 11 を使用するように更新されたら、JDK 11 が .NET MAUI にデフォルトでバンドルされます。
 
Androidプロジェクトでは、デフォルトで MaterialTheme が使用されるようになりました。これにより、Android でランタイムエラーが発生する場合は、Platforms/Android/MainActivity.cs で @style/Maui.SplashTheme が指定されているかを確認してください。詳細は更新された .NET MAUIテンプレートを参照ください。
 
公式情報:Android Updates
 
 

その他の更新(.NET MAUI Preview 8)

公式情報:Other Changes

  • MinHeightRequest, MaxHeightRequest, MinWidthRequest, MaxWidthRequestに "Request "という接尾辞がなくなり、レイアウトシステムがそれらを真の値として扱うようになりなりました。
  • 任意のコントロールマッパーにビヘイビアを追加する方法を簡素化- #1859
  • シェルテーマのスタイリングの様々な改善
  • Android #2027 と iOS #2029 用の RefreshView を追加
  • AbsoluteLayout を追加 #2136
  • Right-to-Left (RTL) FlowDirectionの追加 #948
  • Button.Icon ImageSourceを追加 #2079

 
 
 

.NET MAUI Preview 9 の更新情報

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

なお、オリジナルの記事はこちらです。
devblogs.microsoft.com
 
.NET MAUI Preview 10 の更新情報はこちらです。
hiro128.hatenablog.jp
 
.NET MAUI Preview 8 の更新情報はこちらです。
hiro128.hatenablog.jp
 
 

コントロールの更新(.NET MAUI Preview 9)

 
公式情報:Announcing .NET MAUI Preview 9 - .NET Blog
 
 

新しいボーダーコントロール(.NET MAUI Preview 9)

  • 新しい Microsoft.Maui.Graphics ライブラリは、ネイティブのグラフィックスエンジンに基づいた一貫した UI 描画 API を提供します。
  • .NET MAUI のほとんどのレイアウトやコントロールに、ボーダー、コーナーレンダリング、美しいシャドウを簡単に追加できます。
  • 新しいボーダーコントロールは、任意のレイアウトやコントロールをラップして、ボーダーや各コーナーの独立した制御を追加することができます。

 
公式情報:Borders, Corners, and Shadows – Oh my!
 
 

高速な Android のスタートアップ(.NET MAUI Preview 9)

Preview 9には、.NET MAUIのスタートアップトレースプロファイルが同梱されており、コマンドラインからビルドする際に使用することができます。 
[android] add AOT profile for .NET MAUI by jonathanpeppers · Pull Request #2496 · dotnet/maui · GitHub
 
スタートアップトレースを活用して起動時の実行経路を追跡することで、アプリケーションの起動時に実行される部分のみを AOT 化し、スピードとサイズのバランスを取ることができます。
 
公式情報:Quick Android Startup

コントロールのエコシステム(.NET MAUI Preview 9)

DevExpress、Syncfusion、Telerik は最近 .NET MAUI用の新しいコントロールセットを出荷しています。それらでは、Microsoft.Maui.Graphicsの強力なグラフィックサポートが利用されています。
 
公式情報:
Announcing .NET MAUI Preview 9 - .NET Blog

 
 

.NET MAUI Preview 10 更新情報

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

なお、オリジナルの記事はこちらです。
devblogs.microsoft.com
 
.NET MAUI Preview 11 の更新情報はこちらです。
hiro128.hatenablog.jp
 
.NET MAUI Preview 9 の更新情報はこちらです。
hiro128.hatenablog.jp
 
 

.NET MAUI のインストール(.NET MAUI Preview 10)

.NET MAUIをインストールするには、Visual Studio 2022 Preview 17.1 以上(Windows版)で「.NET によるモバイル開発」ワークロードにチェックを入れます。
 
将来のリリースでは、.NET MAUIは独自のトップレベルのワークロードに昇格する予定となっています。
 

なお、Visual Studio for Mac 2022 Preview ではまだ .NET MAUI はサポートされていません。
 
公式情報:Announcing .NET MAUI Preview 10 - .NET Blog
 
 

コントロールと機能のアップデート(.NET MAUI Preview 10)

CollectionView と IndicatorView のハンドラ実装が新たに追加されました。
その他のコントロールにも、VerticalTextAlignment、TextTransform などのプロパティが実装されました。
 
Xamarin.Forms のレンダラーアーキテクチャは、.NET MAUI ではハンドラーアーキテクチャーに進化しました。
ハンドラーについての詳細は以下を参照ください。
docs.microsoft.com
 
公式情報:Announcing .NET MAUI Preview 10 - .NET Blog
 
 

.NET MAUI Preview 11 更新情報

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

なお、オリジナルの記事はこちらです。
devblogs.microsoft.com
 
.NET MAUI Preview 12 の更新情報はこちらです。
hiro128.hatenablog.jp
 
.NET MAUI Preview 10 の更新情報はこちらです。
hiro128.hatenablog.jp
 
 

Fluent Design SystemによるWindowsコントロールのスタイリング(.NET MAUI Preview 11)

.NET MAUI では、アプリケーションは既定で単一のコードベースからプラットフォーム固有のデザインとエクスペリエンスを提供されます。Windows 11 における更新された Fluent Design System による新しいUIスタイルを含みます。
 
公式情報:Announcing .NET MAUI Preview 11 - .NET Blog
 
 

マルチ Window アプリ(.NET MAUI Preview 11)

.NET MAUI では Xamarin.Forms では不可能だったマルチ Window アプリが利用できます。Application.Current.Windows に作成したすべてのウィンドウへの参照は保持され簡単に新しいウィンドウを開けます。
(Windows App SDK のマルチ Window の実装は、Windows App SDK v1.1 がリリースされるまで実験的なリリースとなります)
 
公式情報:Announcing .NET MAUI Preview 11 - .NET Blog
 
 

C# 10 の新機能を利用したシンプルなテンプレート(.NET MAUI Preview 11)

暗黙的な using ディレクティブやファイルスコープの名前空間宣言などの C# 10 の新機能によりシンプルなテンプレートに更新されました。MauiProgram.cs も簡素化されました。
 
暗黙的な using ディレクティブについては以下を参照ください。
hiro128.hatenablog.jp
ファイルスコープの名前空間宣言については以下を参照ください。
hiro128.hatenablog.jp
 
公式情報:Announcing .NET MAUI Preview 11 - .NET Blog
 
 

iOS, macOS, tvOS における型の調整(.NET MAUI Preview 11)

  • .NET 6 の iOS と Mac Catalyst SDK では、System.nintとSystem.nuintではなく、C# 9.0 から採用された新しいネイティブ型(nint、nuint)が利用されます。これにより、Xamarin.iOS や Xamarin.Mac 向けにビルドした既存のコードやアセンブリとの互換性が維持されなくなります。
  • プロジェクトを .NET 6 にアップグレードする場合、すべてのコードを.NET 6 をターゲットに再コンパイルする必要があります。
  • 既存のアセンブリ(古いTargetFrameworkIdentifier である xamarinios10 用にビルドされた NuGet パッケージなど)は動作せず、サポートされません。
  • net4.x、netstandard、netcoreapp、.NET 5.0+ などの非 Xamarin をターゲットとするアセンブリは問題なく動作します。
  • .NET 6 にアップグレードし、C# ネイティブの nint、nuint 型を明示的に使用したい場合は、System.nint と System.nuint を C# の nint と nuint に書き換えるコードの修正が必要となります。

以下の GitHub の issue もご確認することをお勧めします。
github.com
 
C# ネイティブの nint、nuint 型については以下を参照ください。
docs.microsoft.com
 
公式情報:
Announcing .NET MAUI Preview 11 - .NET Blog

 
 

.NET MAUIドキュメントの更新(.NET MAUI Preview 11)

アクセシビリティ、BlazorWebView、Border、GraphicsView、Maui.Graphics、Shadows、Splash Screen、マルチターゲット、プラットフォーム固有のコードの呼び出し方などが更新されています。
docs.microsoft.com


Xamarin.Formsのドキュメントは .NET MAUI に移植され更新作業中であり、今後定期的に公開される予定となっています。必要な .NET MAUI のドキュメントが見つからない場合は、Xamarin.Forms のドキュメントを確認してください。
docs.microsoft.com
 
公式情報:
Announcing .NET MAUI Preview 11 - .NET Blog