Xamarin
Внимание
Центр приложений Visual Studio планируется выйти на пенсию 31 марта 2025 г. Хотя вы можете продолжать использовать Центр приложений Visual Studio до тех пор, пока он не будет полностью прекращен, существует несколько рекомендуемых вариантов, которые можно перенести.
Дополнительные сведения о временной шкале поддержки и альтернативах.
Сборки Xamarin.iOS из файла решения (.sln) вместо файла проекта (CSPROJ)
Когда сборки Xamarin.iOS выполняются из файла решения (.sln), может потребоваться проверить несколько элементов.
Проекты Android и UWP должны быть отключены в коде для конфигураций сборки, предназначенных для сборок iOS. Перейдите в сопоставления конфигурации решения и для всех сопоставлений, предназначенных для iPhone и iPhoneSimulator, снимите флажок всех проектов, предназначенных для разных платформ. Эта конфигурация гарантирует, что при начале .sln сборки она не попытается создать другие проекты.
Мои сборки Xamarin.iOS завершаются ошибкой, утверждая, что мне нужно предоставить сведения о подписи
Если сборки Xamarin.iOS не подписаны, но процесс сборки требует подписывания, вероятно, это связано с тем, что вы выбрали Sign builds: Off в конфигурации ветви Центра приложений.
Если журнал сборки содержит следующее:
RequireProvisioningProfile: True.
Это означает, что сам проект настроен для подписывания и применяет подписывание, несмотря на конфигурацию Центра приложений.
Чтобы устранить эту проблему, откройте пакет сборки > iOS в > интегрированной среде разработки и убедитесь, что конфигурация проекта (например, Debug|iPhoneSimulator) не содержит никаких сведений о подписи, отличных от автоматического.
Сбой сборки Xamarin.Android: нет файлов APK.
Одна из распространенных причин сбоя сборки во время задачи Postprocess Xamarin Android — неправильное значение свойства в <OutputPath> файле проекта Android. Чтобы проверить его, перейдите к выходным данным сборки > Xamarin.Android > > и убедитесь, что конфигурация сборки (отладка и выпуск) указывает на расположение по умолчанию. Обычно это должно быть YourProjectDir/bin/$(Configuration).
Я настраиваю ветвь приложения Xamarin.iOS для сборки без подписывания, но моя сборка завершилась ошибкой, утверждая, что мне нужно предоставить сведения о подписи
Если выбрана Sign builds: Off конфигурация ветви Центра приложений, а журнал сборки содержится RequireProvisioningProfile: True, значит, что сам проект настроен для подписывания и попытается применить подпись, несмотря на конфигурацию Центра приложений. Чтобы исправить его, откройте сборку пакета iOS для сборки пакета > > iOS в интегрированной среде разработки и убедитесь, что конфигурация проекта (например, Debug|iPhoneSimulator) не содержит никаких сведений о подписи, отличных от автоматического.
Сборка симулятора Xamarin.iOS не удается установить в симулятор iOS с ошибкой "Не удалось выполнить chmod ... /Appname.iOS.app/Appname.iOS: нет такого файла или каталога".
При создании проекта Xamarin.iOS в Visual Studio конфигурация по умолчанию для iPhoneSimulator имеет поддерживаемые архитектуры i386 + x86_64 . Файл .app , который создается из такой конфигурации, не сможет отправиться в симулятор. Откройте сборку iOS и > измените конфигурацию iPhoneSimulator на поддерживаемые архитектуры на i386 или x86_64.>
Сбой сборки Xamarin с ошибкой MSB4018: не удалось выполнить задачу WriteRestoreGraphTask.
Похоже, решение содержит проекты PCL или более старых проектов .NET Standard вместе с более новыми проектами .NET Standard. Это означает, что они могут содержать оба PackageTargetFallback и AssetTargetFallback ссылки в .csproj файлах. Журналы сборки также будут содержать такие сообщения:
error MSB4018: NuGet.Commands.RestoreCommandException: PackageTargetFallback and AssetTargetFallback cannot be used together. Remove PackageTargetFallback(deprecated) references from the project environment.
Чтобы устранить эту проблему, удалите PackageTargetFallback (как правило, в старых файлах PCL .csproj ) или переименуйте его в AssetTargetFallback? Решение также описано в этом потоке StackOverflow.
Сбой сборки Xamarin: этот проект ссылается на пакеты NuGet, отсутствующие на этом компьютере.
Похоже, что не все пакеты были восстановлены для сборки приложения. Журналы сборки также будут содержать такие сообщения:
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?)
Чтобы устранить эту проблему, можно использовать скрипт appcenter-pre-build.sh предварительной сборки со следующими командами, которые восстанавливают все пакеты для каждого решения в репозитории:
#!/bin/bash
find $APPCENTER_SOURCE_DIRECTORY -name '*.sln' -print0 | xargs -0 -n1 nuget restore -DisableParallelProcessing
Я хочу запустить модульные тесты для приложения Xamarin
Чтобы запустить модульные тесты в сборках Xamarin, используйте скрипт после сборки. Например, если в проекте на основе NUnit есть тест в имени, можно использовать следующий скрипт для сборки, запуска и отображения результатов:
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 {} \;
Я получаю ошибку: не найдены проекты и не найдены конфигурации для сборок Xamarin
Это может быть проблема глубины репозитория, в которую .csproj находится и .sln находится. Существует ограничение в текущем анализаторе из-за причин производительности.
Для .csproj файлов не должно быть меньше четырех каталогов, включая корневой каталог репозитория.
Для .sln файлов он не должен быть ниже двух каталогов глубоко, включая корневой каталог репозитория.
Разделы справки восстановить частный веб-канал NuGet?
Если файл NuGet.Config проверяется в репозитории и сидит рядом с .sln или на корневом уровне репозитория, Центр приложений восстанавливает частные веб-каналы NuGet при добавлении, как показано в приведенном ниже примере. Учетные данные можно добавить безопасно с помощью переменных среды.
Для компьютеров сборки 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>
Для компьютеров сборки Windows см. раздел UWP C#.
Если у вас есть сложные конфигурации и требуется дополнительная информация, можно обратиться к настройке поведения NuGet.
Сборки застряли в КомпиляцииToNative
Если при сборке аналогичные симптомы, как описано в этой проблеме GitHub, попробуйте выполнить сборку только для ARM64, добавив следующий аргумент, как показано в этой проблеме:
<MtouchArch>ARM64</MtouchArch>
Сбой сборки с ошибкой: целевой объект "_IsProjectRestoreSupported" не существует в проекте.
При наличии проекта UWP в решении, в котором во время восстановления его ошибки были автоматически проигнорированы в старой версии NuGet. Удаление или исправление такого проекта UWP в решении может устранить проблему. Сведения об этой проблеме GitHub см. в plese.