Dev Homeは、開発者向けのダッシュボードアプリです。
Dev Homeを使えば
などが行えます。
開発に必要なIDE、エディタ、SDK、ツールなどをまとめてインストールできます。
インストール済のものも検出できるので、開発チームで必要なアプリ一覧などを用意しておけば、あとは足りなものをここからインストールすればＯＫです。
残念なことに（？）Visual StudioをCommunityが候補にのっていますが、Enterpriseが入っていても「インストール済」と認定されない点です。このあたりはEdition関係なくVisual Studioと検出してくれるといいですね。
プレビュー版ですので、フィードバックしておくのがいいでしょう。
フィードバックボタンも左側のメニューアイコンにちゃんとありますね。
build.microsoft.com
まずはキーノート「Shaping the future of work with AI」から視聴開始です！
news.microsoft.com
今回のBuildの見どころがまとまった資料「Book of News」が公開されました。
その冒頭では次のように書かれています。
Microsoft Buildは、開発者のために設計されたイベントです。AIがテクノロジー分野の話題を独占している今、今年のイベントでAIが重要な役割を果たすことは理にかなっています。
こちらの日本語コンテンツですが英語コンテンツを自動翻訳した日本語訳とは異なっていますので、人による翻訳・もしくは監修が入ってそうですね。
Book of Newsによれば「Azure Cognitive Service for Language」の様々なところに「Azure OpenAI Service」による機能がはいってくるそうです。
すでにプレビュー中のものに加えて、私が注目したのは「開発者が要約をカスタマイズする機能」です。
さらに
一般提供開始を間近に控えたドキュメントと会話の要約は、すぐに使えるようになります。これにより、お客様は、Azure Service Level Agreementsやデータセキュリティなど、Azureのエンタープライズグレードの準備に支えられながら、ユースケースを本番環境で展開することができます。
とのことです。
要約機能はタイパ（タイムパフォーマンス）を向上させますから、これは提供が待ち遠しいですね。
春の祭典、Microsoft Buildが日本時間の5/24 1:00からはじまります。
この春はOpen AIなどが注目されたMicrosoftですが、Buildでどのような発表があるか楽しみですね。
build.microsoft.com
MAUIアプリは、１つのプロジェクトの中で画像などもプラットフォーム共通部分とプラットフォーム固有部分を分けて定義できます。
プラットフォーム共通部分は、プロジェクト直下にある「Resource\Images」フォルダに配置し、プラットフォーム固有部分については（例えばAndroidの場合）「Platfoems\Android\Resources\Drawable」フォルダに配置します。
Xamarin.FormsからMAUIに移植する作業であれば、「Platfoems\Android\Resources\Drawable」フォルダから「Resource\Images」フォルダに画像ファイルを移動することになります。
この画像ファイルの移動については、Visual Studioのソリューションエクスプローラで行いのではなく、ファイルエクスプローラを使ってファイルを移動させてください。理由は後程。
画像ファイル名は「英大文字」がつかえず「英小文字と_」のみになります。
よって、「ImageFolder.png」のようなファイル名は「image_folder.png」にする必要があります。
「Platfoems\Android\Resources\Drawable」フォルダの画像ファイルのビルドアクションは「AndroidResouce」です。
一方、プラットフォーム共通の「Resource\Images」フォルダに配置する画像ファイルは「MauiImage」です。
「AndroidResouce」のままだとビルド時にエラーになります。
このビルドアクションの変更ですが、ファイルエクスプローラーでファイルを移動した場合、Visual Studioが自動的に「MauiImage」のビルドアクションを設定してれます。ソリューションエクスプローラでやるとビルドアクションが維持されちゃうので注意してください。
前回は、.NET Upgrade Assistantを使って、Xamarin.Formsのアプリを.NET MAUI化してみました。
ソリューション構造は、Xamarin.Formsのままで.NET MAUI化ができましたが、できれば、.NET MAUIのソリューション構造にしておきたいですよね。
理由としては、まったくの私見であり経験則というほどのものでもないのですが、これだけソリューション構造が異なるとすると、将来的なことを考えると.NET MAUIのソリューション構造の形にしておいた方が良いのではないかと思うからです。
Visual Studioで「.NET MAUIアプリ」テンプレートを使って、新規アプリケーション作成を「MAUIApp」という名前で実施します。
フレームワークとしては「.NET 7.0」を選択します。
「.NET MAUIアプリ」テンプレートには、Android、iOS、MacOS、Tizen、WindowsOSの５つのプラットフォームが定義されています。
ソリューションの「Platforms」フォルダの下からも不要なプラットフォームのフォルダを削除します。
ビルドを開始しました...
1>------ ビルド開始: プロジェクト: MAUIApp, 構成: Debug Any CPU ------
1>MAUIApp -> C:\Sample\MAUIApp\MAUIApp\bin\Debug\net7.0-ios\iossimulator-x64\MAUIApp.dll
1>MAUIApp -> C:\Sample\MAUIApp\MAUIApp\bin\Debug\net7.0-android\MAUIApp.dll
========== ビルド: 成功 1、失敗 0、最新の状態 0、スキップ 0 ==========
========== ビルド は 10:28 AM に開始され、02:32.818 分 かかりました ==========
ここまでが移植するもの関係なく必要な共通作業となります。
それでは、「Xamarin.Formsアプリ」テンプレートで作成したソリューションから移植をしていきましょう。
Xamarin.Formsアプリの共通プロジェクト部分である「XamarinApp」部分については、.NET MAUIアプリではプロジェクトが１つになっていることもあって、下記の場所に配置されています。
Xamarinでは、App.xaml.csの中でメインページを指定していました。
.NET MAUIでは、AppShellを介してメインページを指定しています。
試しにApp.xaml.csで直接MainPageを指定しても正常に動作します。
AppShellには「TabBar」を定義してい複数の画面を切り替えるようなUIを作ることができます。
「FlyoutItem」を定義すればハンバーガーメニューとそこからの画面切り替えUIを作ることができます。
このあたりの画面遷移UIを採用しているのならば、AppShellは残しておいて、将来的にはXamarin.Formsでの実装方法からAppShellでの実装に変えていくと良いかもしれません。
今回は、そこまでは手を入れずにAppShellは残しておいてMainPageの指定にだけ使用しましょう。
Xamarin.Formsでも画面関連は、iOSとAndroidで基本同じ定義になるので共通プロジェクト側に入っています。
これをそのまま.NET MAUI側にコピーしていくのが基本ですがいくつか変更が必要です。
Xamarin.Formsの画面定義である拡張子がxamlのXAMLファイル関連の変更点としては名前空間の変更があります。
具体的には、Xamarin.Formsの名前空間「xmlns="http://xamarin.com/schemas/2014/forms"」→MAUIの名前空間「xmlns="http://schemas.microsoft.com/dotnet/2021/maui"」の置換が必要です。
Xamarin.Formsアプリをアップグレードしたときと異なり、開発者モードにした実機をUSB接続すればターゲットとして実機がでてきて、すぐにデバッグ実行できます。
なぜかSplashScreenに指定した画像が表示されませんが、それも、Visual Studioを繋げずに実機側でアプリを起動すればきちんと表示されます。
今回は非常にシンプルな（ほとんど何もしない）アプリでしたが、次回はMVVMで作成したXamarin.FomrsアプリからXAMLやロジックをコピーして、.NET MAUIアプリとして再構築を試したいと思います。
次回：
新規作成したXamarin.Formsのソリューション構造と、新規作成した.NET MAUIのソリューション構造が全く違うことを前回紹介しました。
今回は、新規作成したXamarin.Formsのソリューションを.NET MAUIに移行します。
今回紹介する方法は、 .NET Upgrade Assistantによる自動移行です。
learn.microsoft.com
dotnet tool install -g upgrade-assistant
upgrade-assistant upgrade .\XamarinApp.sln --non-interactive --entry-point *
実行すると、移行するための操作内容や結果がどんどん表示されますが、かなり作業としては多いようです。
時間もそれなりに時間を要しますので、時間的に余裕のある時に試すのがいいでしょう。
なお、オリジナルのソリューション構成は自動的にバックアップが作成されますので、その点は安心して実行できます。
.NET Upgrade Assistantを実行した結果を、実行前の状態と比較してます（Gitに事前にコミットしておいて実行後のファイルとの差分を検証）
Xamarin.Formsの画面定義である拡張子がxamlのXAMLファイル関連の変更点としては名前空間の変更があります。
具体的には、Xamarin.Formsの名前空間「xmlns="http://xamarin.com/schemas/2014/forms"」→MAUIの名前空間「xmlns="http://schemas.microsoft.com/dotnet/2021/maui"」の置換が必要です。
基本的には名前空間の変更だけで、画面定義部分であるXAMLの他の部分は変更がかかっておりません。
実際のアプリ開発用プロジェクトでは、それだけでは期待した表示が得られない可能性もありますが、まずは、MAUI上で動作するように変更するポイントはここだけのようです。
xamlファイルと対になるxaml.csファイルについても変更点は名前空間のみとなります。
usingのところで参照している「Xamarin」「Xamarin.Forms」を「Microsoft.Maui」「Microsoft.Maui.Controls」に変更します。
usingではなくコード本文中で「Xamarin.Forms.～」のように記載している部分があれば、そこも変更が必要です。
もともとXamarinで作成していたとしても、コード部分は.NET Frameworkと互換性があり、また、.NET Frameworkと.NET 6/7も基本的にコードの互換性はあるので、これだけシンプルな変更となっているのだと推測します。
移行で一番変更がかかるのがこのプロジェクトファイルです。
.NET Framework形式から.NET SDK形式にプロジェクトファイルの変更します。
不安になるくらい要素が削除されます。なぜこのようにシンプルになるのかの答えはlearnにありました。
learn.microsoft.com
.NET Framework プロジェクトとは異なり、既定値がほとんどの一般的なユース ケースに対応しているため、これらの項目をプロジェクト ファイルで指定する必要はありません。 この動作により、プロジェクト ファイルのサイズがより小さく、より簡単に理解できるようになり、必要に応じて手作業で編集できます。
.NET SDK形式のプロジェクトファイルにすることでこのような恩恵を得られるのでシンプルになるわけです。
.NET Upgrade Assistantだけで完結してくれたらよかったのですが、一部手動での変更が必要です。
AssemblyInfo.csの内容は、csproj側への記載（プロジェクトのプロパティ）に変更が必要です。
AssemblyInfo.csの内容をcsproj側に記載がおわったら、AssemblyInfo.cs自体は削除します。
こちらも.NET SDK契機にすることで不要になるので削除します。
Xamarin時代のMainActivity.csの基底クラスは「global::Xamarin.Forms.Platform.Android.FormsAppCompatActivity」でしたが、.NET MAUIにすると「MauiAppCompatActivity」となりますので、MainActivity.csを書き換えます。
OnCreateメソッドの中身も「base.OnCreate(savedInstanceState);」をのこしてFormsなどの初期化ロジックは削除します。
Androidプロジェクトに「MainApplication.cs」を追加します。
共通プロジェクト側に「MauiProgram.cs」を追加します。
実機実行が非常に大変でした。
アップグレードする前のXamarin.Formsのプロジェクトで実機実行できることを確認しておいたのですが、実行ターゲットに実機がでてこないのです。
<<<<<<調査継続中>>>>>>>
実際に実機で動くのかどうか。とりあえずは、adbを使ってapkファイルを実機転送して実行できるかを試してみましょう。
これができるのであれば、Visual Studio側の問題だと切り分けられます。
まずは、実機が接続されているか「adb devices」で確認します。
問題なく接続できていますね。
adbコマンドで実機転送できるのはapkファイルになります。releaseの生成物をaabではなくapkに変更する方法でもいいのですが、あとで戻し忘れそうなのでdebugで生成したapkを転送してみます。
ただし、debugビルドはファーストデプロイが有効で、ファーストデプロイが有効だとアーカイブ（apkファイル作成
）できないのでそこだけ変更します。
変更ができたら、ソリューションエキスプローラ―でAndroidプロジェクトを右クリックして「アーカイブ」を選択すればapkファイルが作成できます。
apkファイルに署名せずに実機転送しようとすると「INSTALL_PARSE_FAILED_NO_CERTIFICATES」のエラーが出力されるので、アーカイブマネージャーで、[配布]-[アドホック]で署名付きapkファイルを作成します。
adb -s L52A1ced3372 install com.companyname.xamarinapp.apk
実機でXamarinAppを実行すれば、無事に動作しました。
これであとは、Visual Studioで実機が認識されて実機転送デバックできる手順が分かれば、安心してアップグレードを想定して使い始められそうですね。
