Xcode 4 project: utility to clean up pbxproj file?

I have an Xcode 4 project with 2 targets, one for iPhone and one for iPad. If I click on the iPad target and try to go to Build S开发者_StackOverflow社区ettings Xcode 4 crashes:

Encountered multiple assertions. First assertion was: ASSERTION FAILURE in /SourceCache/IDEXcode3ProjectSupport/IDEXcode3ProjectSupport-269/Xcode3Sources/XcodeIDE/Frameworks/DevToolsBase/pbxcore/FileTypes/../PBXFileType.m:594 Details: filename should be a non-empty string, but it is nil

Obviously the pbxproj file has a bad reference in there somewhere -- likely caused by the many manual merges I've been forced to do by git. Is there some way to clean up the pbxproj file so it works correctly again or to tell which line is causing the problem?? I'd really really prefer not to have to recreate the project from scratch.

I tried gorbster's method with no success (though it has solved similar problems for me in the past).

I went into my project.pbxproj file (inside the .xcodeproj package for the project) and found two lines that looked a little suspicious, both of the form:

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

I deleted the lines, and voilà: I can access my build settings for this target again.

No idea how they got in there in the first place. I would guess something to do with a faulty merge under SVN.

Ran into the same issue this morning after pulling a colleague's merge.

I was able to fix this with the following:

1. Close Xcode
2. Open the .xcodeproj package in Finder
3. Delete the project.xcworkspace file/package
4. Open the xcuserdata folder and delete your user-specific .xcuserdatad folder.
5. Re-Open Xcode and project

I lost some minor user preferences (file and tab history, etc), but can now click all (9) of my targets without issue. Turns out my colleague was on an earlier version of Xcode, but I'm not sure if this contributed to the IDE crashing.

Ben Mosher found the solution. And yes it is due to SVN merge problem.

As we working in team with SVN the error occur often so I wrote a bash script:

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

Try the following steps while your Xcode is closed.

1. Go to your {YOUR_PROJECT}.xcodeproj file in finder.

2. Right click on the {YOUR_PROJECT}.xcodeproj file.

3. Choose Show Package Contents ... this will open the contents in another Finder screen.

4. Open file project.pbxproj and search for all lines having string "(null) in"

5. Delete all lines having (null) in ... no worries.... delete confidently.

6. Save your file.

Now open your project using Xcode and try to open the Build Settings tab... hopefully your problem will be solved.

Thanks, Mohamed.

Right click your .xcodeproj file and "Show Package Contents".

Then open project.pbxproj file with TextEdit and duplicate.

Save duplicate file anywhere with same name and extension. (project.pbxproj)

And replace with the old file.

In case you also tried the remove (null) reference lines and deleting the user-specific .xcuserdatad folder, and those did not work, here is a potential solution. FYI... This was experienced on Xcode 7.3.1 .

Here is the scenario I faced:

I experienced this issue that was triggered by having "twin" branches in a git repo... (i.e. one branch BRANCH_A is a development branch with some features not due for release, and another that had the same commits except for the new features, call it BRANCH_B).

The development work flow is as follows: start with BRANCH_B, create a commit branch CHANGE_C, make changes and commit, then checkout BRANCH_A, create a commit branch, then cherry-pick changes from CHANGE_C. BRANCH_A is tracking BRANCH_B in this way, with its additional feature files.

In my case, (for some reason during rebasing on co-worker changes from the remote that BRANCH_B tracks, the project file for BRANCH_B got corrupted.

In this case, the solution is to save a copy of the project file for BRANCH_A (which is good and compiles), then checkout BRANCH_B, and replace its project file with the copy.

Initially, it will not compile, until all references to the feature files (from BRANCH_A) are removed from Target's Build Phases > Compile Sources.

Works great.