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 в интегрированной среде разработки и убедитесь, что конфигурация проекта (например, 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 указано значение Test , можно использовать следующий скрипт для сборки, запуска и отображения результатов:
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.
Сборки зависли в CompileToNative
Если при сборке возникают аналогичные симптомы, описанные в этой проблеме на GitHub, попробуйте выполнить сборку только для ARM64, добавив следующий аргумент, как показано в этой проблеме:
<MtouchArch>ARM64</MtouchArch>
Сбой сборки с ошибкой: целевой объект "_IsProjectRestoreSupported" не существует в проекте.
Вы можете столкнуться с проблемами сборки, если в решении есть проект UWP, в котором во время восстановления его ошибки были автоматически проигнорированы в старой версии NuGet. Удаление или исправление такого проекта UWP в решении может устранить проблему. Сведения о plese см. в этой проблеме на GitHub.