Xamarin
Importante
O Visual Studio App Center está programado para ser desativado em 31 de março de 2025. Embora você possa continuar a usar o Visual Studio App Center até que ele seja totalmente desativado, há várias alternativas recomendadas para as quais você pode considerar migrar.
Meu Xamarin.iOS compila o build 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 talvez você queira marcar.
Projetos Android e UWP devem ser desabilitados em seu código para configurações de build destinadas a builds do iOS. Acesse os mapeamentos de configuração da solução e, para todos os mapeamentos direcionados ao iPhone e ao iPhoneSimulator, desmarque todos os projetos destinados a diferentes plataformas. Essa configuração garante que, quando o começar a .sln compilar, ele não tentará compilar outros projetos.
Meus builds 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 será porque você selecionou Sign builds: Off na configuração do branch do App Center.
Se o log de build contiver:
RequireProvisioningProfile: True.
Isso significa que o próprio projeto está configurado para assinatura e aplica 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 verifique se a configuração do projeto (por exemplo, Depurar|iPhoneSimulator) não contém nenhuma informação de assinatura diferente de Automática.
Minha compilação do Xamarin.Android falhou com Erro: nenhum arquivo APK encontrado.
Um motivo comum para uma falha de build durante a tarefa postprocess do Xamarin Android é um valor incorreto na <OutputPath> propriedade no arquivo de projeto do Android. Para marcar-lo, vá para 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 minha compilação 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 o log de build contém RequireProvisioningProfile: True, isso significa que o 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 no IDE e verifique se a configuração do projeto (por exemplo, Depurar|iPhoneSimulator) não contém nenhuma informação de assinatura diferente de Automática.
Minha compilação do simulador do Xamarin.iOS falha ao ser instalada no Simulador do iOS com o erro "Falha ao criar chmod ... /Appname.iOS.app/Appname.iOS : nenhum arquivo ou diretório desse tipo".
Quando você cria um projeto Xamarin.iOS no Visual Studio, a configuração padrão para iPhoneSimulator tem arquiteturas com suporte para i386 + x86_64 . O arquivo .app que é compilado com base nessa configuração não será carregado em um simulador. Abra Opções > de Projeto Compilar > Build do iOS e, para iPhoneConfiguração do iPhoneSimulator, altere as arquiteturas com suporte para i386 ou x86_64.
Minha compilação 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 mais recentes do .NET Standard. Isso significa que eles podem conter PackageTargetFallback referências e AssetTargetFallback em .csproj arquivos. Os logs de build 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 resolve 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 StackOverflow.
Meu build do Xamarin falha com o erro: este projeto faz referência a pacotes NuGet ausentes neste computador.
Parece que nem todos os pacotes foram restaurados para criar seu aplicativo. Os logs de build 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 resolve esse problema, você pode usar o script appcenter-pre-build.shde 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 pós-build. Por exemplo, quando o projeto baseado em NUnit tiver Test no nome, você poderá usar o script a seguir 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 o .csproj e .sln estão localizados. Há uma limitação no analisador atual devido a motivos de desempenho.
Para .csproj arquivos, ele não deve ser inferior a quatro diretórios profundos, incluindo a raiz do repositório.
Para .sln arquivos, ele não deve ser inferior a dois diretórios profundos, incluindo a raiz do repositório.
Como fazer restaurar um feed do NuGet privado?
Se o arquivo NuGet.Config for verificado no repositório e estiver sentado 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 computadores de build do 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 C#UWP.
Se você tiver configurações complexas e precisar de mais informações, consulte Configurando o comportamento do NuGet.
Builds travados no CompileToNative
Se o build apresentar sintomas semelhantes, conforme descrito neste problema do GitHub, tente compilar somente para ARM64 adicionando o seguinte argumento, conforme sugerido no problema:
<MtouchArch>ARM64</MtouchArch>
Falha no build 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 silenciosamente ignorados na versão antiga do NuGet. Remover ou corrigir esse projeto UWP na solução pode resolve o problema. Veja os detalhes neste problema do GitHub.