デスクトップアプリの移植ガイダンス

ほとんどのアプリケーションコードは、次のいずれかの領域に分類できます。

C# (または Visual Basic.NET) で記述された Windows フォームおよび WPF アプリケーションの場合、ビジネスロジック、ローカルデータアクセス、Web サービスコードの驚くべき量をプラットフォーム間で共有できます。

.NET Portability Analyzer

Visual Studio 2017 以降では、既存のアプリケーションを調べて、他のプラットフォームに "そのまま" 移植できるコードの量を示す .NET Portability Analyzer (Windows 版のダウンロード) がサポートされています。

GitHub の Portability Analyzer をダウンロードして同じレポートを提供するために使用できるコマンドラインツールもあります。

アナライザーでコードの大きな部分が移植可能と示される可能性がありますが、どのようなアプリにも他のプラットフォームに移動できない部分が確実に存在します。

コードのさまざまなチャンクは、おそらく次のいずれかに分類されます。これらについては後で詳しく説明します。

すべてのプラットフォームで使用できる API に対して記述された .NET コードは、変更せずにクロスプラットフォームにできます。理想的には、このコードをすべてポータブルクラスライブラリ、共有ライブラリ、または .NET 標準ライブラリに移動し、既存のアプリ内でそれをテストできます。

その共有ライブラリを、他のプラットフォーム (Android、iOS、macOS など) のアプリケーションプロジェクトに追加できます。

一部の .NET API は、すべてのプラットフォームでは使用できない場合があります。このような API がコードに存在する場合、クロスプラットフォーム API を使うには、それらのセクションを書き直す必要があります。

そのようなものの使用例であるリフレクション API は、.NET 4.6 では使用できますが、すべてのプラットフォームで使用できるわけではありません。

移植可能な API を使ってコードを書き直したら、そのコードを共有ライブラリにパッケージ化して、既存のアプリ内でテストできるはずです。

おそらくクロスプラットフォームにできないコードの例を次に示します。

ユーザーインターフェイス - Windows フォームまたは WPF の画面は、たとえば Android や iOS のプロジェクトでは使用できません。このコントロールの比較を参考にして、ユーザーインターフェイスを書き直す必要があります。
プラットフォーム固有のストレージ - プラットフォーム固有のテクノロジ (ローカル SQL Server Express データベースなど) に依存するコード。これは、クロスプラットフォームの代替手段 (データベースエンジン用の SQLite など) を使って書き直す必要があります。 UWP には Android や iOS と若干異なる API があるため (たとえば、大文字と小文字が区別されるファイルシステムと、されないファイルシステム)、一部のファイルシステム操作も調整が必要な場合があります。
サードパーティ製コンポーネント – アプリケーションのサードパーティ製コンポーネントが他のプラットフォームで使用できるかどうかを確認します。ビジュアルではない NuGet パッケージのように利用できるものもありますが、他のものはできません (特に、グラフなどのビジュアルコントロールやメディアプレーヤー)