Xamarin

My Xamarin.iOS builds build from solution file (.sln) instead of project file (.csproj)

Wenn Ihre Xamarin.iOS-Builds aus der Lösungsdatei (.sln) ausgeführt werden, gibt es mehrere Dinge, die Sie überprüfen möchten.

Android- und UWP-Projekte sollten in Ihrem Code für Buildkonfigurationen deaktiviert werden, die für iOS-Builds vorgesehen sind. Wechseln Sie zu den Konfigurationszuordnungen der Lösung, und deaktivieren Sie für alle Zuordnungen, die auf iPhone und iPhoneSimulator abzielen, alle Projekte, die auf verschiedene Plattformen ausgerichtet sind. Diese Konfiguration stellt sicher, dass beim Erstellen der .sln Erstellung nicht versucht wird, andere Projekte zu erstellen.

Bei meinen Xamarin.iOS-Builds tritt ein Fehler auf, der behauptet, dass ich Signaturinformationen bereitstellen muss.

Wenn Ihre Xamarin.iOS-Builds nicht signiert sind, aber der Buildprozess die Signatur erfordert, liegt es wahrscheinlich daran, dass Sie in der App Center Branch-Konfiguration ausgewählt Sign builds: Off haben.

Wenn Ihr Buildprotokoll Folgendes enthält:

RequireProvisioningProfile: True. 

Dies bedeutet, dass Ihr Projekt selbst für das Signieren konfiguriert ist und die Signierung trotz der App Center-Konfiguration anwendet.

Um dies zu beheben, öffnen Sie project Options > Build > iOS Bundle Signing in Ihrer IDE, und stellen Sie sicher, dass Ihre Projektkonfiguration (z. B. Debug|iPhoneSimulator) keine anderen Signaturinformationen als "Automatisch" enthält.

Mein Xamarin.Android-Build ist mit Fehler fehlgeschlagen: Es wurden keine APK-Dateien gefunden.

Ein häufiger Grund für einen Buildfehler während der Aufgabe Xamarin Android Postprocess ist ein falscher Wert in der Eigenschaft in der <OutputPath> Android-Projektdatei. Um dies zu überprüfen, wechseln Sie zu "Xamarin.Android > Project Options > Build > Output ", und stellen Sie sicher, dass Ihre Buildkonfiguration (Debug/Release) auf den Standardspeicherort verweist. Normalerweise sollte es sein YourProjectDir/bin/$(Configuration).

Ich habe meine Xamarin.iOS-App-Verzweigung so eingerichtet, dass er ohne Signierung erstellt wird, aber mein Build konnte nicht behaupten, dass ich die Signaturinformationen bereitstellen muss.

Wenn Sie in der App Center Branch-Konfiguration ausgewählt Sign builds: Off haben und Ihr Buildprotokoll enthält RequireProvisioningProfile: True, bedeutet dies, dass Ihr Projekt selbst für die Signatur konfiguriert ist und versucht, die Signatur trotz der App Center-Konfiguration anzuwenden. Um es zu beheben, öffnen Sie project Options > Build > iOS Bundle Signing in Your IDE und stellen Sie sicher, dass Ihre Projektkonfiguration (z. B. Debug|iPhoneSimulator) keine anderen Signaturinformationen als "Automatisch" enthält.

Mein Xamarin.iOS-Simulator-Build kann nicht in iOS Simulator installiert werden, wobei "Fehler beim Chmod ... /Appname.iOS.app/Appname.iOS : Keine solche Datei oder verzeichnis" Fehler aufgetreten ist.

Wenn Sie ein Xamarin.iOS-Projekt in Visual Studio erstellen, enthält die Standardkonfiguration für iPhoneSimulator i386 + x86_64 unterstützte Architekturen. Die .app Datei, die aus einer solchen Konfiguration erstellt wird, kann nicht in einen Simulator hochgeladen werden. Öffnen Sie Project Options > Build iOS Build > und für iPhoneSimulator Konfigurationsänderung Unterstützte Architekturen in i386 oder x86_64.

Mein Xamarin-Build schlägt mit fehler MSB4018 fehl: Unerwarteter Fehler bei der Aufgabe "WriteRestoreGraphTask".

Anscheinend enthält Ihre Lösung PCL- oder ältere .NET Standard-Projekte zusammen mit neueren .NET Standard-Projekten. Das bedeutet, dass sie sowohl als auch PackageTargetFallback AssetTargetFallback Verweise in .csproj Dateien enthalten können. Ihre Buildprotokolle enthalten auch Nachrichten wie die folgende:

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

Um dieses Problem zu beheben, entfernen Sie entweder PackageTargetFallback (ist in älteren PCL-Dateien .csproj tendiert), oder benennen Sie es in AssetTargetFallback um? Die Lösung wird auch in diesem StackOverflow-Thread beschrieben.

Mein Xamarin-Build schlägt mit einem Fehler fehl: Dieses Projekt verweist auf NuGet-Pakete, die auf diesem Computer fehlen.

Anscheinend wurden nicht alle Pakete wiederhergestellt, um Ihre Anwendung zu erstellen. Ihre Buildprotokolle enthalten auch Nachrichten wie die folgenden:

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

Um dieses Problem zu beheben, können Sie pre-build script appcenter-pre-build.sh with the following commands verwenden, which restores all packages for each solution in your repository:

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

Ich möchte Komponententests für meine Xamarin-Anwendung ausführen

Verwenden Sie ein Postbuildskript, um Komponententests in Ihren Xamarin-Builds auszuführen. Wenn Ihr NUnit-basiertes Projekt beispielsweise den Namen "Test" aufweist, können Sie das folgende Skript verwenden, um die Ergebnisse zu erstellen, auszuführen und anzuzeigen:

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 {} \;

Ich erhalte eine Fehlermeldung: Es wurden keine Projekte gefunden, und für Xamarin-Builds wurden keine Konfigurationen gefunden.

Es könnte ein Problem der Repositorytiefe sein, in der sich die .csproj und .sln sich befinden. Aufgrund von Leistungsgründen gibt es eine Einschränkung in der aktuellen Analyse.

Bei .csproj Dateien sollte sie nicht unter vier Verzeichnissen liegen, einschließlich des Repositorystamms.

Bei .sln Dateien sollte sie nicht niedriger als zwei Verzeichnisse sein, einschließlich des Repositorystamms.

Gewusst wie einen privaten NuGet-Feed wiederherstellen?

Wenn die Datei NuGet.Config in das Repository eingecheckt ist und sich neben dem .sln oder auf der Stammebene Ihres Repositorys befindet, stellt App Center Ihre privaten NuGet-Feeds wieder her, wenn sie wie im folgenden Beispiel gezeigt hinzugefügt werden. Anmeldeinformationen können sicher mithilfe von Umgebungsvariablen hinzugefügt werden.

Für Mac-Buildcomputer:

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

Informationen zu Windows-Buildcomputern finden Sie unter UWP C#.

Wenn Sie über komplexe Konfigurationen verfügen und weitere Informationen benötigen, können Sie sich auf das Konfigurieren des NuGet-Verhaltens beziehen.

Builds hängen bei CompileToNative

Wenn bei dem Build ähnliche Symptome auftreten, wie in diesem GitHub-Problem beschrieben, versuchen Sie, nur für ARM64 zu erstellen, indem Sie das folgende Argument hinzufügen, wie im Problem vorgeschlagen:

<MtouchArch>ARM64</MtouchArch>

Fehler beim Buildfehler: Ziel "_IsProjectRestoreSupported" ist im Projekt nicht vorhanden.

Möglicherweise treten Buildprobleme auf, wenn Sie über ein UWP-Projekt in der Lösung verfügen, bei dem während der Wiederherstellung ihre Fehler in der alten Version von NuGet im Hintergrund ignoriert wurden. Das Entfernen oder Beheben eines solchen UWP-Projekts in der Lösung kann das Problem beheben. Plese sehen die Details in diesem GitHub-Problem.