Ответ 1
По моему опыту, Xcode иногда путается о том, какой сертификат подписи использовать. У меня появилась привычка уходить и перезапускать Xcode после любого изменения настроек подписи кода (и создания чистой сборки), чтобы обойти эту проблему.
Я пытаюсь загрузить приложение в iPhone App Store, но я получаю это сообщение об ошибке из iTunes Connect:
Выбранный двоичный файл недействителен. Подпись была недействительной или не была подписана с сертификатом подачи Apple.
Примечание. Детали исходного вопроса были удалены, так как эта страница превратилась в репозиторий для всей информации о возможных причинах этого конкретного сообщения об ошибке.
Общие сведения о представлении приложений iPhone в App Store см. в разделе Шаги по загрузке приложения iPhone в AppStore.
По моему опыту, Xcode иногда путается о том, какой сертификат подписи использовать. У меня появилась привычка уходить и перезапускать Xcode после любого изменения настроек подписи кода (и создания чистой сборки), чтобы обойти эту проблему.
Я просто хотел упомянуть, что у меня тоже была проблема с zip из команды . Проблема заключается в том, как по умолчанию она обрабатывает символические ссылки. Использование:
zip -y -r myapp.zip myapp.app
Решена эта проблема.
У меня была такая же проблема, и я решил ее так:
Сертификаты свойств были установлены на моей машине разработки, а mobileprovision.embedded был включен в архив распространения. По прошествии часа или около того в Google Googling и рытье я нашел источник ошибки. Внутри Xcode я скопировал конфигурацию Release и создал новую конфигурацию дистрибутива, а затем изменил идентификатор подписи на свой сертификат распространения. Однако, хотя он был обновлен в графическом интерфейсе, файл проекта не был правильно обновлен.
Если вы столкнулись с той же ошибкой, загляните в каталог [ProjectName].xcodeproj для файла project.pbxproj и откройте его в своем любимом редакторе. Найдите раздел "Распространение". Мой сломанный выглядит так:
C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Distribution: Edward McCreary";
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = "iPhone Developer: Edward McCreary";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Developer: Edward McCreary";
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = "DB12BCA7-FE72-42CA-9C2B-612F76619788″;
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "DB12BCA7-FE72-42CA-9C2B-612F76619788″;
};
name = Distribution;
};
Вы можете видеть, что идентификатор подписывания и профиль обеспечения некорректны во втором разделе. Отредактируйте его, чтобы соответствовать первому разделу, перестроить, и вам должно быть хорошо идти. Последнее выглядело так:
C384C90C0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ARCHS = "$(ARCHS_STANDARD_32_BIT)";
CODE_SIGN_ENTITLEMENTS = "";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Distribution: Edward McCreary";
GCC_C_LANGUAGE_STANDARD = c99;
GCC_WARN_ABOUT_RETURN_TYPE = YES;
GCC_WARN_UNUSED_VARIABLE = YES;
PREBINDING = NO;
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "F00D3778-32B2-4550-9FCE-1A4090344400″;
SDKROOT = iphoneos2.2.1;
};
name = Distribution;
};
C384C90D0F9939FA00E76E41 /* Distribution */ = {
isa = XCBuildConfiguration;
buildSettings = {
ALWAYS_SEARCH_USER_PATHS = NO;
CODE_SIGN_IDENTITY = "iPhone Distribution: Edward McCreary";
"CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Distribution: Edward McCreary";
COPY_PHASE_STRIP = YES;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = GenPass_Prefix.pch;
INFOPLIST_FILE = Info.plist;
PRODUCT_NAME = GenPass;
PROVISIONING_PROFILE = "F00D3778-32B2-4550-9FCE-1A4090344400″;
"PROVISIONING_PROFILE[sdk=iphoneos*]" = "F00D3778-32B2-4550-9FCE-1A4090344400″;
};
name = Distribution;
};
изменено для защиты невинных
Такая же проблема, другое решение.
В моем случае я сжимал файл, используя zip -r myapp.zip myapp.app
Оказывается, команда zip ввернула узел. Сжатие его от искателя заставило его работать.
У меня была такая же проблема, и после нескольких попыток я удалил права .plist из прав на подписание кода (просто оставил его пустым), и он был создан нормально и загружен НАКОНЕЦ.
Удачи всем:-D
У меня была такая же проблема, но при создании я заметил, что в сборке не было добавлено обеспечение.
Исправление для меня состояло в том, чтобы установить сборку на iphone-устройство, где я обычно использую симулятор, но тогда он не будет включать профиль подготовки...
Это может быть ошибка noob. Обычно вы не можете подключиться к устройству, но когда вы это сделаете для распространения, вы можете.
Еще одна точка данных: какое-то время мое приложение прошло. Теперь я добавил поддержку покупок в приложении, и внезапно он завершился с ошибкой "Недопустимая двоичная/недействительная подпись". После тщательного изучения, я узнал, что значение идентификатора приложения в файле plients разрешено.
Это, скорее всего, связано с тем фактом, что я заменил профиль обеспечения с подстановочного на конкретный для приложения (необходимый для покупок в приложении). Неверный идентификатор приложения, присвоенный по старому профилю. Он не соответствовал идентификатору приложения в info.plist, но, по-видимому, iTunes прощал это.
Итак, чтобы повторить:
info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.*
в порядке, а
info.plist: com.mydomain.foo
dist.plist: com.mydomain.bar
Profile: com.mydomain.foo
вызывает "Недействительный двоичный файл".
Хорошо, повторив шаги несколько раз, я, наконец, успешно загрузил свое приложение.
Я точно не знаю, что исправил его, но до успешной попытки я закрыл Xcode и Firefox и перезапустил их. Я думаю, у одного из этих приложений была плохая джуй.
Здесь проблема, с которой я столкнулся: я добавил двоичный файл Subversion перед загрузкой. Сравнивая/застегивая двоичный файл, затем включали скрытые каталоги .svn, которые испортили подписание кода.
Я пробовал разные вещи после прочтения различных сообщений, в том числе выше. Что, наконец, сработало для меня, началось полностью! Я удалил каждый сертификат и профиль профилей, связанные с моим приложением.
Я воссоздал новый сертификат разработки и новый сертификат распространения. Я снова загрузил промежуточный сертификат. Затем я воссоздал как профиль разработки, так и профиль распространения.
После установки трех сертификатов (я заметил, что на этот раз у дистрибутива были как закрытые, так и открытые ключи) и два профиля подготовки (мой профиль распространения не был отмечен как не имеющий действительного сертификата!), все сработало.
Как только я принял решение отозвать все и только начал, для создания нового материала и его повторной установки потребовалось всего 5 минут.
Посмотрите эту ссылку для решения:
http://greghaygood.com/2010/09/04/invalid-binary-message-from-itunesconnect
Короткий ответ: "В итоге я дважды проверил свой info.plist и обнаружил что-то. Я добавил CFBundleIconFiles в соответствии с новыми рекомендациями, но в списке массивов была пустая запись. Я удалил это и повторно отправил, и это было наконец принято!"
У меня была аналогичная проблема, но в Monotouch. Я обнаружил, что мой профиль выпуска настроен на использование сертификатов разработчика. Он должен выглядеть так:
Кажется, эта проблема имеет много причин. Здесь мое решение:
Это относится ко всем, кто принадлежит нескольким группам разработчиков (например, вашим собственным приложениям и вашим компаниям).
Если вы создаете сборку с одним набором учетных данных и повторно подписываете ее с другим (например, для распространения adhoc/appstore), вы должны убедиться, что сборка была изначально построена и подписана с учетными данными, принадлежащими та же команда разработчиков iOS, что учетные данные для распространения, которые вы переписываете, принадлежат.
Поэтому не создавайте учетные данные "Indy Dev Inc", затем попробуйте развернуть с учетными данными "Company Inc". Убедитесь, что вы установили оба разработчика "Company Inc", а также учетные данные распространения и используете их.
Я разместил дополнительную информацию об этом в своем блоге: http://omegadelta.net/2011/06/09/fiendish-ios-code-signing-invalid-binary-issue/
У меня была та же проблема. Я был готов бросить полотенце на эту проблему, но я понял это, когда я пошел проверять свой код с помощью Murky. Я всегда просматриваю diff на файлах, которые были изменены до того, как я зарегистрировался. В этом случае я заметил, что файл project.pbxproj изменился.... и в разделе "Распространение" запись для "PROVISIONING_PROFILE [sdk = iphoneos *])" было пусто.
Завершение и перезапуск Xcode не помогло мне. Вместо этого я включил оба моих проекта и целевые настройки и изменил подписание кода, чтобы напрямую выбрать профиль распространения, а не полагаться на функцию автоматического выбора. Это привело к тому, что файл project.pbxproj заполнил правильные значения, даже если функция автоматического выбора предположительно выбрала тот же самый профиль, который я выбрал вручную.
Мне нужно пиво...
После проверки всех остальных исправлений, перечисленных здесь, мы зарегистрировали TSI с Apple. Следуя всем шагам в Техническая нота TN2250, наша проблема возникла из-за отсутствия или отсутствия закрытого ресурса. В нашем случае это было ._.DS_Store
.
".." называется файлом Apple Double и является результатом копирования папки проекта Xcode Project, * unzipped *, на и обратно из файловой системы, которая не поддерживает HFS + "вилки ресурсов" (используется для подписи кода). Эти дополнительные файлы ".." приводят к потере подтверждения подписи кода.
Чтобы очистить проблемные файлы Apple Double от папки проекта Xcode, запустите команду dot_clean в папке проекта Xcode, выполните чистую сборку, а затем закрепите ее и повторите попытку.
dot_clean /the/path/to/xcode/project
Примечание. Вы можете просто перетащить папку проекта в терминал, чтобы автоматически заполнить путь
При запуске команды нет сообщения, но сборка проекта может показать предупреждение о файле при следующем построении. Вы можете игнорировать это, приложение будет проверять и отправлять успешно.
У меня была аналогичная проблема, но я не использую права .plist. Однако после дюжины неудачных загрузок я проверил свой info.plist и обнаружил что-то. Мой массив CFBundleIconFiles имел пустую запись. Я удалил это и повторно представил, и он был наконец принят!
Серьезно, насколько сложно было бы Apple опубликовать такие ошибки проверки?Изменить: это не сразу apparant, где CFBundleIconFiles - это потому, что они используют другое имя. В представлении информации о проекте нажмите Ctl и выберите "Show Raw Keys/Values", а затем вы увидите ссылки на CFBundleWhatever. В этом случае редактора он пытался использовать несуществующий файл [email protected]
Устранено это, очистив файл myProject.xcodeproj(щелкните правой кнопкой мыши, откройте пакет), пакет содержит файлы от со-разработчика, после удаления этих проблем была решена
Для меня решение создало дистрибьюторскую сертификацию по адресу: Портал разработчиков Apple Developer.
Я получил недействительный двоичный файл, если приложение не использует удаленное push-уведомление, но я оставил код для регистрации push и делегатов callback для регистрации/получения удаленного уведомления без комментариев, даже если код не используется.
Это последнее. Мое последнее представление на прошлой неделе было прекрасным. На этой неделе он возвращает недействительный двоичный файл. К счастью, есть сообщение, объясняющее ошибку.
Для чего это стоит, я хочу добавить, что это, что исправил эту проблему для меня. У меня есть? (вопросительный знак) в названии моего приложения, которое вызывало ошибку.
У нас была эта проблема сегодня, но ответы здесь не помогли. Я, наконец, нашел проблему.
Удостоверьтесь, что используется выпадающее меню: Проект > Изменить Active Target "Имя_проекта" для изменения Подписи кодов к распределению. Я выбрал проект в панели "Группы и файлы" и с помощью кнопки "Информация", которая показывает ПРОЕКТ, а не TARGET - очень запутанная! Только понял, когда я выключил код в проекте и построил его, и он все еще хочет ввести код!
Я думаю, именно поэтому в постели Эдди он должен был изменить его на уровне project.pbxproj
Также на оригинальном посте в 1-м шаге: 1. В Xcode выберите целевое устройство Device | Release Разумеется, это должно быть целевое приложение Device | Distribution? (при условии, что этот скопированный релиз и переименовал его в соответствии с инструкциями Apple в Provisioning Portal)
Мои два цента:
Загрузите последнюю версию загрузчика приложений. Я только что обновился и теперь получаю другое сообщение об ошибке.
Я просто пережил эту проблему (снова), но на этот раз я обнаружил, что мой профиль распространения имеет статус "Недействительный". Если вы считаете, что все остальное правильно, дважды проверьте статус на портале и обновите/перезагрузите все, что не находится в активном состоянии.
Я получил Invalid Binary после загрузки приложения, не отслеживая сообщения по электронной почте о том, почему это не удалось. Я попытался сделать пару вещей сразу, и я не уверен, что из следующего действительно исправил его:
У меня возникла проблема с этим и 4.3 GM SDK. Одно из наших приложений не сделало бы его прошлой загрузкой. Оказалось, что это вопрос профилирования. Я восстановил профиль магазина приложения, и он работал нормально.
Мое решение включало создание нового идентификатора приложения. Я точно не знаю, почему это исправлено, но я подозреваю, что это были несоответствующие идентификаторы пакетов. Создание нового идентификатора приложения заставил меня убедиться, что мое приложение и iTunes ожидали того же.
Другое решение:
Для меня просто установка сертификатов "Release" под "подписание кода" исправлена. Первоначально они были установлены на "Не вводить код".
Для меня проблема была решена путем сохранения изображения PNG с опцией без чередования. В предыдущих версиях разрешалось чередование png, но известно, что это изображение может вызвать недопустимый двоичный файл.
Мое яблочное сообщение: Коррумпированный файл значков. Файл значка[email protected] выглядит искаженным. Ваш значок не должен быть чересстрочным PNG файлом.
Вы можете увидеть, чередуется ли PNG с помощью команды "файл" в терминале: Eva-Madrazos-MacBook-Pro-2: Интерактивные объявления GQ 7 Eva $file *.png Default.png: данные изображения PNG, 320 x 480, 8 бит/цвет RGB, без чередования
Удачи, Eva
Я хочу указать на возможность отправлять электронную почту Apple и просить их проверить их журналы. Я сделал именно это, сначала попробовав множество вещей. Необходимо было напомнить их почти через четыре недели, но, наконец, они ответили и указали на точное место вопроса.
Проблема в моем случае состояла в том, что я ранее пробовал другие иконки приложений, и ссылка на старое изображение все еще оставалась в "CFBundleIcons". Я использовал функцию перетаскивания, чтобы установить значок, но я не заметил, что старый контент не был полностью очищен до добавления новой ссылки.
Чтобы увидеть неисправную ссылку, необходимо было развернуть стрелки для просмотра каждого элемента в файле plist. Один из советов - щелкнуть правой кнопкой мыши в файле и выбрать опцию для просмотра исходного содержимого. Таким образом вам не нужно ничего расширять.
Я попробовал все другие предлагаемые решения, но ничего не помогло.
Я закончил создание нового проекта Xcode и скопировал в него весь мой код и ресурсы. Это сделал трюк, и мое приложение попало в очередь просмотра.
Я также могу рекомендовать Яркие технические примечания о подписании кода для отладки/проверки.