はつねの日記

Kinect, Windows 10 UWP, Windows Azure, IoT, 電子工作

Dev Homeのプレビュー提供が始まりました!


Dev Homeは、開発者向けのダッシュボードアプリです。
Dev Homeを使えば

  • バイスのセットアップ
  • GitHubと連携してIssueやプルリクの確認・管理
  • Windows設定の最適化

などが行えます。

バイスのセットアップ

開発に必要なIDE、エディタ、SDK、ツールなどをまとめてインストールできます。

インストール済のものも検出できるので、開発チームで必要なアプリ一覧などを用意しておけば、あとは足りなものをここからインストールすればOKです。
残念なことに(?)Visual StudioをCommunityが候補にのっていますが、Enterpriseが入っていても「インストール済」と認定されない点です。このあたりはEdition関係なくVisual Studioと検出してくれるといいですね。
プレビュー版ですので、フィードバックしておくのがいいでしょう。
フィードバックボタンも左側のメニューアイコンにちゃんとありますね。

GitHubと連携してIssueやプルリクの確認・管理


このあたりがダッシュボードでみれると便利ですね。

Windows設定の最適化

Microsoft Build 2023 Book of Newsが公開されましたね

news.microsoft.com
今回のBuildの見どころがまとまった資料「Book of News」が公開されました。
その冒頭では次のように書かれています。

Microsoft Buildは、開発者のために設計されたイベントです。AIがテクノロジー分野の話題を独占している今、今年のイベントでAIが重要な役割を果たすことは理にかなっています。

こちらの日本語コンテンツですが英語コンテンツを自動翻訳した日本語訳とは異なっていますので、人による翻訳・もしくは監修が入ってそうですね。

Azure Cognitive Service for Language

Book of Newsによれば「Azure Cognitive Service for Language」の様々なところに「Azure OpenAI Service」による機能がはいってくるそうです。
すでにプレビュー中のものに加えて、私が注目したのは「開発者が要約をカスタマイズする機能」です。
さらに

一般提供開始を間近に控えたドキュメントと会話の要約は、すぐに使えるようになります。これにより、お客様は、Azure Service Level Agreementsやデータセキュリティなど、Azureのエンタープライズグレードの準備に支えられながら、ユースケースを本番環境で展開することができます。

とのことです。
要約機能はタイパ(タイムパフォーマンス)を向上させますから、これは提供が待ち遠しいですね。

ACS Translator plugin for Azure OpenAI Service

ACS=Azure Communication ServiceのプラグインとしてOpen AIを使った翻訳機能がプライベートプレビューとして提供されるようです。
まだ詳細は未確認ですが、Teamsの裏側のようなACSにこのプラグインがつくというのは多言語コミュニケーション通信アプリにとって非常に強力な翻訳機能がつけれることを意味しているかもですね。
learn.microsoft.com

Xamarin.FormsからMAUIへアプリ内画像を移植する

前回:
hatsune.hatenablog.jp

MAUIアプリは、1つのプロジェクトの中で画像などもプラットフォーム共通部分とプラットフォーム固有部分を分けて定義できます。

プラットフォーム共通部分は、プロジェクト直下にある「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」のビルドアクションを設定してれます。ソリューションエクスプローラでやるとビルドアクションが維持されちゃうので注意してください。

画像ファイルの指定方法の変更点

このように移動した前後でも画面定義体XAMLや、コード中での画像ファイルの参照は変更不要です。

もちろんファイル名をすべて小文字に変更する作業が発生したときは、ファイル名の小文字かだけは実施してください。

今回は以上になります。
せっかくMAUIにするのであれば、プラットフォーム固有は本当に必要な最小限にして共通部分に移植していきたいですね。

MAUIテンプレートを活用してXamarin.Formsアプリを移植してみよう

前回:
hatsune.hatenablog.jp

前回は、.NET Upgrade Assistantを使って、Xamarin.Formsのアプリを.NET MAUI化してみました。
ソリューション構造は、Xamarin.Formsのままで.NET MAUI化ができましたが、できれば、.NET MAUIのソリューション構造にしておきたいですよね。
理由としては、まったくの私見であり経験則というほどのものでもないのですが、これだけソリューション構造が異なるとすると、将来的なことを考えると.NET MAUIのソリューション構造の形にしておいた方が良いのではないかと思うからです。

.NET MAUIアプリを初期生成する

Visual Studioで「.NET MAUIアプリ」テンプレートを使って、新規アプリケーション作成を「MAUIApp」という名前で実施します。

フレームワークとしては「.NET 7.0」を選択します。

フレームワークを限定する

「.NET MAUIアプリ」テンプレートには、AndroidiOSMacOS、Tizen、WindowsOSの5つのプラットフォームが定義されています。

MAUI.appのTargetFrameworkを限定する

今回は、AndroidiOSのみが必要なので、MAUI.appのTargetFrameworkをAndroidiOSのみにします。
]

Platform定義の削除

ソリューションの「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 分 かかりました ==========

無事にiOSAndroidの2つがビルドできました。

移植を始めよう

ここまでが移植するもの関係なく必要な共通作業となります。
それでは、「Xamarin.Formsアプリ」テンプレートで作成したソリューションから移植をしていきましょう。

共通プロジェクト部分


Xamarin.Formsアプリの共通プロジェクト部分である「XamarinApp」部分については、.NET MAUIアプリではプロジェクトが1つになっていることもあって、下記の場所に配置されています。

App.xaml関連

Xamarinでは、App.xaml.csの中でメインページを指定していました。

.NET MAUIでは、AppShellを介してメインページを指定しています。

試しにApp.xaml.csで直接MainPageを指定しても正常に動作します。

AppShellの役目

AppShellには「TabBar」を定義してい複数の画面を切り替えるようなUIを作ることができます。
「FlyoutItem」を定義すればハンバーガーメニューとそこからの画面切り替えUIを作ることができます。
このあたりの画面遷移UIを採用しているのならば、AppShellは残しておいて、将来的にはXamarin.Formsでの実装方法からAppShellでの実装に変えていくと良いかもしれません。
今回は、そこまでは手を入れずにAppShellは残しておいてMainPageの指定にだけ使用しましょう。

画面の移植

Xamarin.Formsでも画面関連は、iOSAndroidで基本同じ定義になるので共通プロジェクト側に入っています。
これをそのまま.NET MAUI側にコピーしていくのが基本ですがいくつか変更が必要です。

XAMLファイル関連

Xamarin.Formsの画面定義である拡張子がxamlXAMLファイル関連の変更点としては名前空間の変更があります。
具体的には、Xamarin.Formsの名前空間「xmlns="http://xamarin.com/schemas/2014/forms"」→MAUIの名前空間「xmlns="http://schemas.microsoft.com/dotnet/2021/maui"」の置換が必要です。

XAML.csファイル関連

usingのところで参照している「Xamarin」「Xamarin.Forms」を「Microsoft.Maui」「Microsoft.Maui.Controls」に変更します。
usingではなくコード本文中で「Xamarin.Forms.~」のように記載している部分があれば、そこも変更が必要です。

Androidのリソースを移植する


.NET MAUIのプラットフォーム共通リソースについて

.NET MAUIはプロジェクトフォルダの直下に「Resources」フォルダがあって、ここにプラットフォーム共通の「アイコン」「起動時スプラッシュ」「文字フォント」「画像」などを格納できます。
Xamarin.Formsのときに共通プロジェクト側においてあるリソースがあれば、ここへの配置を考えてみると良いでしょう。
また、iOSAndroidで分けてリソース管理していたものも、移植を機会に共通化して定義の二度手間が省けるものは省いていくようにリファクタリングすることも計画すると良いかもしれません。

.NET MAUIのAndroid固有リソースについて

.NET MAUIでのAndroid固有リソースは、[Platforms]-[Android]-[Rrsoureces]フォルダにあります。
Xamarin.FormsでのAndroidプロジェクトの[Resouces]フォルダの中身を丸ごとコピーしてしまえば移植は完了です。

Androidの固有定義を移植する

AndroidManifest.xmlを移植する

Xamarin.FormsのAndroidプロジェクトの[Properties]フォルダにある「AndroidManifest.xml」ファイルを、.NET MAUIの[Platforms]-[Android]フォルダの下に上書きコピーします。

MainActivity.csを移植する

Xamarin.FormsのAndroidプロジェクトの「MainActivity.cs」ファイルは、を基底クラスとしているので、それを.NET MAUIの[Platforms]-[Android]フォルダの下に上書きコピーしてしまっては問題が発生します。

内容を抜粋して移植します。
このとき、Xamarin.FormsやEssentialsの初期化コード、LoadApplicationメソッドなどは削除します。

条件付きコンパイルシンボルの調整

MAUI.appにある[ビルド]-[全般]でビルド時のコンパイルシンボルを設定できます。
iOSについては「__IOS__」というシンボルが定義されているのですが、Androidについては「__DROID__」というシンボルが定義されていないので、追加します。

実機実行

Xamarin.Formsアプリをアップグレードしたときと異なり、開発者モードにした実機をUSB接続すればターゲットとして実機がでてきて、すぐにデバッグ実行できます。
なぜかSplashScreenに指定した画像が表示されませんが、それも、Visual Studioを繋げずに実機側でアプリを起動すればきちんと表示されます。

今回は非常にシンプルな(ほとんど何もしない)アプリでしたが、次回はMVVMで作成したXamarin.FomrsアプリからXAMLやロジックをコピーして、.NET MAUIアプリとして再構築を試したいと思います。

次回:

~Xamarin.FormsからMAUIへ~ .NET Upgrade Assistantを使って移行してみよう

前回:
hatsune.hatenablog.jp

新規作成したXamarin.Formsのソリューション構造と、新規作成した.NET MAUIのソリューション構造が全く違うことを前回紹介しました。
今回は、新規作成したXamarin.Formsのソリューションを.NET MAUIに移行します。

.NET Upgrade Assistantによる自動移行

今回紹介する方法は、 .NET Upgrade Assistantによる自動移行です。
learn.microsoft.com

.NET Upgrade Assistantのインストール

dotnet tool install -g upgrade-assistant

.NET Upgrade Assistantの実行

upgrade-assistant upgrade .\XamarinApp.sln --non-interactive --entry-point *

実行すると、移行するための操作内容や結果がどんどん表示されますが、かなり作業としては多いようです。
時間もそれなりに時間を要しますので、時間的に余裕のある時に試すのがいいでしょう。
なお、オリジナルのソリューション構成は自動的にバックアップが作成されますので、その点は安心して実行できます。

.NET Upgrade Assistantによる移行結果

.NET Upgrade Assistantを実行した結果を、実行前の状態と比較してます(Gitに事前にコミットしておいて実行後のファイルとの差分を検証)

XAMLファイル関連

Xamarin.Formsの画面定義である拡張子がxamlXAMLファイル関連の変更点としては名前空間の変更があります。

具体的には、Xamarin.Formsの名前空間「xmlns="http://xamarin.com/schemas/2014/forms"」→MAUIの名前空間「xmlns="http://schemas.microsoft.com/dotnet/2021/maui"」の置換が必要です。
基本的には名前空間の変更だけで、画面定義部分であるXAMLの他の部分は変更がかかっておりません。
実際のアプリ開発用プロジェクトでは、それだけでは期待した表示が得られない可能性もありますが、まずは、MAUI上で動作するように変更するポイントはここだけのようです。

XAMLC#部分関連

xamlファイルと対になるxaml.csファイルについても変更点は名前空間のみとなります。

usingのところで参照している「Xamarin」「Xamarin.Forms」を「Microsoft.Maui」「Microsoft.Maui.Controls」に変更します。
usingではなくコード本文中で「Xamarin.Forms.~」のように記載している部分があれば、そこも変更が必要です。
もともとXamarinで作成していたとしても、コード部分は.NET Frameworkと互換性があり、また、.NET Frameworkと.NET 6/7も基本的にコードの互換性はあるので、これだけシンプルな変更となっているのだと推測します。

csproj(プロジェクトファイル)のアップグレード

移行で一番変更がかかるのがこのプロジェクトファイルです。
.NET Framework形式から.NET SDK形式にプロジェクトファイルの変更します。

不安になるくらい要素が削除されます。なぜこのようにシンプルになるのかの答えはlearnにありました。
learn.microsoft.com

.NET Framework プロジェクトとは異なり、既定値がほとんどの一般的なユース ケースに対応しているため、これらの項目をプロジェクト ファイルで指定する必要はありません。 この動作により、プロジェクト ファイルのサイズがより小さく、より簡単に理解できるようになり、必要に応じて手作業で編集できます。

.NET SDK形式のプロジェクトファイルにすることでこのような恩恵を得られるのでシンプルになるわけです。

手動変更

.NET Upgrade Assistantだけで完結してくれたらよかったのですが、一部手動での変更が必要です。

AssemblyInfo.csの削除

AssemblyInfo.csの内容は、csproj側への記載(プロジェクトのプロパティ)に変更が必要です。
AssemblyInfo.csの内容をcsproj側に記載がおわったら、AssemblyInfo.cs自体は削除します。

Resource.designer.csの削除


こちらも.NET SDK契機にすることで不要になるので削除します。

MainActivity.csの変更

Xamarin時代のMainActivity.csの基底クラスは「global::Xamarin.Forms.Platform.Android.FormsAppCompatActivity」でしたが、.NET MAUIにすると「MauiAppCompatActivity」となりますので、MainActivity.csを書き換えます。
OnCreateメソッドの中身も「base.OnCreate(savedInstanceState);」をのこしてFormsなどの初期化ロジックは削除します。

MainApplication.csの追加

Androidプロジェクトに「MainApplication.cs」を追加します。

MauiProgram.csの追加

共通プロジェクト側に「MauiProgram.cs」を追加します。

実機実行

実機実行が非常に大変でした。
アップグレードする前のXamarin.Formsのプロジェクトで実機実行できることを確認しておいたのですが、実行ターゲットに実機がでてこないのです。

<<<<<<調査継続中>>>>>>>

adbコマンドで実機転送して確認

実際に実機で動くのかどうか。とりあえずは、adbを使ってapkファイルを実機転送して実行できるかを試してみましょう。
これができるのであれば、Visual Studio側の問題だと切り分けられます。

実機接続確認

まずは、実機が接続されているか「adb devices」で確認します。

問題なく接続できていますね。

apkファイル作成

adbコマンドで実機転送できるのはapkファイルになります。releaseの生成物をaabではなくapkに変更する方法でもいいのですが、あとで戻し忘れそうなのでdebugで生成したapkを転送してみます。
ただし、debugビルドはファーストデプロイが有効で、ファーストデプロイが有効だとアーカイブ(apkファイル作成
)できないのでそこだけ変更します。

変更ができたら、ソリューションエキスプローラ―でAndroidプロジェクトを右クリックして「アーカイブ」を選択すればapkファイルが作成できます。

apkファイルに署名

apkファイルに署名せずに実機転送しようとすると「INSTALL_PARSE_FAILED_NO_CERTIFICATES」のエラーが出力されるので、アーカイブマネージャーで、[配布]-[アドホック]で署名付きapkファイルを作成します。

apkファイルを実機転送

adb -s L52A1ced3372 install com.companyname.xamarinapp.apk


実機実行

実機でXamarinAppを実行すれば、無事に動作しました。
これであとは、Visual Studioで実機が認識されて実機転送デバックできる手順が分かれば、安心してアップグレードを想定して使い始められそうですね。