CocoaPods adds duplicate project to xcworkspace.

[StalkerRus]

My workspace structure is the following:

• ProjectA
  
  
  
  • ProjectB
  
  
  • ProjectC
  
  
• Pods

I run the 'pod update' and what I get is

• ProjectA
  
  
  
  • ProjectB
  
  
  • ProjectC
  
  
• Pods
• ProjectB <- this should not be here!

My Podfile is:

platform :ios, '7.0'
inhibit_all_warnings!
workspace 'ProjectA'

target :ProjectA do
    pod "AFNetworking", "~> 2.0"
    pod 'Facebook-iOS-SDK'
    pod 'RESideMenu'
    pod 'RBStoryboardLink'
end

target :ProjectBTests do
    xcodeproj 'Libraries/ProjectB/ProjectB'
    pod 'Expecta'
    pod 'Specta'
    pod 'OCMock'
end

Problem is not critical, but quite annoying.

[fabiopelosin]

CocoaPods expects to create a Workspace with the list of all the projects. We could inspect the user projects to see if a project is already added as a subproject of another one. However this approach would require to inspect all the file references of the projects and have some logic dedicated to the circularity.

This is not compatible with the KISS principle unless there is evidence of strong demand. In the meanwhile I would suggest to delete the project from the workspace using the post install hook of the Podfile.

[Reflejo]

Hey @fabiopelosin can you post an example of how to remove the project on post_install ?

EDIT: I don't see how this is possible to achieve by the post_install hook since post_install is called before writing the xcworkspace file.

[tomaskraina]

Hey @Reflejo any progress on this? I'm currently running into the very same issue.

[ghost]

I am seeing duplicate projects too.

My Xcode workspace, pre pod install is:

• My-Pod Files Folder
• My-Tests Project
• My-Example Project

The actual folder structure is

My-App

• My-App Workspace
• My-Framework-files
• My-Tests
  
  
  
  • My-Tests.xcodeproj
  
  
  • Podfile
  
  
• My-Example
  
  
  
  • My-Example.xcodeproj
  
  

The podfile in the same folder as the My-Tests Project is as follows:

source PRIVATE_REPO

platform :ios, '7.0'
inhibit_all_warnings!

workspace '../my-example'
link_with 'my-tests'
xcodeproj 'My-Tests'

pod 'MyPod', :path => '../'

After pod install I get a workspace that looks like:

• My-Tests Project
• My-Example Project
• My-Tests Project
• Pods project

[ghost]

Scratch that, seems there was something flakey going on in my *.xcworkspacedata file.

[migfabio]

I'm sorry if I rebump this issue, but still happens.
I have CocoaPods 0.39.0 and this is my Podfile

platform :ios, '8.0'
inhibit_all_warnings!

xcodeproj 'MyProject/MyProject.xcodeproj'

pod 'Google-Mobile-Ads-SDK', '~> 7.0'
pod 'Google/Analytics', '~> 1.0.0'
. . .

and this is contents.xcworkspacedata generated

<?xml version="1.0" encoding="UTF-8"?>
<Workspace
   version = "1.0">
   <FileRef
      location = "container: MyProject/MyProject.xcodeproj">
   </FileRef>
   <FileRef
      location = "group:Pods/Pods.xcodeproj">
   </FileRef>
   <FileRef
      location = "group: MyProject/MyProject.xcodeproj">
   </FileRef>
</Workspace>

Did I make some mistake?

[peterpaulis]

2017, but i still encountered this with my project

[orta]

Sounds like you've got a reproduction case then, you're in a good position to take a look at making a PR?

[peterpaulis]

i solved it like following

deleted the pod file, pod.lock and workspace

pod install

[KaneCheshire]

@peterpaulis this didn't have an effect for me unfortunately. Closing and reopening the workspace caused it to show the duplicates again.

[jayantnd]

same issue here!

[anToha]

It's Jan 2019 and still the same issue.

[dnkoutso]

This is a 5 year old issue. This comment doesn't assist at all. Please file a new issue with a sample app demonstrating it so someone can reproduce and fix it.

[anToha]

@dnkoutso Challenge accepted!

_TLDR: This is a user's workspace bug. To fix the issue just open your workspace's contents.xcworkspacedata in a text editor and simplify all relative paths. E.g. OMGNotExistingDirectory/../FirstLibrary/FirstLibrary.xcodeproj should now look like FirstLibrary/FirstLibrary.xcodeproj_

So, sometimes while rearranging your projects in a workspace your contents.xcworkspacedata may end up like this:

<?xml version="1.0" encoding="UTF-8"?>
<Workspace
   version = "1.0">
   <FileRef
      location = "group:App/App.xcodeproj">
   </FileRef>
   <FileRef
      location = "group:OMGNotExistingDirectory/../FirstLibrary/FirstLibrary.xcodeproj">
   </FileRef>
   <FileRef
      location = "group:SecondLibrary/SecondLibrary.xcodeproj">
   </FileRef>
   <FileRef
      location = "group:ThirdLibrary/ThirdLibrary.xcodeproj">
   </FileRef>
</Workspace>

See that OMGNotExistingDirectory/../FirstLibrary/FirstLibrary.xcodeproj ? Yes, that's the problem. Even if the folder in the path does not exist anymore the /.. part of the path allows XCode to ignore it and work without problems.

Now we run pod install. The problem here is when CocoaPods reassembles the workspace (#create_workspace function in lib/cocoapods/installer/user_project_integrator.rb) it compares relative paths instead of absolute to avoid duplicates. And, of course, FirstLibrary/FirstLibrary.xcodeproj is not OMGNotExistingDirectory/../FirstLibrary/FirstLibrary.xcodeproj even though they are pointing to the same file.

So to fix the issue you have to simplify the relative paths in your workspace by removing redundant parts in them.

Thanks to kezi's answer in StackOverflow https://stackoverflow.com/a/54329752/974750 for giving a clue on the issue root cause.

[k3zi]

Another part of the problem is nested groups. FileReferences aren't considered equal unless fr.path == otherfr.path && fr.type == otherfr.type. However Xcodeproj doesn't support file references that are buried in nested groups. Currently any file reference nested in more than a single group reference will skip it's first group reference's parents when initializing the path. Thus the comparison will also be affected. I'd like to create a pull request sometime this week but for the moment I opened an issue on that repo: https://github.com/CocoaPods/Xcodeproj/issues/657

[dnkoutso]

@anToha @k3zi first of all thank you both!

I recommend opening a new issue with your case @anToha and maybe attempt to make a PR for both issues?