Не может загрузить двоичный файл приложения на App Store
Мы наконец перешли к сути дела представления нашего первого приложения для iPhone к App Store (или попытка к), но я, может казаться, не заставляю Подключение iTunes принимать загрузку.
Я делал попытку через обоих веб-сайта ("Двоичный файл, который Вы загрузили, было недопустимо. Подпись была недопустима, или она не была подписана с сертификатом представления Apple".) и Загрузчик Приложения ("Info.plist не содержит CFBundleResourceSpecification").
После большого чтения (включая вопросы как они), перечитывание и поиск с помощью Google, я могу сказать что:
- Я уверен, что идентификатор пакета соответствует AppID.
- Существует Icon.png, это - файл PNG на 57x57 пкс, и это - точное имя в Info.plist.
- Я делаю устройство, не средство моделирования, сборку.
- Процесс подписания успешно выполняется: результаты сборки показывают это и выполнение
codesign -vvvv MyApp.appне указывает ни на какие проблемы. - Нет никаких странных символов в пути к zip-файлу.
- Я удалил папку сборки и восстановил двоичный файл довольно много раз.
Теперь, это верно, что в созданном приложении, Info.plist не содержит a CFBundleResourceSpecification ключ, но мне нисколько не ясно, куда то значение должно прибыть из, или что еще я должен добавить для создания этой работы. (Единственная ссылка, я могу найти поиск Apple использования, является некоторой информацией о версии подписывания кода..., но, поскольку я упомянул выше, шаг подписывания кода успешно выполняется, насколько я могу сказать.)
Кто-либо натыкался на какие-либо объяснения этой проблемы, что я уже не упомянул?
Править: Вот (немного отредактирован) вывод от шага подписывания кода сборки, FWIW:
снимок экрана подписывания кода http://img70.yfrog.com/img70/8988/codesign.png
4 ответа
Проблема, похоже, заключалась в том, что я использовал json-framework в моем приложении и включение его в качестве дополнительного SDK согласно инструкциям в вики . Я предполагаю, что XCode запутался из-за наличия> 1 SDK и поэтому не смог найти ResourceRules.plist по умолчанию, как предполагалось.
Я нашел два решения (в любом случае, обходные пути):
- Используйте параметр сборки «Путь к правилам ресурса для подписи кода» (который по умолчанию пуст), чтобы указать путь к файлу, который должен использовать XCode:
$ (SDKROOT) /ResourceRules.plist. Это работает, и кажется достаточно безобидным, но разочаровывает в том смысле, что XCode должен быть в состоянии понять это самостоятельно. (Я нашел это решение в очень старой проблеме , зарегистрированной на json-framework.) - Не используйте подход SDK. Вместо этого просто включите файлы непосредственно в проект и обновите операторы
#importлокальными путями. В конечном итоге я выбрал именно такой подход, поскольку мы приняли общее решение объединить все внешние зависимости в сам проект (чтобы другим разработчикам было проще настраивать свои машины, чтобы начать работу).
Я не уверен, ошибка ли это в XCode или что-то не так с json-framework, но на всякий случай я зарегистрировал проблему последнего.
ОБНОВЛЕНИЕ, 30 июня 2010 г .: проблема, которую я зарегистрировал, закрыта, и г-н Браутасет планирует удалить поддержку опции SDK в следующем выпуске (2.3) проекта. Кроме того, код теперь находится на GitHub , хотя страницы кода Google все еще существуют.
Вы уверены, что вы строите С распределением, в отличие от разработки, сертификата и мобильной связи?
Выполняете ли вы какие-либо операции по созданию/копированию/перетаскиванию из командной строки? Если да, то нужно очень внимательно относиться к символическим ссылкам. .app поставляется с подкаталогом в качестве символической ссылки на другой каталог, и если скопировать его или заархивировать без нужных флагов, то содержимое будет скопировано в печатном виде.
Это случилось со мной - и самое ужасное в том, что ad-hoc работает нормально без символической ссылки, поэтому вы не замечаете проблему, пока не построят магазин приложений.
Абзацы в документах с открытым текстом обычно разделяются двумя или более разделителями строк. Разделителем линии может быть линия (\n ), каретка-возврат (\r ) или каретка-возврат, за которой следует линия-возврат (\r\n ). Эти три типа разделителей обычно связаны с операционными системами, но любое приложение может свободно писать текст, используя любой тип разделителя строк. Фактически, текст, собранный из различных источников (например, веб-страницы), может содержать два или более видов разделителей. Когда приложение читает текст , независимо от того, на какой платформе оно работает, оно всегда должно проверять наличие всех трех типов разделителей строк.
BufferedReader # readLine () делает это, но, конечно, считывает только одну строку за раз. Простая проза обычно возвращается в виде чередующейся последовательности непустых строк, представляющих абзацы, и пустых строк, представляющих места между ними. Но не рассчитывайте на это; следите за несколькими пустыми строками и помните, что «пустые» строки могут содержать пробелы, такие как пространства (\u0020 ) и TAB (\u0009 ).
Если вы решите не использовать BufferedReader , возможно, вам придется написать код обнаружения с нуля. Java ME не включает поддержку regex, поэтому split () и java.util.Scanner недоступны; StringTokenizer не различает один символ разделителя и несколько символов в строке, если не используется параметр returnDelims . Затем он возвращает разделители по одному символу за раз, так что вы все равно должны написать свой собственный код, чтобы выяснить, какой разделитель вы смотрите, если есть.
Самый простой способ сделать это - построить шаблон для хранения данных и разбора файлов в ram, конечно, это не самый эффективный способ.
Что-то вроде...
НЕКОТОРЫЕ/МЕСТОПОЛОЖЕНИЕ/Имя файла > > > содержимое файла здесь, бла-бла-бла <<< SOME/OTHER/LOCATION/File2Name > > > содержимое другого файла здесь < < <
Затем для вывода каталога с помощью regex найдите все строки, оканчивающиеся на > > >, затем выполните синтаксический анализ до X-ой косой черты (на основе числа косых черт в папке поиска) и выполните поиск с учетом регистра (в), исходя из того, нужно ли учитывать регистр. Конечно, как я уже упоминал, загружая его в память, вы можете искать хэшмап «ключ - > значение», который, вероятно, будет намного проще.
-121--3397751-Я предполагаю, что вы загружаете ZIP-файл.
Я только что проверил приложение, которое я загрузил, и CFBundleResoureSpecification находится только в подписанных версиях (то есть в компоновке устройства).