Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 3092 [details]
I can't find the other ticket where we had an extensive discussion about this and you made some changes to how the drop down for signing/certificates are listed. It's supposed to only show the latest provisioning profile if there are duplicates and now it seems we're also seeing team provisioning profiles in 3.1.0 of MonoDevelop.
After installing Xamarin.Mac which updated me to MD 3.1.0 (which seems to be still in beta) I checked to see if the items from the prior bug report were corrected and I was surprised to see the items as shown in the attached images. In one image you can see for the distribution I'm seeing signing options for our other app "APDL" which is a different bundle ID than the one for the current "Logbook Pro" app which should be "Logbook Pro Dist" for AppStore distribution.
So in essence, we should only see the latest profile if there are multiple, and I believe also only profiles that match the bundle ID for the app being signed to avoid iCloud issues I reported previously and other obvious problems - wrong signing ID.
Created attachment 3093 [details]
I don't really understand the problem here, I can't see any inappropriate provisioning profiles being displayed.
The various "automatic" values (in bold) are not *actual* provisioning profiles or signing certificates. They are special values that cause MD to look for a matching identity of the specified kind at the beginning of the build. So they are always displayed - whether there are any of the that kind of cert/profile installed or not.
Essentially this is (approximately) what MD does at the beginning of the build:
1. MD builds a list of all installed, valid provisioning profiles paired with signing certificates
2. MD filters all pairs out of the list that don't match the signing certificate constraints. For example, if you specified an exact signing certificate it filters out all pairs that don't use that exact signing certificate. If you specified a *kind* of signing certificate it filters out all pairs that don't use that kind of signing certificate, for example if you specified "Automatic (Distribution)" it will filter out all pairs that don't use distribution certificates.
3. MD filters all pairs out of the list that don't match the provisioning profile constraints. For example, if you specified an exact provisioning profile it filters out all pairs except the one that uses that provisioning profile. If you specified a *kind* of provisioning profile it filters out all pairs that don't use that kind of provisioning profile, for example if you specified "Automatic (App Store)" it will filter out all pairs that don't use a App Store provisioning profile.
4. If the app has a bundle ID specified, MD filters all pairs out of the list where the provisioning profile doesn't allow the bundle ID
5. MD sorts the list by most specific match on the bundle ID, if one is specified, then by most recent. This means exact matches are preferred over wildcards. For example, with bundle ID "foo.bar", provisioning profiles would be sorted "foo.bar", "foo.*", "*".
6. MD selects the top match from the list. If a bundle ID was not specified, it constructs one to match the selected provisioning profile. If the list is empty, it errors out.
7. MD reports the selected identity (signing certificate, provisioning profile and bundle ID) to the build output for diagnostic purposes.
The intention of this logic is that you should never have to specify an exact signing certificate or provisioning profile, the "automatic" values should work fine - as long as you specify a bundle ID.
While I didn't read or comprehend all of what you wrote, I think that was more for you than I :) - What I do know is this app has a bundle ID - it's Logbook Pro yet in the distribution image I pointed out the items that are of a different bundle ID for another app "APDL". Why am I seeing "App Store" in the list which is for "APDL" (a diff bundle ID) when I'm signing the Logbook Pro app?
I thought we previously discussed that in the case of duplicate profiles the latest one would be listed? Notice how I have duplicates because for whatever reason when I added a person or device I somehow got duplicate but later signed certs from iTunes provisioning portal.
The bold "Automatic [...]"values in the list are not actual provisioning profiles, they are constraints that cause MD to pick a matching provisioning profile of the selected kind (if it can find one). The intent is that you should always use the "Automatic" values except in very advanced cases.
In this case, if you select "Automatic (App Store)", the build will fail because it can't find an app store provisioning profile matching your bundle ID.
The duplicates do look like an issue, if we can be sure several profiles are different versions of the same profile (same key, name, bundle id, etc) we should hide all but the newest.
Why would you present items in the list such as "App Store" when it's a bundle ID mismatch? In my opinion I should only see items that would successfully sign the Logbook Pro app in this case.
There is no mismatch. It is not a provisioning profile, it does not have a bundle ID. It is a constraint that you can specify whether you have installed profiles/keys of that kind or not.
This means new projects can have an "App Store" build configuration with that constraint set, even though the user may not have a matching provisioning profile installed until much later. Or some developers on a team may not have access to the dist certs, but they can still see (and modify) useful values in the project configurations even though they can't build.
Something we could consider would be to group the actual provisioning profiles under the constraint that they match. Then it might be clearer what they mean, and what kind of provisioning profiles are installed.
The only way that you should be getting duplicate provisioning profiles is if they have different UUIDs.
if you open the provisioning profiles in a text editor (technically, the files are binary, but they have a huge plain-text xml blob in the middle of them), you can search for :
The <string> value immediately after them is likely different. If not, let me know.
The code I added based on your previous bug report only filtered out duplicate provisioning profiles that shared the same UUID.
Thanks Jeffrey, I was just surprised to see the different presentation of signing profiles than before and really had hoped that there would be a fail safe system to disallow me from choosing a signing profile that would fail such as for a different bundle ID.
On another note, are you all creating the named items "App Store, Ad Hoc, and In House"? Because these are not in my iTunes connect provisioning profile areas, I have nothing with these names. This is really confusing and I think is going to lead to signing errors and app rejections.
Yes, we are creating those. They are effectively aliases that map to the best-matching provisioning profile that are for the various purposes (i.e. Ad-Hoc, App Store, and In-House (Enterprise) deployment).
I think we can close this, right?
Yep, up to you. Ironically I have a 3rd profile for each now! I bought an iPhone 5 so I removed my 4S from the provisioning area of iTunes connect. Because I removed a device it invalidated my profiles. I had to renew the profiles such as for development and ad-hoc and then refreshed xcode, now I have three of each! My guess is Xcode is not removing invalid profiles when new ones are created. So as you an imagine, it's a bit of a mess. I'm using MonoDevelop 3.1.1. When I go to the signing area I see three profiles + the team one, etc. Really should just show the latest one in the list. If you need a screenshot let me know.
What you can do is go to the Organizer and delete all of the provisioning profiles and then click "Refresh" in the lower-right corner of the window and it will refetch all of the profiles (but since you deleted them all locally, you'll only have 1 copy of each).
I thought I had tried that without success in the past, it seems to have worked this time! Thanks Jeff!
No prob, always glad to help ;-)