Xamarin

Important

Visual Studio App Center est prévu pour la mise 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 que vous pouvez envisager de migrer vers.

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

Mes builds Xamarin.iOS Proviennent du fichier solution (.sln) au lieu du fichier projet (.csproj)

Lorsque vos builds Xamarin.iOS s’exécutent à partir du fichier solution (.sln), plusieurs éléments peuvent être vérifiés.

Les projets Android et UWP doivent être désactivés dans votre code 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 qui ciblent différentes plateformes. Cette configuration garantit que lorsque la .sln génération commence, elle ne tente pas de générer d’autres projets.

Mes builds Xamarin.iOS échouent et j’ai besoin de fournir des informations de signature

Si vos builds Xamarin.iOS ne sont pas signées, mais que le processus de génération nécessite la signature, c’est probablement parce que vous avez sélectionné Sign builds: Off dans la configuration de la branche App Center.

Si votre journal de génération contient :

RequireProvisioningProfile: True. 

Cela signifie que votre projet lui-même est configuré pour la signature et applique la signature malgré la configuration d’App Center.

Pour résoudre ce problème, ouvrez > l’offre groupée iOS Build > iOS Bundle Sign in your IDE et assurez-vous que votre configuration de projet (par exemple, Debug|iPhoneSimulator) ne contient aucune information de signature autre que Automatique.

Ma build Xamarin.Android a échoué avec l’erreur : aucun fichier APK trouvé.

Une des raisons courantes d’une défaillance de build pendant la tâche Postprocess Xamarin Android est une valeur incorrecte dans la propriété dans le <OutputPath> fichier projet Android. Pour le vérifier, accédez à Xamarin.Android > Project Options > Build > Output et vérifiez que votre configuration de build (Debug/Release) pointe vers l’emplacement par défaut. En règle générale, il devrait être YourProjectDir/bin/$(Configuration).

J’ai configuré ma branche d’application Xamarin.iOS pour générer sans signer, mais mon build a échoué, j’ai besoin de fournir les informations de signature

Si vous avez sélectionné Sign builds: Off dans la configuration de la branche App Center et que votre journal de génération contient RequireProvisioningProfile: True, cela signifie que votre projet lui-même est configuré pour la signature et tente d’appliquer la signature malgré la configuration d’App Center. Pour résoudre ce problème, ouvrez > le bundle iOS Build > iOS Bundle Sign in your IDE and sure that your project configuration (par exemple, Debug|iPhoneSimulator) ne contient aucune information de signature autre que Automatic.

Ma build de simulateur Xamarin.iOS ne parvient pas à s’installer dans iOS Simulator avec l’erreur « Échec de chmod ... /Appname.iOS.app/Appname.iOS : Aucune erreur de fichier ou de répertoire de ce type .

Lorsque vous créez un projet Xamarin.iOS dans Visual Studio, la configuration par défaut pour iPhoneSimulator a i386 + x86_64 architectures prises en charge. Le fichier .app généré à partir de cette configuration ne peut pas être chargé dans un simulateur. Ouvrez Project Options > Build iOS Build > and for iPhoneSimulator configuration changez les architectures prises en charge par i386 ou x86_64.

Ma build Xamarin échoue avec l’erreur MSB4018 : la tâche « WriteRestoreGraphTask » a échoué de façon inattendue.

Il semble que votre solution contient des projets PCL ou .NET Standard plus anciens avec des projets .NET Standard plus récents. Cela signifie qu’ils peuvent contenir des PackageTargetFallback références et AssetTargetFallback des références dans des .csproj fichiers. Vos journaux de génération contiennent également des messages comme suit :

error MSB4018: NuGet.Commands.RestoreCommandException: PackageTargetFallback and AssetTargetFallback cannot be used together. Remove PackageTargetFallback(deprecated) references from the project environment.

Pour résoudre ce problème, supprimez PackageTargetFallback (généralement dans les fichiers PCL .csproj plus anciens) ou renommez-le en AssetTargetFallback ? La solution est également décrite dans ce thread StackOverflow.

Ma build Xamarin échoue avec une erreur : ce projet fait référence aux packages NuGet manquants sur cet ordinateur.

Il semble que tous les packages n’ont pas été restaurés pour générer votre application. Vos journaux de génération contiennent également des messages tels que ceux-ci :

warning MSB3245: Could not resolve this reference. Could not locate the assembly "ASSEMBLY_NAME". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
error CS0246: The type or namespace name 'TYPE_OR_NAMESPACE_NAME' could not be found (are you missing a using directive or an assembly reference?)

Pour résoudre ce problème, vous pouvez utiliser le script appcenter-pre-build.sh de pré-génération avec les commandes suivantes, qui restaure tous les packages pour chaque solution de votre dépôt :

#!/bin/bash
find $APPCENTER_SOURCE_DIRECTORY -name '*.sln' -print0 | xargs -0 -n1 nuget restore -DisableParallelProcessing

Je souhaite exécuter des tests unitaires pour mon application Xamarin

Pour exécuter des tests unitaires dans vos builds Xamarin, utilisez un script post-build. Par exemple, lorsque votre projet basé sur NUnit a test dans le nom, vous pouvez utiliser le script suivant pour générer, exécuter et afficher les résultats :

echo "Found NUnit test projects:"
find $APPCENTER_SOURCE_DIRECTORY -regex '.*Test.*\.csproj' -exec echo {} \;
echo
echo "Building NUnit test projects:"
find $APPCENTER_SOURCE_DIRECTORY -regex '.*Test.*\.csproj' -exec msbuild {} \;
echo
echo "Compiled projects to run NUnit tests:"
find $APPCENTER_SOURCE_DIRECTORY -regex '.*bin.*Test.*\.dll' -exec echo {} \;
echo
echo "Running NUnit tests:"
find $APPCENTER_SOURCE_DIRECTORY -regex '.*bin.*Test.*\.dll' -exec nunit3-console {} \;
echo
echo "NUnit tests result:"
find . -name 'TestResult.xml' -exec cat {} \;

J’obtiens une erreur : Aucun projet trouvé et aucune configuration trouvée pour les builds Xamarin

Il peut s’agir d’un problème de profondeur du dépôt dans lequel se trouvent les .csproj .sln données. Il existe une limitation dans l’analyseur actuel en raison de raisons de performances.

Pour .csproj les fichiers, il ne doit pas être inférieur à quatre répertoires profonds, y compris la racine du référentiel.

Pour .sln les fichiers, il ne doit pas être inférieur à deux répertoires profonds, y compris la racine du référentiel.

Comment faire restaurer un flux NuGet privé ?

Si le fichier NuGet.Config est archivé dans le référentiel et assis en regard de l '.sln ou au niveau racine de votre référentiel, 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.

Pour les machines de build Mac :

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

Pour les machines de build Windows, reportez-vous à UWP C#.

Si vous avez des configurations complexes et avez besoin d’informations supplémentaires, vous pouvez vous référer à La configuration du comportement NuGet.

Builds bloquées sur CompileToNative

Si la build rencontre des symptômes similaires comme décrit dans ce problème GitHub, essayez de générer uniquement pour ARM64 en ajoutant l’argument suivant, comme suggéré dans le problème :

<MtouchArch>ARM64</MtouchArch>

Échec de la génération avec l’erreur : la cible « _IsProjectRestoreSupported » n’existe pas dans le projet.

Vous pouvez rencontrer des problèmes de génération si vous avez un projet UWP dans la solution où pendant la restauration ses erreurs ont été ignorées silencieusement dans l’ancienne version de NuGet. La suppression ou la résolution de ce projet UWP dans la solution peut résoudre le problème. Plese consultez les détails de ce problème GitHub.