Comment faire pour détecter un profil de configuration est pour le développement ou la distribution, par programmation
Je voudrais détecter si un profil de configuration est un profil de développement ou de distribution (ad-hoc ou app store) le profil. J'ai besoin de faire ce purement de la programmation.
Je suis déjà à comprendre comment détecter adhoc vs appstore. Et je suis particulièrement intéressé par les dev vs distribution.
J'ai examiné les plists interne à chaque type de profil et ne peut pas trouver une différence visible (via security cms -D -i #{@profilePath}
). J'ai aussi regardé dans le openssl
api et je suis en utilisant un certain certificat de manipulation.
C'est pour une mesure xcode système automatisé de construction. Dans le cadre de la pré-construction de validation j'ai besoin pour s'assurer que le profil spécifié n'est pas pour le développement.
Est-ce même possible? Si oui, comment pouvez-I du programme, la différence entre les deux?
Merci d'avance pour toutes vos idées!
- C'est une question intéressante, +1.
- Évidemment les gens à
testflightapp.com
sont faites pour .les fichiers ipa, mais je ne sais même pas comment différencier les adhoc/appstore qui vous êtes en train de faire. Je pense que XCode est outils de ligne de commande doit inclure un "profil d'approvisionnement de la charpie outil de" ce qui devrait être fait pour nous. C'est juste une riche source de confusion pour l'utilisateur. Merci Apple. - Salut Warren P, pour info tout ce que je fais pour détecter un adhoc vs appstore profil est de vérifier la présence de la
ProvisionedDevices
clé dans le profil du plist, depuis l'appstore profils ont l'habitude de tout configuré appareils. Peut-être pas infaillible, mais pour le système, je suis en train de travailler à l'intérieur, il sert l'objectif. Espérons que cela est utile.
Vous devez vous connecter pour publier un commentaire.
C'était quelque chose que j'ai abordé dans un de mes propres construire des systèmes pour la même fonction...nous allons faire un voyage dans le temps à Jour 1 de l'iPhone Developer Program". Si vous avez été autour de la communauté à l'époque, vous vous souvenez peut-être que la suite d'outils a été...disons moins...qu'il ne l'est aujourd'hui.
Lorsque vous voulez construire pour l'AppStore ou pour AdHoc s'appuie que vous avez dû faire cette curieuse droits.fichier plist, puis collez-y une goutte de XML dans le corps de ce fichier. Vous puis a couru à la construction et à l'époque ce qui semblait être de la magie s'est produite et la simple présence de ce fichier fait l'accumulation de travail, permis de construire manuellement votre IPA, et continuer comme d'habitude. Maintenant que nous sommes quelques années de plus et on espère un peu plus sage que dans les premiers jours de la SDK, nous en sommes venus à reconnaître que la magie XML blob n'est pas vraiment si magique, la 'obtenir la tâche de permettre" la clé est un paramètre pour indiquer si le binaire devrait permettre à d'autres processus (comme peut-être un débogueur) à joindre à la binaire. Lors de la signature des applications à l'aide d'un Profil d'approvisionnement de Développement, cette clé sera la valeur "true" (et donc de permettre LLDB à fixer et à interagir avec votre application)...et, naturellement, au moment de la signature des applications à l'aide d'un Profil d'approvisionnement de Distribution, cette clé sera mis à 'false'.
Apple a fourni des mises à jour dans Note technique TN2250 lire le XML (et par extension les droits) de Profils de configuration:
Ce sera de retour le XML dans le profil de configuration -- à partir de là, vous pouvez analyser la valeur de la clé d'une paire de 'get-tâche-autoriser" et utiliser cette valeur pour déterminer si le Profil de configuration est le Développement ou la Distribution.
Je suis absolument d'accord qu'il serait agréable d'avoir un outil qui va nous dire qui, directement, de sorte que nous n'avons pas à renifler, à travers le profil pour trouver des indices, mais en même temps, au moins nous avons un très fiable, quoique de façon détournée de faire cette distinction avant de courir et de faire un build nous ne pouvons pas utiliser.
Bonne chance et laissez-moi savoir si vous avez besoin de plus de précisions ou avez d'autres questions.
J'ai un plus concis et efficace version de Toom code:
Je vais maintenir des extraits de code comme ceci dans un résumé, vous pouvez trouver une version plus récente ici: https://gist.github.com/steipete/7668246
Basé sur Bryan Musial grande réponse, j'ai écrit un code qui vous permettent de cocher la case "obtenir la tâche de permettre" directement à partir de l'application lors de l'exécution. Dans mon cas, je suis en utilisant cette valeur pour ouvrir une session de débogage des applications :
Ici est une version de Swift 3, basé sur @steipete réponse:
Si curieux,
get-task-allow
est un drapeau que le build utilise pour déterminer si vous devez être en mesure de raccorder un débogueur et d'autres processus comme ça - c'est donc assez précis pour savoir si c'est un dev construire ou pas.