Xamarin

Ważne

Program Visual Studio App Center ma zostać wycofany 31 marca 2025 r. Mimo że można nadal używać programu Visual Studio App Center do momentu jego pełnego wycofania, istnieje kilka zalecanych alternatyw, do których można rozważyć migrację.

Dowiedz się więcej o osiach czasu pomocy technicznej i alternatywach.

Moja kompilacja platformy Xamarin.iOS z pliku rozwiązania (.sln) zamiast pliku projektu (csproj)

Podczas uruchamiania kompilacji platformy Xamarin.iOS z pliku rozwiązania (.sln) warto sprawdzić kilka rzeczy.

Projekty systemu Android i platformy UWP powinny być wyłączone w kodzie na potrzeby konfiguracji kompilacji przeznaczonych dla kompilacji systemu iOS. Przejdź do mapowań konfiguracji rozwiązania i dla wszystkich mapowań przeznaczonych dla urządzeń iPhone i iPhoneSimulator usuń zaznaczenie wszystkich projektów przeznaczonych dla różnych platform. Ta konfiguracja gwarantuje, że po rozpoczęciu kompilacji .sln nie będzie podejmować próby skompilowania innych projektów.

Kompilacje platformy Xamarin.iOS kończą się niepowodzeniem, twierdząc, że muszę podać informacje o podpisywaniu

Jeśli kompilacje platformy Xamarin.iOS nie są podpisane, ale proces kompilacji wymaga podpisania, prawdopodobnie dlatego, że wybrano konfigurację Sign builds: Off gałęzi Centrum aplikacji.

Jeśli dziennik kompilacji zawiera następujące elementy:

RequireProvisioningProfile: True. 

Oznacza to, że sam projekt jest skonfigurowany do podpisywania i stosuje podpisywanie pomimo konfiguracji centrum aplikacji.

Aby rozwiązać ten problem, otwórz plik Project Options Build > iOS Bundle Signing in your IDE (Build Project Options > Signing in your IDE ( (Na przykład Debuguj|iPhoneSimulator) nie zawiera żadnych informacji o podpisywaniu innych niż Automatyczne.

Kompilacja platformy Xamarin.Android nie powiodła się z powodu błędu: nie znaleziono plików APK.

Jedną z typowych przyczyn niepowodzenia kompilacji podczas zadania Xamarin Android Postprocess jest nieprawidłowa wartość we właściwości w <OutputPath> pliku projektu systemu Android. Aby to sprawdzić, przejdź do pozycji Xamarin.Android Project Options > Build Output (Kompilowanie > danych wyjściowych projektu platformy Xamarin.Android>) i sprawdź, czy konfiguracja kompilacji (debugowanie/wydanie) wskazuje domyślną lokalizację. Zazwyczaj powinna to być YourProjectDir/bin/$(Configuration)wartość .

Skonfigurowano gałąź aplikacji platformy Xamarin.iOS do kompilacji bez podpisywania, ale kompilacja nie powiodła się, twierdząc, że muszę podać informacje o podpisywaniu

Jeśli wybrano konfigurację Sign builds: Off gałęzi Centrum aplikacji, a dziennik kompilacji zawiera RequireProvisioningProfile: Truewartość , oznacza to, że sam projekt jest skonfigurowany do podpisywania i spróbuje zastosować podpisywanie pomimo konfiguracji centrum aplikacji. Aby rozwiązać ten problem, otwórz okno Project Options > Build > iOS Bundle Signing in your IDE (Build iOS Bundle Signing in your IDE( your project configuration (na przykład Debuguj|iPhoneSimulator) nie zawiera żadnych informacji o podpisywaniu innych niż Automatyczne.

Nie można zainstalować kompilacji symulatora platformy Xamarin.iOS w symulatorze systemu iOS z błędem "Nie można chmod ... /Appname.iOS.app/Appname.iOS: nie ma takiego pliku lub katalogu".

Podczas tworzenia projektu platformy Xamarin.iOS w programie Visual Studio domyślna konfiguracja urządzenia iPhoneSimulator ma architektury obsługiwane przez platformę i386 i x86_64 . Plik .app kompilacji z takiej konfiguracji nie będzie można przekazać do symulatora. Otwórz opcje > projektu Kompilacja > kompilacji systemu iOS i dla konfiguracji iPhoneSimulator zmień obsługiwane architektury na i386 lub x86_64.

Moja kompilacja platformy Xamarin kończy się niepowodzeniem z powodu błędu MSB4018: zadanie "WriteRestoreGraphTask" nie powiodło się nieoczekiwanie.

Wygląda na to, że rozwiązanie zawiera projekty PCL lub starsze projekty .NET Standard wraz z nowszymi projektami .NET Standard. Oznacza to, że mogą zawierać zarówno PackageTargetFallback odwołania, jak i AssetTargetFallback w .csproj plikach. Dzienniki kompilacji będą również zawierać komunikaty podobne do poniższych:

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

Aby rozwiązać ten problem, usuń element PackageTargetFallback (zwykle w starszych plikach PCL .csproj ) lub zmień jego nazwę na AssetTargetFallback? Rozwiązanie zostało również opisane w tym wątku StackOverflow.

Moja kompilacja platformy Xamarin kończy się niepowodzeniem z powodu błędu: ten projekt odwołuje się do pakietów NuGet, których brakuje na tym komputerze.

Wygląda na to, że nie wszystkie pakiety zostały przywrócone do skompilowania aplikacji. Dzienniki kompilacji będą również zawierać komunikaty podobne do następujących:

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

Aby rozwiązać ten problem, możesz użyć skryptu appcenter-pre-build.sh wstępnego kompilacji z następującymi poleceniami, które przywraca wszystkie pakiety dla każdego rozwiązania w repozytorium:

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

Chcę uruchomić testy jednostkowe dla mojej aplikacji platformy Xamarin

Aby uruchomić testy jednostkowe w kompilacjach platformy Xamarin, użyj skryptu po kompilacji. Na przykład gdy projekt oparty na NUnit ma wartość Test w nazwie, możesz użyć następującego skryptu, aby skompilować, uruchomić i wyświetlić wyniki:

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

Otrzymuję błąd: Nie znaleziono projektów i nie znaleziono żadnych konfiguracji dla kompilacji platformy Xamarin

Może to być problem z głębokością repozytorium, .csproj w których znajdują się i .sln . Istnieje ograniczenie dotyczące bieżącego analizatora ze względu na wydajność.

W przypadku .csproj plików nie powinna być mniejsza niż cztery katalogi, w tym katalog główny repozytorium.

W przypadku .sln plików nie powinna być niższa niż dwa katalogi, w tym katalog główny repozytorium.

Jak mogę przywrócić prywatne źródło danych NuGet?

Jeśli plik NuGet.Config jest zaewidencjonowany w repozytorium i znajduje się obok .sln lub na poziomie głównym repozytorium, centrum aplikacji przywraca prywatne kanały informacyjne NuGet po dodaniu, jak pokazano w poniższym przykładzie. Poświadczenia można bezpiecznie dodawać przy użyciu zmiennych środowiskowych.

W przypadku maszyn kompilacji dla komputerów 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>

W przypadku maszyn kompilacji systemu Windows zapoznaj się z tematem UWP C#.

Jeśli masz złożone konfiguracje i potrzebujesz więcej informacji, zapoznaj się z artykułem Konfigurowanie zachowania narzędzia NuGet.

Kompilacje zablokowane na stronie CompileToNative

Jeśli kompilacja ma podobne objawy, jak opisano w tym problemie z usługą GitHub, spróbuj skompilować tylko dla usługi ARM64, dodając następujący argument, jak pokazano w problemie:

<MtouchArch>ARM64</MtouchArch>

Kompilacja nie powiodła się z powodu błędu: element docelowy "_IsProjectRestoreSupported" nie istnieje w projekcie.

Problemy z kompilacją mogą wystąpić, jeśli masz projekt platformy UWP w rozwiązaniu, w którym podczas przywracania błędy były dyskretnie ignorowane w starej wersji narzędzia NuGet. Usunięcie lub naprawienie takiego projektu platformy UWP w rozwiązaniu może rozwiązać ten problem. Plese zapoznaj się ze szczegółami w tym problemie z usługą GitHub.