Od jakiegoś czasu pracuję nad stworzeniem aplikacji na iPhone'a. Dzisiaj, gdy moja bateria była słaba, pracowałem i ciągle zapisywałem pliki źródłowe, a potem skończyło się zasilanie ...
Teraz, kiedy ponownie podłączyłem komputer i nabiera mocy, próbuję otworzyć plik projektu i pojawia się błąd:
Nie można otworzyć projektu
Nie można otworzyć projektu ..., ponieważ nie można przeanalizować pliku projektu.
Czy jest sposób, o którym ludzie wiedzą, że mogę się z tego wyleczyć? Próbowałem użyć starszego pliku projektu i ponownie go wstawić, a następnie skompilować. Daje mi dziwny błąd, prawdopodobnie dlatego, że nie znajduje wszystkich plików, których chce ...
Naprawdę nie chcę odbudowywać mojego projektu od zera, jeśli to możliwe.
EDYTOWAĆ
Ok, zrobiłem różnicę między tym a nieco starszym plikiem projektu, który działał i zobaczyłem, że plik jest uszkodzony. Po ich scaleniu (części dobre i najnowsze) już działa.
Świetne uwagi dotyczące SVN. Mam jeden, ale przy próbie zsynchronizowania z nim XCode było trochę dziwactwa. Na pewno spędzę z nim teraz więcej czasu ... ;-)
Odpowiedź Mahometa była bardzo pomocna (i pomogła doprowadzić do mojej poprawki). Jednak samo usunięcie >>>>>>> ======= <<<<<<< nie wystarczyło, aby naprawić problem parsowania w projekcie.pbxproj (dla mnie) podczas zachowywania zmian z obu gałęzi po scaleniu.
Miałem konflikt scalania w sekcji PBXGroup (której początek wskazuje komentarz blokowy, taki jak ten: / * Begin PBXGroup section * /) pliku project.pbxproj. Jednak napotkany problem może wystąpić również w innych miejscach w pliku project.pbxproj.
Poniżej znajduje się uproszczenie napotkanego konfliktu scalania:
<<<<<<< HEAD id = { isa = PBXGroup; children = ( id ); name = "Your Group Name"; ======= id = { isa = PBXGroup; children = ( id ); name = "Your Group Name"; >>>>>>> branch name sourceTree = "<group>"; };
Kiedy usunąłem znaczniki konfliktu scalania, oto co mi zostało:
id = { isa = PBXGroup; children = ( id ); name = "Your Group Name"; id = { isa = PBXGroup; children = ( id ); name = "Your Group Name"; sourceTree = "<group>"; };
Zwykle usunięcie znaczników konfliktu scalania rozwiązałoby problem z analizą w pliku project.pbxproj i przywróciłoby integralność obszaru roboczego. Tym razem tak się nie stało.
Poniżej przedstawiam, co zrobiłem, aby rozwiązać problem:
id = { isa = PBXGroup; children = ( id ); name = "Your Group Name"; sourceTree = "<group>"; }; id = { isa = PBXGroup; children = ( id ); name = "Your Group Name"; sourceTree = "<group>"; };
Właściwie musiałem dodać 2 linie na końcu pierwszej PBXGroup.
Widać, że gdybym zdecydował się odrzucić zmiany z jednej z głowic lub z gałęzi scalającej, nie byłoby problemu z analizą! Jednak w moim przypadku chciałem zachować obie grupy, które dodałem z każdej gałęzi, a samo usunięcie znaczników łączenia nie wystarczyło; Musiałem dodać dodatkowe linie do pliku project.pbxproj, aby zachować prawidłowe formatowanie.
Tak więc, jeśli napotkasz problemy z analizowaniem po tym, jak myślałeś, że rozwiązałeś wszystkie konflikty scalania, możesz przyjrzeć się bliżej plikowi .pbxproj i upewnić się, że nie ma żadnych problemów z formatowaniem!
źródło
Otrzymałem dokładnie ten sam błąd, ponieważ Cordova pozwoli ci stworzyć projekt ze spacjami, a Xcode nie wie, jak sobie z tym poradzić.
źródło
Miałem podobny problem.
Poniżej znajdują się kroki, aby rozwiązać ten problem:
Przejdź do folderu, w którym znajduje się plik
projectName.xcodeproj
.Kliknij prawym przyciskiem myszy i wybierz opcję „
Show Package Contents
”. Będziesz mógł zobaczyć listę plików z.pbxproj
rozszerzeniem.Wybierz
project.pbxproj
. Kliknij prawym przyciskiem myszy i otwórz ten plik za pomocą 'Text Edit
'.Będzie można zobaczyć
<<<<<< .mine
,============
i>>>>>>>>>> .r123
. Są to generalnie konflikty, które pojawiają się podczas pobierania aktualizacji z SVN. Usuń je i zapisz plik.Teraz będziesz mógł otworzyć projekt bez żadnego komunikatu o błędzie .
źródło
Analiza wizualna pliku projektu Xcode nie pomogła mi zlokalizować błędu po scaleniu. Po przejrzeniu syslog znalazł taką linię, gdy Xcode próbował przeanalizować plik:
2/7/14 12:39:12.792 PM Xcode[9949]: CFPropertyListCreateFromXMLData(): Old-style plist parser: missing semicolon in dictionary on line 4426. Parsing will be abandoned. Break on _CFPropertyListMissingSemicolon to debug.
Po naprawieniu ten projekt można otworzyć ok.
źródło
Przeanalizuj składnię pliku projektu. Sprawdź to w swoim projekcie w terminalu:
plutil -lint project.pbxproj
Spowoduje to wyświetlenie błędów z parsera.
Możliwy problem : niektóre projekty ustawiają strategię scalania git
union
dla plików projektów. Działa to przez większość czasu, ale po cichu zabije plik projektu, jeśli się nie powiedzie. Ta strategia jest zdefiniowana w.gitattributes
pliku w repozytorium.źródło
Ostatnio napotkałem ten sam problem podczas próby połączenia mojego oddziału ze zdalnym oddziałem. Jednak żadne z powyższych rozwiązań nie wydawało się odpowiednie dla mojego problemu.
Nie było konfliktów scalania między plikiem project.pbxproj w mojej gałęzi lub gałęzi zdalnej. Jednak mój plik ProjectName.xcodeproj odmówiłby otwarcia z tego samego powodu, co pokazano w zadanym pytaniu.
Moim rozwiązaniem było przejrzenie pliku project.pbxproj za pomocą edytora tekstu i stwierdzenie, czy nie ma żadnych nieprawidłowości w składni pliku (np. Dodatkowy nawias klamrowy). Przyspieszyłem ten proces, koncentrując się na wierszach, które zostały wstawione lub usunięte w starym pliku w porównaniu do scalonego pliku. Przy bliższym przyjrzeniu się stwierdziłem, że przyczyną mojego problemu było powtórzenie następującej linii:
xxxxxxxxxxxxx /* [CP] Check Pods Manifest.lock */ = {
w moim połączonym pliku. Doprowadziło to do niezamkniętego nawiasu klamrowego i w konsekwencji nieprawidłowej składni pbxproj. Usunięcie powyższej linii rozwiązało mój problem.
źródło
Właśnie napotkałem ten sam problem. Usunąłem wygenerowane ciągi przez git jak zawsze, ale Xcode nadal odmawiał otwarcia pliku .xcodeproj. Ale wszystko było w porządku, żadnych brakujących nawiasów itp. W końcu próbowałem wyjść z Xcode i otworzyć projekt, kiedy Xcode został zamknięty … wtedy zadziałało. Mam nadzieję, że to komuś pomoże.
EDYTOWAĆ:
do rozwiązywania konfliktów w pliku .xcodeproj możesz użyć tego przydatnego skryptu:
Oto skrypt:
projectfile =
find -d . -name 'project.pbxproj'
projectdir =echo *.xcodeproj
projectfile = "$ {projectdir} /project.pbxproj" tempfile = "$ {projectdir} /project.pbxproj.out" savefile = "$ {projectdir} /project.pbxproj.mergesave"cat $ projectfile | grep -v "<<<<<<< HEAD" | grep -v "=======" | grep -v "^ >>>>>>>"> $ tempfile mv $ tempfile $ projectfile
Uruchom go z terminala za pomocą polecenia sh: sh replace_conflicts.sh
źródło
resolve_conflicts.sh: line 1: -d: command not found resolve_conflicts.sh: line 3: $tempfile: ambiguous redirect
Kroki, które należy wykonać: - 1. Przejdź do folderu, w którym znajduje się nazwa Twojego projektu.xcodeproj 2. Kliknij prawym przyciskiem myszy i wybierz opcję „Pokaż zawartość pakietu”. Będziesz mógł zobaczyć listę plików z rozszerzeniem .pbxproj. 3. Wybierz project.pbxproj. Kliknij prawym przyciskiem myszy i otwórz ten plik za pomocą opcji „Edycja tekstu”. 4. Będziesz mógł zobaczyć <<<<<<, ============ i >>>>>>>>>>. Są to generalnie konflikty, które pojawiają się podczas pobierania aktualizacji z Sourcetree / SVN / GITLAB. Usuń je i zapisz plik. 5. Teraz będziesz mógł otworzyć projekt bez żadnego komunikatu o błędzie.
źródło
Przywróć plik project.pbxproj
svn revert --filename--
źródło
Wygląda na to, że będziesz musiał utworzyć nowy projekt w Xcode, przejść do starego katalogu i przeciągnąć wszystkie pliki źródłowe, końcówki i zasoby do paska bocznego plików Xcode w nowym projekcie. Nie powinno to zająć więcej niż kilka minut, chyba że naprawdę wykonałeś dużo pracy z niestandardowymi ustawieniami kompilacji lub celami. Albo to, albo wróć do ostatniego wpisu w kontroli źródła i ręcznie dodaj wszystkie pliki kodu, które zmieniły się od teraz do tego czasu.
źródło
A gdy wszystko znów zacznie działać, powinieneś rozważyć użycie czegoś takiego jak subversion lub mercurial do tworzenia kopii zapasowych i kontroli wersji. Pamiętaj, że elektrony nie zawsze idą tam, gdzie powinny, tworzą kopie zapasowe wcześnie i często!
źródło
zmień nazwę bieżącego folderu projektu i moduł pobierania tego samego projektu, a następnie dodaj zmiany w bieżącym pliku.
źródło
Wystarczy sprawdzić plik project.pbproject i porównać z działającą wersją pliku projektu.
Często zdarza się to, gdy występują konflikty z systemu kontroli wersji, takiego jak zamieszczony tutaj: Plik użytkownika nie może zostać przeanalizowany w subversion w MAC iPhone SDK
źródło
Spróbuj znaleźć HEAD i _HEAD między wierszami i usuń te słowa w pliku project.pbxproj. Przed wykonaniem tej czynności wykonaj kopię zapasową tego pliku.
źródło
Idź do PhoneGapTest >> platforma Następnie usuń folder ios, a następnie przejdź do terminala, a następnie wpisz: sudo phonegap build ios, po czym możesz uruchomić projekt
źródło
Cofając, możesz cofnąć ściągnięty kod.
Jeśli chcesz cofnąć to żądanie ściągnięcia, po prostu umieść to polecenie w ścieżce projektu
->
git merge --abort
źródło
W przypadku, gdy nie znalazłeś w Text === lub <<< lub >>>> jak dla mnie problem był naprawdę prosty i zabawny ... Zmieniam nazwę aplikacji w Xcode, ale nie zmieniam jej w UnityProjectSettings przed kompilacją - to był problem ...
źródło
Jeśli kiedykolwiek połączysz się i nadal będziesz mieć problemy, które nie wiedzą, czym one są, mam na myśli nie oczywiste ślady różnic
<<<<< .... ====== >>>>>>
Następnie możesz przeanalizować pliki projektu za pomocą https://github.com/Karumi/Kin , zainstalować go i używać
kin project.pbxproj
Powoduje to, że ekstrema błędów, które nie pozwalają na otwarcie projektu są łatwiejsze do zrozumienia i rozwiązania (takie jak hashe, grupy itd.).
A tak przy okazji, to również może być pomocne, pomyślałem, że nie użyłem go, próbując porównać 2 wersje plików twojego projektu https://github.com/bloomberg/xcdiff, więc to naprawdę da ci to, co się dzieje.
źródło
Subversion uszkodzi mój plik projektu po svn prawie co tydzień. Próbuję dowiedzieć się, dlaczego robi to teraz i napotkałem ten problem.
źródło
Dzieje się tak, ponieważ nazwy projektów nie powinny zawierać spacji między nimi
źródło