views:

108

answers:

1

In the middle of developing an app, I was asked to switch to a different developer account, which resulted in adding a new app ID and creating new provisioning profiles for adhocs on the new account, as well as updating the XCode settings to sign with the new identity.

The problem is that somewhere, somehow XCode is keeping the old provisioning profile around.

I.e. I had a distribution profile "OLD". I created a "NEW". I deleted "OLD" from Organizer in XCode. When I build and archive, "OLD" REAPPEARS in XCode's Organizer, and the adhoc doesn't work for people.

I've tried doing a

grep -r "AD67EE83" *

in the trunk directory for the app, where "AD67EE83" is the profile id in the Organizer. I get a bunch of results in the build directory that look like this:

build/myapp.build/Adhoc-iphoneos/myapp.build/build-state.dat:N/Users/me/Library/MobileDevice/Provisioning Profiles/AD67EE83-BLAB-LABLA-BLAB-LABLABLABLAB.mobileprovision
build/myapp.build/Adhoc-iphoneos/myapp.build/build-state.dat:CProcessProductPackaging "/Users/me/Library/MobileDevice/Provisioning Profiles/AD67EE83-BLAB-LABLA-BLAB-LABLABLABLAB.mobileprovision" /Users/me/Documents/svn/myapp/trunk/build/Adhoc-iphoneos/myapp.app/embedded.mobileprovision
build/myapp.build/Adhoc-iphoneos/myapp.build/build-state.dat:x/Users/me/Library/MobileDevice/Provisioning Profiles/AD67EE83-BLAB-LABLA-BLAB-LABLABLABLAB.mobileprovision
build/myapp.build/Adhoc-iphoneos/myapp.build/build-state.dat:lSLF07#2@192"ProcessProductPackaging "/Users/me/Library/MobileDevice/Provisioning Profiles/AD67EE83-BLAB-LABLA-BLAB-LABLABLABLAB.mobileprovision" build/Adhoc-iphoneos/myapp.app/embedded.mobileprovision303990620#303990620#0(0"0(0#0#108"/Users/me/Documents/svn/myapp/trunk/build/Adhoc-iphoneos/myapp.app/embedded.mobileprovision8628715392#445"    cd /Users/me/Docume    <com.apple.tools.product-pkg-utility> "/Users/me/Library/MobileDevice/Provisioning Profiles/AD67EE83-BLAB-LABLA-BLAB-LABLABLABLAB.mobileprovision" -o /Users/me/Documents/svn/myapp/trunk/build/Adhoc-iphoneos/m0#p.app/embedded.mobileprovision

(I replaced the actual ID with BLABLA there, in case you wonder about that.)

In any case, OLD is pulled out from somewhere and restored and used. Insane. I deleted in Organizer and searched my disk for that AD... thing and found a few files in /Users/me/Library/MobileDevices/Provisioning Profiles/ which had the same names.

I deleted those and it still pulls them out from somewhere when i Build & Archive. In fact, those files are put back in that directory as well.

I've gone through all the settings trying to find any reference to this AD... profile, but there's none anywhere.

OLD is tied to "com.oldcorp" and NEW is tied to "com.newcorp" -- doing a grep 'newcorp' reveals

myapp-Info.plist:    <string>com.newcorp.myapp</string>

Doing a grep 'oldcorp' gives no results.

Any ideas where it might be referring to this old invalid cert? (It's even removed from the developer portal, so I don't think it's possible for it to download it from Apple directly.)

Update: building and archiving ANY project results in the resurrection of the "oldcorp" distribution profile, so it's not related to my project. Problem remains though - adhoc is non-functional.

Solved this by recreating a project and manually putting code in. Long term solution is in answer below.

A: 

I create new User accounts on my Mac when dealing with different developer accounts to prevent XCode caching from creating these types of messes.

That might still provide you with a solution. Create a temporary fresh new User account, install only the private keys, certificates and provisions needed for the new developer account in the new User account, make sure not to use any shared user directories in your build settings, check out your project from source control into the new user account, and run Xcode for your Ad Hoc builds there.

hotpaw2
This looks very much like The Only Way, yeah. I'm currently pending a report back on whether my last attempt worked. Regardless, looks like I'll be forced to juggle accounts. Groan...
Kalle