Xamarin

Meus builds do Xamarin.iOS são compilados do arquivo de solução (.sln) em vez do arquivo de projeto (.csproj)

Quando os builds do Xamarin.iOS são executados no arquivo de solução (.sln), há várias coisas que você pode querer verificar.

Os projetos Android e UWP devem ser desabilitados em seu código para configurações de build destinadas a builds do iOS. Vá para os mapeamentos de configuração da solução e, para todos os mapeamentos direcionados ao iPhone e ao iPhoneSimulator, desmarque todos os projetos direcionados a plataformas diferentes. Essa configuração garante que, quando o começar a .sln ser construído, ele não tentará criar outros projetos.

Minhas compilações do Xamarin.iOS falham alegando que preciso fornecer informações de assinatura

Se os builds do Xamarin.iOS não estiverem assinados, mas o processo de build exigir assinatura, provavelmente é porque você selecionou Sign builds: Off na configuração do branch do App Center.

Se o log de compilação contiver:

RequireProvisioningProfile: True. 

Isso significa que seu próprio projeto está configurado para assinatura e aplica a assinatura, apesar da configuração do App Center.

Para corrigi-lo, abra Opções > de projeto Criar > assinatura de pacote do iOS em seu IDE e certifique-se de que a configuração do projeto (por exemplo, Depurar|iPhoneSimulator) não contenha nenhuma informação de assinatura além de Automática.

Meu build do Xamarin.Android falhou com Erro: Nenhum arquivo APK encontrado.

Um motivo comum para uma falha de build durante a <OutputPath> tarefa de pós-processamento do Xamarin Android é um valor incorreto na propriedade no arquivo de projeto do Android. Para verificá-lo, acesse Saída de Build > de Opções > de Projeto do Xamarin.Android > e verifique se a configuração de build (Depuração/Versão) aponta para o local padrão. Normalmente, deve ser YourProjectDir/bin/$(Configuration).

Configurei meu branch de aplicativo Xamarin.iOS para compilar sem assinar, mas meu build falhou alegando que preciso fornecer as informações de assinatura

Se você selecionou Sign builds: Off na configuração do branch do App Center e seu log de build contiver RequireProvisioningProfile: True, isso significa que seu próprio projeto está configurado para assinatura e tentará aplicar a assinatura apesar da configuração do App Center. Para corrigi-lo, abra Opções > do Projeto: Compilar > Assinatura de Pacote do iOS em seu IDE e certifique-se de que a configuração do seu projeto (por exemplo, Depurar|iPhoneSimulator) não contenha nenhuma informação de assinatura além de Automática.

Meu build do simulador Xamarin.iOS falha ao instalar no Simulador do iOS com o erro "Falha ao chmod ... /Appname.iOS.app/Appname.iOS : Não existe esse arquivo ou diretório".

Quando você cria um projeto Xamarin.iOS no Visual Studio, a configuração padrão do iPhoneSimulator tem i386 + x86_64 arquiteturas com suporte. O arquivo .app que é compilado a partir dessa configuração não será carregado em um simulador. Abra Opções > do Projeto Compilar > iOS Build e, para configuração do iPhoneSimulator, altere as arquiteturas com suporte para i386 ou x86_64.

Meu build do Xamarin falha com o erro MSB4018: a tarefa "WriteRestoreGraphTask" falhou inesperadamente.

Parece que sua solução contém projetos PCL ou .NET Standard mais antigos, juntamente com projetos .NET Standard mais recentes. Isso significa que eles podem conter referências PackageTargetFallback e AssetTargetFallback em .csproj arquivos. Seus logs de compilação também conterão mensagens como esta:

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

Para resolver esse problema, remova PackageTargetFallback (tende a estar em arquivos PCL .csproj mais antigos) ou renomeie-o para AssetTargetFallback? A solução também é descrita neste thread do StackOverflow.

Meu build do Xamarin falha com erro: Este projeto faz referência a pacotes NuGet que estão ausentes neste computador.

Parece que nem todos os pacotes foram restaurados para construir seu aplicativo. Seus logs de compilação também conterão mensagens como estas:

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

Para resolver esse problema, você pode usar o script appcenter-pre-build.sh de pré-compilação com os seguintes comandos, que restaura todos os pacotes para cada solução em seu repositório:

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

Quero executar testes de unidade para meu aplicativo Xamarin

Para executar testes de unidade em seus builds do Xamarin, use um script de pós-build. Por exemplo, quando seu projeto baseado em NUnit tem Test no nome, você pode usar o seguinte script para compilar, executar e exibir os resultados:

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

Recebo um erro: Nenhum projeto encontrado e Nenhuma configuração encontrada para builds do Xamarin

Pode ser um problema da profundidade do repositório em que os .csproj e .sln estão localizados. Há uma limitação no analisador de corrente por motivos de desempenho.

Para .csproj arquivos, não deve ter menos de quatro diretórios de profundidade, incluindo a raiz do repositório.

Para .sln arquivos, não deve ter menos de dois diretórios de profundidade, incluindo a raiz do repositório.

Como faço para restaurar um feed NuGet privado?

Se o arquivo NuGet.Config for verificado no repositório e estiver ao lado do .sln ou no nível raiz do repositório, o App Center restaurará seus feeds NuGet privados quando eles forem adicionados, conforme mostrado no exemplo abaixo. As credenciais podem ser adicionadas com segurança usando variáveis de ambiente.

Para máquinas de compilação 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>

Para computadores de build do Windows, consulte UWP C#.

Se você tiver configurações complexas e precisar de mais informações, consulte Configurando o comportamento do NuGet.

Compilações travadas em CompileToNative

Se o build apresentar sintomas semelhantes aos descritos neste problema do GitHub, tente compilar apenas para ARM64 adicionando o seguinte argumento, conforme sugerido no problema:

<MtouchArch>ARM64</MtouchArch>

Falha na compilação com erro: o destino "_IsProjectRestoreSupported" não existe no projeto.

Você poderá enfrentar problemas de build se tiver um projeto UWP na solução em que, durante a restauração, seus erros foram ignorados silenciosamente na versão antiga do NuGet. Remover ou corrigir esse projeto UWP na solução pode resolver o problema. Por favor, veja os detalhes nesta edição do GitHub.