Partager via

Génération d’applications Xamarin pour iOS

  • Article

Important

Visual Studio App Center doit être mis hors service le 31 mars 2025. Bien que vous puissiez continuer à utiliser Visual Studio App Center jusqu’à ce qu’il soit entièrement mis hors service, il existe plusieurs alternatives recommandées vers lesquelles vous pouvez envisager de migrer.

En savoir plus sur les chronologies et les alternatives de support.

Notes

Versions et exigences prises en charge App Center prend en charge les projets PCL (Portable Class Library) et .NET Standard . Reportez-vous à Cloud Build Machines pour les versions de .NET Standard. App Center ne prend pas en charge les composants du magasin de composants Xamarin et nous vous conseillons d’utiliser des packages NuGet chaque fois qu’ils sont disponibles. Si vous utilisez un composant qui ne peut pas être remplacé, contactez-nous. Consultez aide et commentaires.

Pour commencer à créer votre première application iOS Xamarin, vous devez :

  1. Connectez-vous à votre compte de service de dépôt (GitHub, Bitbucket, VSTS, Azure DevOps).
  2. Sélectionnez un dépôt et une branche où réside votre application.
  3. Configurez le projet ou l’espace de travail de la build et le schéma que vous souhaitez générer.

Notes

Pour que l’application s’exécute sur un appareil réel, la build doit être signée avec un profil d’approvisionnement valide et un certificat.

1. Liaison de votre dépôt

Si vous ne vous êtes pas encore connecté à votre compte de service de dépôt, vous devez le connecter. Une fois votre compte connecté, sélectionnez le dépôt où se trouve votre projet iOS. Pour configurer une build pour un dépôt, vous avez besoin d’une autorisation d’administrateur et d’extraction pour celui-ci.

2. Sélection d’une branche

Après avoir sélectionné un dépôt, sélectionnez la branche que vous souhaitez générer. Par défaut, toutes les branches actives sont répertoriées.

3. Configuration de votre première build

Avant votre première build, le projet Xamarin doit être configuré.

3.1. Projet/solution

App Center détecte automatiquement les fichiers de solution et de projet dans votre dépôt s’ils se trouvent dans la plage d’analyse. Sélectionnez le .sln ou .csproj/.fsproj que vous souhaitez générer.

Notes

Pour de meilleures performances, l’analyse est actuellement limitée à deux niveaux de répertoire pour .sln et quatre niveaux de répertoire pour .csproj/fsproj , y compris la racine de votre dépôt.

3.1.1. Génération à partir du fichier solution (.sln)

Dans votre code, veillez à désactiver les projets Android et UWP pour les configurations de build destinées aux builds iOS : accédez aux mappages de configuration de la solution, et pour tous les mappages qui ciblent iPhone et iPhoneSimulator, décochez tous les projets ciblant d’autres plateformes. Cette modification garantit que lorsque le .sln est généré, il n’essaiera pas de générer les autres projets. Vous pouvez lire d’autres informations de mappage de configurations de solution .

3.1.2. Génération à partir du fichier projet (.csproj/.fsproj)

Pour générer à partir d’un fichier .csproj/.fsproj , tous les projets référencés (par exemple, votre projet PCL) doivent contenir la configuration portant le même nom que celui de votre projet iOS source. Par conséquent, si vous exécutez la configuration Debug pour le simulateur dans App Center, votre projet PCL doit avoir la configuration Debug|iPhoneSimulator . Dans le cas où elles n’existent pas et pour éviter d’autres erreurs, nous ajoutons ces configurations avant de créer vos projets. Ces configurations ont des paramètres par défaut de base pour Déboguer et Release uniquement.

3.2. Configuration

Sélectionnez la configuration avec laquelle vous souhaitez créer. Les configurations sont automatiquement détectées en fonction du fichier source sélectionné à l’étape précédente.

3.3. Version mono

App Center permet d’utiliser différents environnements Mono regroupés avec le KIT de développement logiciel (SDK) Xamarin.iOS respectif pour votre build afin de maintenir la compatibilité descendante tout en mettant en place une prise en charge des nouvelles fonctionnalités. La configuration Mono par défaut pour une nouvelle configuration de branche sera la dernière configuration stable. Vous pouvez choisir d’utiliser l’un des environnements Mono précédents pour créer d’anciennes versions de frameworks ou de bibliothèques. Lorsque vous choisissez une autre version Mono, vous voyez la version du KIT de développement logiciel (SDK) Xamarin.iOS qui est fournie avec elle. Pour suivre les mises à jour de version du KIT de développement logiciel (SDK) Xamarin, vous pouvez lire des billets dans le blog de publication de Xamarin.

3.3.1. Version de .NET

La version .NET appropriée est sélectionnée automatiquement en fonction de la version de Xamarin.iOS utilisée pour la génération et ne peut pas être remplacée. Vous pouvez afficher le mappage de Xamarin.iOS au .NET utilisé par nos services dans le tableau ci-dessous :

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

3.4. Xcode Version

Les versions actuellement prises en charge de Xamarin nécessitent Xcode 11.7 ou une version ultérieure

3.5. Déclencheurs de génération

Par défaut, une nouvelle build est déclenchée chaque fois qu’un développeur envoie un push à une branche configurée. Si vous préférez déclencher une nouvelle génération manuellement, vous pouvez modifier ce paramètre dans le volet de configuration.

3.6. Build du simulateur

Les builds de simulateur ne peuvent être exécutées que sur des simulateurs et ne peuvent pas être installées sur l’appareil, mais les builds se terminent plus rapidement que les builds d’appareil. Si votre build n’est pas une build de simulateur, vous devez charger des fichiers de signature de code à l’étape suivante.

3.7. Incrémenter le numéro de build

Lorsque cette option est activée, le CFBundleVersion dans info.plist de votre application s’incrémente automatiquement pour chaque build. La modification se produit avant la génération et ne sera pas validée dans votre dépôt.

3.8. Signature de code

Une build d’appareil réussie génère un fichier IPA. Pour installer la build sur un appareil, elle doit être signée avec un profil et un certificat d’approvisionnement valides. Pour signer les builds produites à partir d’une branche, activez la connexion du code dans le volet de configuration et chargez un profil d’approvisionnement (.mobileprovision) et un certificat valide (.p12) ainsi que le mot de passe du certificat. Vous pouvez en savoir plus sur la signature de code et l’approvisionnement d’appareils des applications iOS Xamarin dans la documentation Xamarin.

Les applications avec des extensions d’application ou watchOS nécessitent la signature d’un profil d’approvisionnement supplémentaire par extension.

Notes

Il existe un problème lors de l’exécution nuget restore dans des projets contenant des applications Xamarin watchOS. La création d’une application watchOS sur App Center sans solution de contournement entraîne une erreur :

Project <project> is not compatible with xamarinios10 (Xamarin.iOS,Version=v1.0) / win-x86. Project <project> supports: xamarinwatchos10 (Xamarin.WatchOS,Version=v1.0).

Pour créer des applications watchOS sur App Center, une solution de contournement est requise. Dans le projet iOS contenant, qui fait référence à l’application Watch, une ligne supplémentaire doit être incluse :

<ReferenceOutputAssembly>False</ReferenceOutputAssembly>

Exemple de référence WatchApp avec solution de contournement :

    <ProjectReference Include="..\MyWatchApp\MyWatchApp.csproj">
      <Project>{59EB034F-3D29-43A5-B89F-124879504771}</Project>
      <Name>MyWatchApp</Name>
      <IsWatchApp>True</IsWatchApp>
      <ReferenceOutputAssembly>False</ReferenceOutputAssembly>
    </ProjectReference>

3.9. Lancer votre build réussi sur un appareil réel

Utilisez votre fichier .ipa nouvellement produit pour tester si votre application démarre sur un appareil réel. Lancer le test ajoute environ 10 minutes supplémentaires au temps de génération. Vous souhaiterez peut-être case activée guide plus complet sur le test de vos builds

3.10. Restauration NuGet

Si le fichier NuGet.config est archivé pour le dépôt et se trouve à côté du .sln ou du niveau racine de votre dépôt, App Center restaure vos flux NuGet privés lorsqu’ils sont ajoutés, comme indiqué dans l’exemple ci-dessous. Les informations d’identification peuvent être ajoutées en toute sécurité à l’aide de variables d’environnement :

<?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>

Si vous avez des configurations complexes et avez besoin d’informations supplémentaires, consultez Configuration du comportement De NuGet.

3.11. Distribuer à un groupe de distribution

Vous pouvez configurer chaque build réussie à partir d’une branche pour qu’elle soit distribuée à un groupe de distribution créé précédemment. Vous pouvez ajouter un nouveau groupe de distribution à partir de la section Distribuer. Il existe toujours un groupe de distribution par défaut appelé « Collaborateurs » qui inclut tous les utilisateurs qui ont accès à l’application.

Une fois que vous avez enregistré la configuration, une nouvelle build est automatiquement lancée.

4. Générer des résultats

Une fois qu’une build a été déclenchée, elle peut se trouver dans les états suivants :

  • mis en file d’attente : la build se trouve dans une file d’attente qui attend que les ressources soient libérées.
  • building : la build exécute et exécute les tâches prédéfinies.
  • réussi : la build s’est terminée avec succès.
  • échec : la build s’est arrêtée en raison d’un échec. Vous pouvez résoudre les problèmes en téléchargeant et en inspectant le journal de build.
  • annulé : la build a été annulée par une action utilisateur ou a expiré.

4.1. Journaux d’activité de génération

Pour une build terminée (réussie ou ayant échoué), téléchargez les journaux pour en savoir plus sur la façon dont la build s’est déroulée. App Center fournit une archive avec les fichiers suivants :

|-- 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)

Les journaux spécifiques à l’étape de génération (situés dans le build/ répertoire de l’archive) sont utiles pour résoudre les problèmes et comprendre quelle étape et pourquoi la build a échoué.

4.2. L’application (.ipa ou .app)

est .ipa un fichier d’archive d’application iOS qui contient l’application iOS. Si la build a été correctement signée, .ipa le peut être installé sur un appareil réel, correspondant au profil d’approvisionnement utilisé lors de la signature. Vous trouverez plus d’informations sur la signature et la distribution du code avec App Center.

Si l’application est une build de simulateur, vous pouvez exécuter le .app fichier sur un simulateur, mais vous ne pouvez pas l’utiliser sur un appareil réel.

4.3. Fichiers de symboles (.dsym)

Les fichiers de symboles sont générés uniquement pour les builds d’appareils. Les fichiers .dsym contiennent les symboles de débogage de l’application.

  • Si vous avez précédemment intégré le Kit de développement logiciel (SDK) App Center dans votre application avec le module rapport d’incident activé, le service de rapports d’incidents nécessite ce .dsym fichier pour qu’une build affiche des rapports d’incidents lisibles (symboliques) par l’homme.
  • Si vous avez précédemment intégré un autre KIT de développement logiciel (SDK) pour les rapports d’incidents dans votre application (par exemple, le KIT DE développement logiciel HockeyApp), le service correspondant exige que le .dsym fichier affiche des rapports d’incident lisibles par l’utilisateur.