iOS 用 Xamarin アプリのビルド
重要
Visual Studio App Center は、2025 年 3 月 31 日に廃止される予定です。 完全に廃止されるまで Visual Studio App Center を引き続き使用できますが、移行を検討できる推奨される代替手段がいくつかあります。
注意
サポートされているバージョンと要件 App Center では、ポータブル クラス ライブラリ (PCL) および .NET Standard プロジェクトがサポートされています。 .NET Standard のバージョンについては、 クラウド ビルド マシン に関するページを参照してください。 App Center は Xamarin コンポーネント ストアのコンポーネントをサポートしていないため、使用可能な場合は常に NuGet パッケージを使用することをお勧めします。 交換できないコンポーネントを使用している場合は、お問い合わせください。 ヘルプとフィードバックを参照してください。
最初の Xamarin iOS アプリのビルドを開始するには、次の作業を行う必要があります。
- リポジトリ サービス アカウント (GitHub、Bitbucket、VSTS、Azure DevOps) に接続します。
- アプリが保存されているリポジトリとブランチを選択します。
- ビルドのプロジェクトまたはワークスペース、およびビルドするスキームを構成します。
注意
アプリを実際のデバイスで実行するには、有効なプロビジョニング プロファイルと証明書を使用してコード署名する必要があります。
リポジトリ サービス アカウントに以前に接続していない場合は、それを接続する必要があります。 アカウントが接続されたら、iOS プロジェクトが配置されているリポジトリを選択します。 リポジトリのビルドを設定するには、それに対する管理者とプルのアクセス許可が必要です。
リポジトリを選択したら、ビルドするブランチを選択します。 既定では、すべてのアクティブなブランチが一覧表示されます。
最初のビルドの前に、Xamarin プロジェクトを構成する必要があります。
App Center は、分析範囲内にある場合に、リポジトリ内のソリューション ファイルとプロジェクト ファイルを自動的に検出します。 ビルドする .sln または .csproj/.fsproj を選択します。
注意
最適なパフォーマンスを得るために、分析は現在、 .sln の場合は 2 つのディレクトリ レベルに制限され、リポジトリのルートを含む .csproj/fsproj の場合は 4 つのディレクトリ レベルに制限されています。
コードで、iOS ビルド用のビルド構成に対して Android プロジェクトと UWP プロジェクトを無効にしてください。ソリューションの構成マッピングに移動し、iPhone と iPhoneSimulator を対象とするすべてのマッピングについて、他のプラットフォームを対象とするすべてのプロジェクトをオフにします。 この変更により、 .sln のビルド時に他のプロジェクトのビルドが試行されなくなります。 読み取り可能 なソリューション構成マッピング情報 が他にもあります。
.csproj/.fsproj ファイルからビルドするには、参照されているすべてのプロジェクト (PCL プロジェクトなど) に、ソース iOS プロジェクトの構成と同じ名前の構成が含まれている必要があります。 そのため、App Center でシミュレーターの デバッグ 構成を実行する場合は、PCL プロジェクトに Debug|iPhoneSimulator 構成が必要です。 存在しない場合や、さらにエラーが発生しないようにするため、プロジェクトをビルドする前にこのような構成を追加します。 これらの構成には、デバッグとリリースのみの基本的な既定の設定があります。
ビルドする構成を選択します。 構成は、前の手順で選択したソース ファイルに応じて自動的に検出されます。
App Center では、ビルドに Xamarin.iOS SDK にバンドルされているさまざまな Mono 環境を使用して、新しい機能のサポートをリリースしながら下位互換性を維持できます。 新しいブランチ構成の既定の Mono は、最新の安定した構成になります。 以前の Mono 環境のいずれかを使用して、古いバージョンのフレームワークまたはライブラリをビルドすることもできます。 別の Mono バージョンを選択すると、バンドルされている Xamarin.iOS SDK バージョンが表示されます。 Xamarin SDK バージョンの更新を追跡するには、 Xamarin リリース ブログの投稿を読むことができます。
ビルドに使用される Xamarin.iOS バージョンに基づいて適切な .NET バージョンが自動的に選択され、上書きすることはできません。 サービスで使用されている .NET への Xamarin.iOS のマッピングを次の表に示します。
Xamarin.iOS | .NET |
---|---|
13.20 | 3.1.401 |
14.0 | 3.1.401 |
14.2 | 3.1.401 |
14.4 | 3.1.401 |
14.6 | 5.0.100 |
14.8 | 5.0.100 |
14.10 | 5.0.100 |
14.14 | 5.0.100 |
14.16 | 5.0.100 |
14.20 | 5.0.100 |
15 | 5.0.100 |
15.2 | 5.0.100 |
15.4 | 5.0.100 |
15.6 | 5.0.100 |
15.8 | 5.0.100 |
15.10 | 5.0.100 |
15.12 | 5.0.100 |
16.0 | 5.0.100 |
16.0 (.NET 6) | 6.0.405 |
16.1 | 6.0.405 |
16.2 | 6.0.405 |
現在サポートされている Xamarin のバージョンでは、Xcode 11.7 以降が必要です
既定では、開発者が構成されたブランチにプッシュするたびに、新しいビルドがトリガーされます。 新しいビルドを手動でトリガーする場合は、構成ウィンドウでこの設定を変更できます。
シミュレーター ビルドはシミュレーターでのみ実行でき、デバイスにインストールすることはできませんが、ビルドはデバイス ビルドよりも高速に完了します。 ビルドがシミュレーター ビルドでない場合は、次の手順でコード署名ファイルをアップロードする必要があります。
有効にすると、 CFBundleVersion
アプリの Info.plist の がビルドごとに自動的にインクリメントされます。 変更はビルド前に行われ、リポジトリにコミットされません。
デバイスのビルドが成功すると、IPA ファイルが生成されます。 デバイスにビルドをインストールするには、有効なプロビジョニング プロファイルと証明書を使用して署名する必要があります。 ブランチから生成されたビルドに署名するには、構成ウィンドウでコード署名を有効にし、 プロビジョニング プロファイル (.mobileprovision
) と有効な証明書 (.p12
) と証明書のパスワードをアップロードします。 Xamarin iOS アプリのコード署名とデバイス プロビジョニングの詳細については、 Xamarin のドキュメントを参照してください。
アプリまたは watchOS 拡張機能を使用するアプリでは、拡張機能ごとに追加のプロビジョニング プロファイルを署名する必要があります。
注意
Xamarin watchOS アプリを含むプロジェクトでを実行nuget restore
すると、既存の問題があります。
回避策なしで App Center で watchOS アプリをビルドすると、エラーが発生します。
Project <project> is not compatible with xamarinios10 (Xamarin.iOS,Version=v1.0) / win-x86. Project <project> supports: xamarinwatchos10 (Xamarin.WatchOS,Version=v1.0)
.
App Center で watchOS アプリを構築するには、回避策が必要です。 Watch アプリを参照する含む iOS プロジェクト内に、 追加の行を含める必要があります。
<ReferenceOutputAssembly>False</ReferenceOutputAssembly>
回避策を使用した WatchApp リファレンスの例:
<ProjectReference Include="..\MyWatchApp\MyWatchApp.csproj">
<Project>{59EB034F-3D29-43A5-B89F-124879504771}</Project>
<Name>MyWatchApp</Name>
<IsWatchApp>True</IsWatchApp>
<ReferenceOutputAssembly>False</ReferenceOutputAssembly>
</ProjectReference>
新しく生成された .ipa ファイルを使用して、アプリが実際のデバイスで起動するかどうかをテストします。 起動テストでは、ビルド時間にさらに約 10 分が追加されます。 ビルドのテストに関するより包括的なガイドをチェックしたい場合があります
NuGet.config ファイルがリポジトリにチェックインされ、リポジトリの.slnまたはルート レベルの横にある場合、App Center は、次の例に示すように、プライベート NuGet フィードが追加されたときに復元されます。 資格情報は、 環境変数を使用して安全に追加できます。
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget" value="https://api.nuget.org/v3/index.json" />
<add key="MyGet" value="https://www.myget.org/F/MyUsername/api/v2/index.json" />
<add key="MyAuthNuget" value="https://nuget.example.com/v2/index.json" />
</packageSources>
<activePackageSource>
<add key="All" value="(Aggregate source)" />
</activePackageSource>
<packageSourceCredentials>
<MyAuthNuget>
<add key="Username" value="$USER_VARIABLE" />
<add key="ClearTextPassword" value="$PASSWORD_VARIABLE" />
</MyAuthNuget>
</packageSourceCredentials>
</configuration>
複雑な構成があり、詳細が必要な場合は、「 NuGet の動作の構成」を参照してください。
ブランチから正常にビルドされるたびに、以前に作成した配布グループに配布するように構成できます。 [配布] セクション内から新しい配布グループを追加できます。 アプリにアクセスできるすべてのユーザーを含む、"コラボレーター" という名前の既定の配布グループが常に存在します。
構成を保存すると、新しいビルドが自動的に開始されます。
ビルドがトリガーされると、次の状態になります。
- queued - ビルドは、リソースの解放を待機しているキューにあります。
- building - ビルドが実行され、定義済みのタスクが実行されています。
- succeeded - ビルドが正常に完了しました。
- failed - エラーが原因でビルドが停止しました。 ビルド ログをダウンロードして調べることで、問題のトラブルシューティングを行うことができます。
- canceled - ユーザー アクションによってビルドが取り消されたか、タイムアウトしました。
完了したビルド (成功または失敗) の場合は、ログをダウンロードして、ビルドの実行方法の詳細を理解します。 App Center には、次のファイルを含むアーカイブが用意されています。
|-- 1_build.txt (this is the general build log)
|-- build (this folder contains a separate log file for each build step)
|-- <build-step-1> (e.g. 2_Get Sources.txt)
|-- <build-step-2> (e.g. 3_Pod install.txt)
|--
|-- <build-step-n> (e.g. n_Post Job Cleanup.txt)
ビルド ステップ固有のログ (アーカイブのディレクトリにあります build/
) は、トラブルシューティングと、ビルドが失敗した手順と理由を理解するのに役立ちます。
.ipa
は、iOS アプリを含む iOS アプリケーション アーカイブ ファイルです。 ビルドが正しく署名されている場合は、 を .ipa
実際のデバイスにインストールできます。これは、署名時に使用されるプロビジョニング プロファイルに対応します。 App Center でのコード署名と配布の詳細については、以下を参照してください。
アプリがシミュレーター ビルドの場合は、シミュレーターでファイルを .app
実行できますが、実際のデバイスでは使用できません。
シンボル ファイルは、デバイス ビルドに対してのみ生成されます。 .dsym ファイルには、アプリのデバッグ シンボルが含まれています。
- 以前に App Center SDK をアプリに統合し、クラッシュ レポート モジュールを有効にした場合、クラッシュ レポート サービスでは、人間が読み取り可能な (シンボリック化された) クラッシュ レポートを表示するために、ビルドにこの
.dsym
ファイルが必要です。 - アプリでクラッシュ レポート用の別の SDK (HockeyApp SDK など) を以前に統合した場合、対応するサービスでは、人間が判読できるクラッシュ レポートを表示するファイルが必要
.dsym
です。