個人的なメモ

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

.NET 6 の Scatter/Gather IO の効果を Visual Studio for Mac 2022 Preview 1 on M1 Mac で試してみましたが、まだ、闇が深かったです(訂正済)

2021/10/05 22:40 検証方法に間違いがあったため(VS for Macデバッグありの実行になっていました)、再度検証し直し記事も訂正しております。ご指摘ありがとうございました。
 
 

はじめに

.NET 6 では FileStream がほぼ完全に書き直されており、速度と信頼性のが高まりました。また、複数のバッファーに対応した(Scatter / Gather IO)新しい API が導入されています。Scatter / Gather IO を使用すると、単一の sys-call で複数のバッファーを渡すことにより、高コストの sys-call の数を減らすことができます。
 
devblogs.microsoft.com
 
 

Visual Studio for Mac 2022 Preview 1 on M1 Mac で試したら...

WindowsLinux でのベンチマーク結果は公式ブログにデータがありましたので、Mac ではどのような結果になるか試してみました。
 
公式ブログの記事内のコードから、サンプルプロジェクトを作成しました。
github.com
 
ベンチマークのライブラリは、BenchmarkDotNet を利用しているようなので、同じように構成しました。
github.com
 
Visual Studio for Mac 2022 Preview 1 で実行した結果ですが...

// * Summary *

BenchmarkDotNet=v0.13.1, OS=macOS Big Sur 11.6 (20G165) [Darwin 20.6.0]
Apple M1 2.40GHz, 1 CPU, 8 logical and 8 physical cores
.NET SDK=6.0.100-rc.1.21463.6
  [Host]     : .NET 6.0.0 (6.0.21.45113), X64 RyuJIT
  DefaultJob : .NET 6.0.0 (6.0.21.45113), X64 RyuJIT


|      Method |     Mean |    Error |   StdDev |
|------------ |----------|----------|----------|
|       Write | 47.92 ms | 1.109 ms | 3.271 ms |
| WriteGather | 48.51 ms | 1.567 ms | 4.621 ms |

 
なんと上記の通り、WriteGather()の方が遅いという結果となりました...
 
 

ベクトル化 IO がうまく機能していない

詳細を解析していないのでなんとも言えないですが、公式ブログでは、Linux ではベクトル化 IO が機能しているとのことでしたが、Mac ではなんらかの理由でうまくベクトル化 IO が機能していない感じです。

一応、.NET 6 と Darwin のソースを調べてみましたが、pwritev() はサポートしているようですが、ベクトル化 IO がうまく機能していない詳細な原因まではわかりませんでした。
 
...と、いったんは思ったのですが、よく見ると、ベンチマーク結果が、X64 となっているので、Rosetta 2 による変換が入っているのが気になります。

ちなみに、意識せず x64 版がインストールされていたのは、dotnet-maui-check でインストールしたからでした。
 
 

Arm64 版 SDK をインストールして再度チャレンジ

というわけで、.NET 6 RC1 SDK をいったん全て削除して、再度 Arm64 版 SDK をインストールして Visual Studio for Mac 2022 Preview 1 で再度試したところ、今度は、無事成功しました。しかも、WriteGather()の方が速く、ベクトル化 IO も効果を発揮しています。

// * Summary *

BenchmarkDotNet=v0.13.1, OS=macOS Big Sur 11.6 (20G165) [Darwin 20.6.0]
Apple M1, 1 CPU, 8 logical and 8 physical cores
.NET SDK=6.0.100-rc.1.21463.6
  [Host]     : .NET 6.0.0 (6.0.21.45113), Arm64 RyuJIT
  DefaultJob : .NET 6.0.0 (6.0.21.45113), Arm64 RyuJIT


|      Method |     Mean |    Error |   StdDev |
|------------ |----------|----------|----------|
|       Write | 45.11 ms | 0.950 ms | 2.772 ms |
| WriteGather | 40.23 ms | 1.304 ms | 3.844 ms |

 
 

今回得た知見

今回の検証で以下のような知見を得ました。

  • M1 Mac .NET 6 の、Scatter/Gather IO は Arm64 版 でしか有効にならない。x64 版では効果がない。
  • M1 Mac .NET 6 SDK の、x64, Arm64 を両方インストールした場合、同じ場所に配置され、後にインストールした方が有効となる。side by side にはならない。
  • M1 Mac .NET 6 SDK の、x64, Arm64 を切り替えたい場合、念のため SDK をいったん削除してから再インストールした方が無難そう。
  • M1 MacVisual Studio for Mac 2022 Preview 1 では Arm64 版 SDK でのデバッグ実行がまだ正常動作しない。x64 版 SDK/Rosetta 2 ならデバッグ実行できる。

 
というわけで、Visual Studio for Mac 2022 の今後のリリースに期待します。

Visual Studio 2022 for Mac Preview 1 がリリースされましたので状況を確認してみました。

.NET 6 の GA まであと1ヶ月ちょっとのタイミングでようやく、Visual Studio 2022 for Mac Preview 1 がリリースされました。
devblogs.microsoft.com
 

UI が ネイティブの macOS UI で書き直されました。

これが Visual Studio 2022 for Mac の一番大きなトピックです。この件に工数がかかってしまい、他の件は手がまわりきらなかった感があります。見た目の違いは下記の通りです。色味が若干変わっており、視認性が良くなっています。
 
Xamarin の創設者 @migueldeicaza によると、Gtk+ から AppKit に書き直され C# / Xamarin.Mac で開発されているようです。


 

Visual Studio 2022 Visual Studio 2019
f:id:hiro128:20211003155331p:plain f:id:hiro128:20211003155724p:plain

 
その他、クラッシュの軽減とレスポンスが改善しているとのことです。

  • クラッシュの軽減については、長時間使用していないので体感できませんでした。
  • レスポンスの改善については、MacBook Air (M1, 2020) 上で大きな差ではないですが確かにもたつかなくなったという感覚はあります。

 
 

Windows 版に準じた Git の UI が適用されました

自分は、Git の操作はコマンドで行っているので、実際の画面を見てみてもよくわかりませんでしたが、Git のUI が Windows 版に近づいたそうです。確かにコードの変更箇所は見やすくなりました。
 
 

.NET 6 と C#10 への対応

例えば、Visual Studio 2019 for Mac では、.NET 6 RC1 を導入してもエラーが出てしまっていた以下の Minimal API のサンプルが動作するようになりました。
github.com
 

Visual Studio 2022 Visual Studio 2019
f:id:hiro128:20211003163745p:plain f:id:hiro128:20211003163809p:plain

 
 

SDK スタイルの Xamarin プロジェクトはまだ利用できません

下記のように、公式ブログに記載がある通り、SDK スタイルの iOS, Android プロジェクトはサポートされていません。.
 

Visual Studio for Mac continues to support web and cloud development with .NET Core 3.1 and later, mobile dev with Xamarin Traditional projects, and game development using Unity.

 
.NET 6 GA まであと1ヶ月強という状況と後述する MAUI の GA の情報から予想するに .NET 6 GA のタイミングでは、.NET 6 の iOS, Android のワークロードはサポートされず、これまでの非 SDK スタイルの従来の Xamarin.iOS, Xamarin.Android プロジェクトのサポートに留まる可能性が高そうですが、なんとかリリースされることを期待したい思いです。
 
なお、試しに既存の非 SDK スタイルの Xamarin.iOS プロジェクトを開いて、編集、デバッグしてみましたが、問題なく利用できました。
 
したがって、net6.0-android, net6.0-ios といった TFM が利用できるのも、もう少し先になりそうです。
 
 

.NET MAUI の GA は 2022 Q2 に延期されました。

2020年5月の公式ブログでは、以下のように

  • 2020年 Q4 から 2021年 Q3 までプレビュー
  • RC 2021年9月
  • GA 2021年11月

という予定でしたが 2022 Q2 延期になったようです。
devblogs.microsoft.com
 
 

まとめ

Preview 1 の状況をまとめると以下のような状況です。(実際に動作確認した結果です)

ワークロード 対応状況
コンソールアプリ
ASP.NET
Xamarin.iOS
Xamarin.Android
.NET 6 iOS
.NET 6 Android
.NET 6 Mac Catalyst
MAUI

 
まだ Preview 1 ですのでこれから新たな機能がリリースされると思います。次のプレビューを期待して待ちます。

.NET 6 Preview 4 以降で ASP.NET Core プロジェクトを作成するとデフォルトの起動プロファイルが Kestrel になります

.NET 6 Preview 4 以降で ASP.NET Core プロジェクトを作成するとデフォルトの起動プロファイルが Kestrel になります。
devblogs.microsoft.com
 
 
以下のように、デフォルトの起動プロファイルと、プロファイルの並び順に違いがあります。

   .NET 5 (VS2019)       .NET 6 (VS2022 Preview)    
f:id:hiro128:20210928022256p:plain f:id:hiro128:20210928022309p:plain

 
デフォルトの起動プロファイルは、単純に、[AppName].csproj.user の ActiveDebugProfile の値で決まりますので、.NET 5 でも値を修正すれば デフォルトの起動プロファイルが Kestrel になります。

Kestrel の方が軽いですし、クロスプラットフォームなので、既存の .NET 5 のプロジェクトでも デフォルトの起動プロファイルを Kestrel に変更したい場合もあると思います。
 

.NET 5 の例

WebApp2019.csproj.user 初期値(IIS Express デフォルト)
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="Current" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <DebuggerFlavor>ProjectDebugger</DebuggerFlavor>
  </PropertyGroup>
  <PropertyGroup>
    <ActiveDebugProfile>IIS Express</ActiveDebugProfile>
  </PropertyGroup>
</Project>

 
f:id:hiro128:20210929004743p:plain
 
 

WebApp2019.csproj.user 変更後(Kestrel デフォルト)
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="Current" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|AnyCPU'">
    <DebuggerFlavor>ProjectDebugger</DebuggerFlavor>
  </PropertyGroup>
  <PropertyGroup>
    <ActiveDebugProfile>WebApp2019</ActiveDebugProfile>
  </PropertyGroup>
</Project>

 
起動プロファイルが Kestrel に変更されました。
f:id:hiro128:20210929005311p:plain
 
 
 
起動プロファイルの並び順については、[AppName]\Properties\launchSettings.json 内の記載順で決まりますので、こちらも順番を入れ替えれば、 Kestrel, IIS Express, WSL の並び順を自由に入れ替えできます。
 
 

launchSettings.json 初期値(IIS Express が最初に記載されている)
{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:27769",
      "sslPort": 44341
    }
  },
  "$schema": "http://json.schemastore.org/launchsettings.json",
  "profiles": {
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "launchUrl": "swagger",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "WebApp2019": {
      "commandName": "Project",
      "launchBrowser": true,
      "launchUrl": "swagger",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "dotnetRunMessages": "true",
      "applicationUrl": "https://localhost:5001;http://localhost:5000"
    },
    "WSL": {
      "commandName": "WSL2",
      "launchBrowser": true,
      "launchUrl": "https://localhost:5001/swagger",
      "environmentVariables": {
        "ASPNETCORE_URLS": "https://localhost:5001;http://localhost:5000",
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "distributionName": ""
    }
  }
}

 
JSON の記載順通り IIS Express , WebApp2019(Kestrel) , WSL の順番になります。
f:id:hiro128:20210929005331p:plain
 
 

launchSettings.json 順番入れ替え済み(Kestrel が最初に記載されている)
{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:27769",
      "sslPort": 44341
    }
  },
  "$schema": "http://json.schemastore.org/launchsettings.json",
  "profiles": {
    "WebApp2019": {
      "commandName": "Project",
      "launchBrowser": true,
      "launchUrl": "swagger",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "dotnetRunMessages": "true",
      "applicationUrl": "https://localhost:5001;http://localhost:5000"
    },
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "launchUrl": "swagger",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "WSL": {
      "commandName": "WSL2",
      "launchBrowser": true,
      "launchUrl": "https://localhost:5001/swagger",
      "environmentVariables": {
        "ASPNETCORE_URLS": "https://localhost:5001;http://localhost:5000",
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "distributionName": ""
    }
  }
}

 
こちらも、入れ替えた JSON の記載順通り WebApp2019(Kestrel) , IIS Express , WSL の順番になります。
f:id:hiro128:20210929005347p:plain
 
 
小技ですが、必要になったときに結構忘れたりしますので、備忘録として残しておきました。

Minimal Web API のサンプルコードを作ってみました。

はじめに

Build 2021 のセッション
.NET 6 deep dive; what's new and what's coming | OD485
 
www.youtube.com

 
などで紹介された Minimal Web API について、セッション内でコードの一部は画面で見ることができましたが、公式のサンプルコードの紹介はありませんでした。
 
具体的などのようなコードになるかを確認するために、.NET6 RC1 でサンプルコードを作成しました。
github.com

 
 

プロジェクト

MinimalWebAPISample

Minimal Web API のサンプルです。
f:id:hiro128:20210921234213p:plain
 
Startup.cs も、Controllers も不要で、Program.cs のみで動く
 
Program.cs

using System;
using System.Linq;
using Microsoft.AspNetCore.Builder;
using Microsoft.AspNetCore.Http;

string[] Summaries = new[]
{
    "Freezing", "Bracing", "Chilly", "Cool", "Mild", "Warm", "Balmy", "Hot", "Sweltering", "Scorching"
};

var rng = new Random();

var app = WebApplication.Create(args);
app.MapGet("/", () => "Hello World!");
app.MapGet("/plant", () => new { Name = "cactus" });
app.MapGet("/weatherforecast", () =>
    Enumerable.Range(1, 5).Select(index => new WeatherForecast
    {
        Date = DateTime.Now.AddDays(index),
        TemperatureC = rng.Next(-20, 55),
        Summary = Summaries[rng.Next(Summaries.Length)]
    }).ToArray()
);
await app.RunAsync();

public class WeatherForecast
{
    public DateTime Date { get; set; }
    public int TemperatureC { get; set; }
    public int TemperatureF => 32 + (int)(TemperatureC / 0.5556);
    public string Summary { get; set; }
}

 

MVCWebAPISample

従来からある ASP.NET Core Web API のサンプルです。
f:id:hiro128:20210921234233p:plain
 
長いのでコードは省略しますが、Startup.cs 、Controllers、Program.cs とお作法が多いです。
 
両者は同じ結果を返す API になっていますので、MVCWebAPISample と比べて Minimal Web API でどれだけコードが少なくなるかを確認できます。
 
 

注意点

Minimal Web API のコードは、セッションの内容と .NET6 RC1 SDK を調査した結果から独自に作成したコードですので、正式リリースの .NET6 では動作しなかったり、違うコードになる可能性があります。
 
 

System Requirements

以下の Windows, に対応した Visual Studio 2022 Preview 最新版と .NET 6 SDK RC1 をインストールしてください。Visual Studio 2019 では動作しません。なお、Windows では Visual Studio 2022 PreviewVisual Studio 2019 はサイドバイサイドで動作し、共存可能です。
 

APIのエンドポイント(Minimal Web API, ASP.NET Core Web API 共通)

エンドポイント メソッド レスポンス
/ Get "Hello World!"文字列を固定で返却 f:id:hiro128:20210921235422p:plain
/plant Get レスポンス:植物名(サボテン)のオブジェクト(JSON)を固定で返却 f:id:hiro128:20210921235436p:plain
/weatherforecast Get ランダムな天候を表すオブジェクトのリスト(JSON)を返却 f:id:hiro128:20210921235447p:plain

 
 

まとめ

Minimal Web API のコードは Program.cs ファイルにすべてが記述できており、特に行数が少なくなるようなことはしておりませんが、30行以内に収まっています。
 
ASP.NET Core Web API のコードと比較すると直感的にわかりやすく、簡単な Mock API やシンプルな API を作成するシナリオに利用できそうです。
 

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

.NET 6 もとうとう RC1 がリリースされました。Preview1 から Preview7 まで段階的に情報や新機能がリリースされており、まとまった情報がないのでちょっと整理してみました。
  
内容が多いため、記事は随時更新中です。
  

  

NETプラットフォームの統合

Xamarin の一部である AndroidiOS、および macOS の 機能の統合が完了します。
devblogs.microsoft.com
  

サポート

.NET 6は2021年11月にリリースされ、LTSリリースとして3年間サポートされます(2024年11月まで)。
github.com
  

対応プラットフォーム

動作プラットフォームが追加され以下のようになりました。

   既存対応        新規対応    
Windows x86, x64 Arm64
Linux Arm32, Arm32 Alpine, Arm64, Arm64 Alpine, x64, x64 Alpine
Android x64, Arm32, Arm64
iOS x64(シミュレータ), Arm32, Arm64
Mac macOS x64, Arm64, MacCatalyst

  
詳細は以下をご覧ください。
github.com
 
 

.NET 6 のターゲットフレームワークモニカ(TFM)

新しいプラットフォームのサポートの追加で、TFM が追加されています。
TFM は csproj ファイルの TargetFramework セクションに記載します。

<TargetFramework>net6.0</TargetFramework>


.NET 6 にはOS固有のバインディングを含む以下の TFM があります。

devblogs.microsoft.com
  

SDKワークロード

TFMが、主要な機能とオプションの組み合わせで表現されることに合わせて、SDK自体も主要な機能と各ワークロードのオプションに分割されています。.NET 6 では新たに追加された、.NET MAUI、AndroidiOS、WebAssembly が別のワークロードとして用意されています。これは、これまでのような、すべての機能を含むモノリシック SDK では、ビルド時間長くなり、配布サイズも大きくなってしまうからです。
  
詳細は以下をご覧ください。
devblogs.microsoft.com

  
dotnet workload list コマンドを実行すると、以下のようにインストールされているすべてのワークロードが一覧表示されます。
docs.microsoft.com
 

Installed Workload Ids
----------------------
android-aot
ios
maccatalyst
macos
maui
tvos
wasm-tools

 
.NET 7 では、ASP.NETWindows デスクトップなどのコンポーネントもオプションにする予定となっています。(例えば net7.0-aspnet のような TFM が追加されるということになると予想されます。)
  

パフォーマンスの向上

.NET 6 ではランタイムに対する多数のパフォーマンス改善が行われています。ライブラリ開発者の方には詳細を理解することがとても有効ですが、アプリ開発者の場合、.NET6 をターゲットフレームワークにすれば自動的にパフォーマンスが改善するものも多いので、一旦は特に意識せずに利用できます。

具体的にどのような手法でパフォーマンスを改善しているかをイメージするために、JITコンパイラの「インライン化による最適化」の例を簡単にご紹介します。
  

JIT(ジャストインタイムコンパイラ)の改善

例えば、改善項目の一つである「インライン化による最適化」は、コンパイラがメソッドの呼び出し先からコードを取得し、それを呼び出し元に直接出力するプロセスです。これにより、メソッド呼び出しのオーバーヘッドが回避され、例えば、呼び出し先のコンテンツを呼び出し元のコンテキストに公開し、メソッド呼び出しを操作全体を定数に変換できます。

ただし、インライン化を行うとすべての呼び出し元に呼び出し先の結果のコードがコピーされるため、アセンブリコードのサイズが肥大しまい、場合によってはCPUのキャッシュメモリからあふれてしまい、かえって速度が低下します。それを最適化するために、インライン化するかどうかの判断を厳密に行うように改善し、パフォーマンスを向上させています。

.NET 6 ではこのような地道なパフォーマンス改善を多数実施されています。詳細は以下のリンクを参照してください

参考情報:Performance Improvements in .NET 6
devblogs.microsoft.com
  

ファイルIOの改善

.NET 6 では FileStream がほぼ完全に書き直されており、速度と信頼性のが高まりました。また、複数のバッファーに対応した(Scatter / Gather IO)新しい API が導入されています。Scatter / Gather IO を使用すると、単一の sys-call で複数のバッファーを渡すことにより、高コストの sys-call の数を減らすことができます。
 
関連記事 
hiro128.hatenablog.jp
  
  

FileStreamを使用しない、ファイルの読み取りと書き込み

.NET 6には、FileStreamを使用せずにファイルの読み取りと書き込みを可能にする新しい低レベルAPIが追加されています。

devblogs.microsoft.com
  

Silverlight は不滅でした... OpenSilver を試してみました。

Silverlightプラグイン不要のオープンソース再実装 OpneSilver のベータ版がリリースされたというニュースを見ましたので、昔 Silverlight を使っていた身としては「触ってみなければ」と思い、さっそく試してみました。
opensilver.net

Silverlightは、すでに Chrome、Edge、Safari などの最新のブラウザでは、プラグインもインストールできず、動作もしませんが、OpneSilver は見た目は酷似していますが中身は HTML5、CSS3、WebAssembly などの現在の Web 標準のテクノロジーで動作していますのでプラグインのインストールも不要ですし、最新のブラウザ上でも動作します。

なお、実装が全く違うので、xap ファイルを直接動作はできず、ソースコードからの再コンパイルが必要になります。

インストールは簡単です、トップページから VISX をダウンロードしてインストールするだけです。
f:id:hiro128:20210918182347p:plain

公式の Getting-started もあります。
doc.opensilver.net



インストールすると、OpenSilver のプロジェクトが作成できるようになります。


OpenSilver Application を選択します。
f:id:hiro128:20210918182458p:plain


雑に、Hello World を作ってみると…

細かいところは確認できていませんが、一応動きました。
f:id:hiro128:20210918182408g:plain


Silverlight は不滅ですね!みなさん、安心してこれからもSilverlight を使い続けましょう(嘘)


ちなみに何のためにこんなプロダクトを開発したのかな~と思いサイトをよく見てみると、
以下にある通りSilverlight のアプリのマイグレーションを請け負うビジネスモデルのようですね。
opensilver.net


なかなかおもしろいですね。もう少しいじってみようと思います。

Apple M1 Mac 上の Visual Studio for Mac で Xamarinはどれくらい使えるか調べました。(2020/12/13時点)

はじめに


こんにちは、@hiro128_777です。
 
この記事は「Xamarin Advent Calendar 2020」の13日目になります。
 
Apple M1 Mac が発売されて1ヶ月になりますね。というわけで、macOS Big Sur (Apple M1) 上の、Visual Studio for Mac で Xamarin がどれくらい使えるか再度確認してみました。
 
ちなみに、11/23 時点での状況こちらとなっております。
hiro128.hatenablog.jp


バージョン

 
Xcode は Universal App です。
f:id:hiro128:20201123213941p:plain

Visual Studio はまだ Intel App で Rosetta2 を介しての動作となります。
f:id:hiro128:20201213140416p:plain
 

Visual Studio for Mac のインストールと起動

 
インストールと起動は全く問題ありません。当該の Mac 上で、 なお、Rosetta 2 を利用するアプリの起動が初めての場合は、Rosetta 2 のインストールが走ります。
 

アプリごとの動作のまとめ

 

SDK 認識・コード編集 エミュレーター
デバッグ実行
実機
デバッグ実行
Xamarin Profiler
エミュレーター
Xamarin Profiler
実機
備考
iOS ○ OK ○ OK ○ OK ○ OK ○ OK  
Android ○ OK △ 一応動作 ○ OK ○ OK ○ OK エミュレーターはプレビュー版で動作
macOS ○ OK --------------- ○ OK --------------- ○ OK Intel App としてビルドされ、
Universal App としてビルドできない

 
結論から言うと、発売直後の状況より改善があります。
以下詳細となります。
  

iOS アプリ

 

SDK 認識・コード編集

問題ありません。
 

ビルド・デバッグ実行(シミュレータ)

問題ありません。
 

ビルド・デバッグ実行(実機)

問題ありません。
 
11/23 時点では iOS で実機にデプロイ時にプロビジョニングプロファイルの設定が不完全な時、1度だけ Visual Studio for Mac がクラッシュする現象が発生しましたが、それが起こらなくなりました。ですが、たまたま起こらなかったのか改善されたのかは不明です。
 

Xamarin Profiler(シミュレータ)

問題ありません。
 

Xamarin Profiler(実機)

問題ありません。
 

Android アプリ

 

SDK 認識・コード編集

問題ありません。
 

ビルド・デバッグ実行(エミュレータ

11/23 時点では、エミュレータが起動できず実行できませんでしたが、プレビューですが、Google からApple M1 で動作するエミュレーターがリリースされており、そちらででエミュレーター上のデバッグが可能となりました。

エミュレータは以下からダウンロードしてインストールできます。
github.com

 
起動すると、Visual Studio for Mac で認識します。
f:id:hiro128:20201213141145p:plain
f:id:hiro128:20201213141455p:plain

 
なお、プロジェクトオプションで「迅速なアセンブリの配置」を外さないと、デプロイでエラーが出ました。
f:id:hiro128:20201213140940p:plain
 
プレビュー版で試したら発生しませんでしたので、以下の issue のようです。
github.com

 

ビルド・デバッグ実行(実機)

問題ありません。
 

Xamarin Profiler(シミュレータ)

問題ありません。
 

Xamarin Profiler(実機)

問題ありません。
 

mac アプリ

 

SDK 認識・コード編集

問題ありません。
 

ビルド・デバッグ実行(実機)

 
こちらは状況が変わらず、ビルド、デバッグ実行できますが、Universal App としてビルドさせる設定が見つからず、結果として、Intel App としてビルドされ、Universal App としてはビルドできません。
f:id:hiro128:20201123215611p:plain
 

Xamarin Profiler(実機)

問題ありません。
 

まとめ

というわけで、再度の検証では、Apple M1 Mac 発売直後より状況が改善され、動くには動くという状況にはなりました。少なくとも実機での動作は問題なくなっていますので、実機デバッグのみで開発するのであれば問題ない感じです。エミュレーターも使う場合には、もう少し待てば、Android でも問題なく使えるようになりそうです。
 
なお、速度的には全く遅いとは感じませんでした。あとは、Visual Studio for Mac が M1 ネイティブで動くようになると嬉しいのですが、情報が全く無くどこまで開発が進んでいるのかもわかりません。Xamarin 後継の .NET MAUI は Visual Studio Code をサポートするとアナウンスされていますので、MAUI リリースまで Rosetta 2 で引っ張って、Visual Studio for Mac は廃止で Visual Studio Code に移行というような事態にならないかがとても心配です。
 
早く Visual Studio for Mac を M1 ネイティブ対応にしていただけると助かります。
 
今回は以上です。