Проект Xcode 4: утилита для очистки файла pbxproj?

У меня есть проект Xcode 4 с двумя целями, один для iPhone и один для iPad. Если я нажимаю на цель iPad и пытаюсь перейти в Build Settings Xcode 4:

Обнаружено несколько утверждений. Первое утверждение было: НЕИСПРАВНОСТЬ НЕИСПРАВНОСТИ в /SourceCache/IDEXcode 3ProjectSupport/IDEXcode3ProjectSupport-269/Xcode3Sources/XcodeIDE/Frameworks/DevToolsBase/pbxcore/FileTypes/../PBXFileType.m:594 Подробности: имя_файла должно быть непустой строкой, но оно равно nil

Очевидно, что файл pbxproj имеет плохую ссылку там где-то - вероятно, вызванный многими ручными слияниями, которые я вынужден сделать с помощью git. Есть ли способ очистить файл pbxproj, чтобы он снова работал правильно или чтобы определить, какая строка вызывает проблему? Я бы действительно предпочел не создавать проект с нуля.

Ответ 1

Я пробовал метод gorbster без успеха (хотя в прошлом он решил подобные проблемы для меня).

Я зашел в мой project.pbxproj файл (внутри пакета .xcodeproj для проекта) и нашел две строки, которые выглядели немного подозрительными, оба вида:

53A45F8F138FE6F40077017F /* (null) in Resources */ = {isa = PBXBuildFile; };

Я удалил строки, и voilà: я снова могу получить доступ к моим настройкам сборки для этой цели.

Не знаю, как они попали туда в первую очередь. Я бы предположил, что это связано с неправильным слиянием под SVN.

Ответ 2

В этот же вопрос встал сегодня утром после того, как вытащил коллегу.

Я смог исправить это следующим образом:

  • Закрыть Xcode
  • Откройте .xcodeproj пакет в Finder
  • Удалите файл project.xcworkspace
  • Откройте папку xcuserdata​​strong > и удалите папку для пользователя .xcuserdatad.
  • Повторно открыть Xcode и проект

Я потерял некоторые незначительные пользовательские настройки (история файлов и вкладок и т.д.), но теперь могу без проблем щелкнуть все (9) моих целей. Оказывается, мой коллега был на более ранней версии Xcode, но я не уверен, что это способствовало сбою IDE.

Ответ 3

Бен Мошер нашел решение. И да, это связано с проблемой слияния SVN.

Как мы работаем в команде с SVN, ошибка возникает часто, поэтому я написал bash script:

#!/bin/bash
sed "/(null) in/d" project.pbxproj > tmp_project.pbxproj
mv tmp_project.pbxproj project.pbxproj

Ответ 4

Попробуйте выполнить следующие шаги, пока ваш XCode будет закрыт.

  • Перейдите в файл {YOUR_PROJECT}.xcodeproj в поиске.

  • Щелкните правой кнопкой мыши файл {YOUR_PROJECT}.xcodeproj.

  • Выберите Показать содержимое пакета..., это откроет содержимое на другом экране Finder.

  • Откройте файл project.pbxproj и найдите все строки с строкой (null) в "

  • Удалите все строки с (null) в... не беспокойтесь.... удалите уверенно.

  • Сохраните файл.

Теперь откройте свой проект с помощью XCode и попробуйте открыть вкладку "Настройки сборки"... надеюсь, ваша проблема будет решена.

Спасибо, Mohamed.

Ответ 5

Щелкните правой кнопкой мыши файл .xcodeproj и "Показывать содержимое пакета".

Затем откройте файл project.pbxproj с TextEdit и дубликат.

Сохранять дубликат файла в любом месте с тем же именем и расширением. (Project.pbxproj)

И замените на старый файл.

Ответ 6

Если вы также попробовали ссылочные строки удаления (null) и удалили папку для пользователя .xcuserdatad, и это не сработало, вот потенциальное решение. FYI... Это было связано с Xcode 7.3.1.

Вот сценарий, с которым я столкнулся:

Я столкнулся с этой проблемой, вызванной наличием "двойных" ветвей в репозитории git (т.е. одна ветка BRANCH_A является ветвью развития с некоторыми функциями, не подлежащими выпуску, а другая - с теми же коммитами, за исключением для новых функций, назовите его BRANCH_B).

Процесс разработки работает следующим образом: начните с BRANCH_B, создайте ветвь фиксации CHANGE_C, внесите изменения и зафиксируйте, затем проверьте BRANCH_A, создайте ветвь фиксации, затем измените вишневые изменения из CHANGE_C. BRANCH_A отслеживает BRANCH_B таким образом, с его дополнительными файлами функций.

В моем случае (по какой-то причине во время перезагрузки на сопутствующих изменениях с пульта, который отслеживает BRANCH_B, файл проекта для BRANCH_B поврежден.

В этом случае решение состоит в том, чтобы сохранить копию файла проекта для BRANCH_A (что хорошо и компилирует), затем проверить BRANCH_B и заменить файл проекта копией.

Изначально он не будет компилироваться, пока все ссылки на файлы функций (из BRANCH_A) не будут удалены из целевых фаз сборки > Скомпилировать источники.

Отлично работает.