Xcode 4.3：Codeign操作失败（检查您选择的身份是否有效）

时间：2012-02-21 23:25:37

标签： ios xcode validation distribution codesign

安装Xcode 4.3后，我无法使用管理器验证和分发应用程序。 在Xcode中构建，签名和验证时，组织者中的验证失败，并在此问题的标题中显示消息。

首先，Xcode 4.3可以自动下载配置文件（管理器中有一个选项），但它只下载开发配置文件并忽略分发配置文件，就好像没有。好的，我手动下载并安装它，它出现在管理器中。然后，我为项目和目标设置了正确的代码签名标识，并使用与我的钥匙串中的分发证书匹配的分发配置文件。然后我进行归档（build-sign-verify）并且没有错误，在日志中我看到CodeSign的绿色复选标记和验证步骤。看起来很好，存档会出现在管理器中。

这就是出错的地方，我只选择验证，选择我刚在iTunes Connect中准备的新版本，选择正确的代码签名身份，与用于存档的相同（实际上，我的情况下没有其他选择） ，它像往常一样要求iTunes登录/密码，然后说

  

代码签名操作失败

     

检查您选择的身份是否有效

唉唉!!!为什么！？归档它时没有问题，然后在尝试提交到AppStore时，相同的代码签名不起作用。好吧，甚至没有提交，但在实际发送之前进行验证。所以这个问题是我的机器的本地问题。在构建期间成功的签名和验证在Organizer中失败...

我尝试了所有内容，重新安装了Xcode，删除/撤销并重新颁发了所有证书，从钥匙串中删除了重复的私钥和公钥，将所有证书放在一个“登录”钥匙串中，发布了新的配置文件，安装了Application Loader 2.5。 1，等等......仍然没有运气。

可能是因为之前的Xcode安装有一些遗留问题吗？或者我必须更新一些工具才能使管理器正常工作？

同时，如果有人知道将二进制文件上传到AppStore的另一种方式，请分享。我无法弄清楚如何使用Application Loader，当它要求我选择要上传的包时，我所拥有的只是在存档步骤中由Xcode创建的xcode存档。如何获取iap或Application Loader想要的任何文件？

16 个答案:

答案 0 :(得分：30)

我发现Xcode 4.3.1在应用程序包内的目录树中使用资源验证应用程序存在严重问题。

应用程序可以在Xcode“Build for Archive”过程中通过验证 - 只有在通过Organizer运行验证时才会失败。

在花费数小时试图追踪通常的代码签名权利问题后，我最终在导出失败时注意到系统控制台中的以下行：

3/10/12 2：32：48.450 PM [0x0-0x261261] .com.apple.dt.Xcode：/ Users / chris / Library / Developer / Xcode / Archives / 2012-03-10 /覆盖范围3-10-12 2.32 PM.xcarchive / Products / Applications / Coverage.app / Tiles / T-Mobile-roam / 4：是目录

我花了一天时间试图找出这个错误，我终于把它钉了出来。

XCode 4.3.1中的代码签名者，当您的捆绑包中存在与其父目录同名的子目录时，验证App Store或保存AdHoc分发阻塞。

例如：

test/test/file.x -- FAIL
test/test2/file.x -- WORKS

这似乎是Xcode 4.3.1中的新功能，希望很快就会修复。

注意：此主题似乎相关：https://devforums.apple.com/message/630800

答案 1 :(得分：8)

我是Apple Dev论坛上的原创海报...... https://devforums.apple.com/message/621193

我也试图引起AddThis开发人员的注意：
https://www.addthis.com/forum/viewtopic.php?f=19&t=38292

正如其他帖子中所提到的，我发现阻止代码签名失败的唯一方法是从项目中删除ATResources.bundle文件。

当然，这个捆绑包含了AddThis的许多必要图像，但不再出现错误。

我希望这有助于其他人找到解决此问题的正确方法。

答案 2 :(得分：2)

问题是AddThis或显式地在AddThis文件夹中的ATResources.bundle。

所以你有两个选择：

  • 第一个是使用较旧版本的Xcode存档。

  • 第二个是重新定位内部的所有图像 将ATResources.bundle放入一个文件夹中，并复制该内容 Localizable.strings到你自己的Localizable.strings

    然后打开FBDialog.m文件并搜索“close.png”，删除它 代码行并将其替换为：

    UIImage * closeImage = [UIImage imageNamed：@“close.png”];

现在您已准备好存档。

最后考虑在https://bugreport.apple.com/

中提交错误报告

答案 3 :(得分：2)

In my case，这是一个受损的自定义框架。

答案 4 :(得分：1)

我的捆绑包中有这么多子目录，与父母的名字相同，所以我无法验证和提交。我找到的唯一解决方案是从Apple开发人员中心下载xcode 4.2.1并与xcode 4.3.2并排安装。然后我用它来验证和提交。

答案 5 :(得分：1)

我正在使用Sencha 2进行开发。这里的关键是从Apps / Utilities启动系统控制台，并在分发时查看错误日志。这是查看违规目录的最简单方法。在Sencha2中它位于/ sdk / src / device / device中。好东西：仍然在xcode 4.3.2中发生

答案 6 :(得分：1)

只是确认问题确实是我的应用程序中具有相同名称的嵌套文件夹。

在我的特殊情况下，这就是问题所在：

  • 问题：images / packs / 1/1 /img.png
  • 解决方案：images / packs / pack_1 / 1 /img.png

之后顺利航行。这发生在Xcode 4.3.3

中

答案 7 :(得分：1)

找到解决方案，它真的适合我。希望这能帮到你们。

如果问题是由于Addthis，请尝试按照

enter image description here

注意到里面的ATResources.bundle你有一个名为ATResources的文件夹。

ATResources包含ATResources.bundle中存在的副本项（ADDTHIS.db，en.lproj，images）。所以我们可以简单地从ATResources.bundle中删除ATResources文件夹。

删除，从ATResources.bundle中选择文件并右键单击，在finder中显示 - ＆gt;并删除ATResources文件夹。

enter image description here

主要问题是因为您的包中的子目录与其父目录具有相同的名称。

：）

答案 8 :(得分：1)

我在Xcode 5.0.2（5A3005）上遇到了这个问题，其中包含两个完全独立的文件夹，这两个文件夹恰好相同。

此线程中的大多数其他案例都集中在父/兄弟关系上，但我认为任何两个具有相同名称的文件夹都会导致此失败。

答案 9 :(得分：0)

我和你一样有同样的问题，而且我的反响激励了我：

您是否看到ATResources目录只包含其父级的副本？

ADDTHIS.db
en.lproj/*
images/*
ATResources/ADDTHIS.db
ATResources/en.lproj/*
ATResources/images/*

作为一个快速而又脏的修复，我删除了冗余子目录。应用程序构建并且似乎工作正常，Xcode能够签名。

如果我错过了此修复的任何后果，请告诉我？

答案 10 :(得分：0)

哎呀，我花了一个小时来解决这个问题。

我刚从项目中删除了AddThis。做它，它会工作。

答案 11 :(得分：0)

重启xcode让按钮对我有用。如果这里有人遇到同样的问题，他们之前会变灰了

答案 12 :(得分：0)

Techi50暗示了这一点，但要明确 - 在Xcode 4.3.5下，如果您的子目录与父目录具有相同的名称，则代码签名将会失败。例如，在Sencha Touch 2 SDK树中，有

/ SDK / SRC /设备/装置

呃...几个小时试图编码没有运气的标志......重命名为：

/ sdk / src / device / device_epic_fail

（因为我不需要那些库）

我可以编码。

一个大的虫子狩猎已经结束了。 Apple ...请修复...

答案 13 :(得分：0)

将AddThis SDK从0.1.7更新到0.1.9为我解决了这个问题（使用XCode 4.3.1）。

答案 14 :(得分：0)

我已确定此错误的另一个原因，这在Xcode 4.6.2（4H1003）中发生。我有一个子项目构建可执行文件。此可执行文件是一个帮助工具，在构建时会复制到我的应用程序包中。

该应用程序具有OS X 10.7的最低部署目标，因此可为64位Intel构建。 但是，帮助工具的部署目标设置为10.6，并且正在为32位/ 64位Intel构建。

更改帮助工具以构建10.7和64位Intel只能修复错误。我可以通过将帮助工具更改回32位/ 64位Intel来可靠地重新创建错误;这不是'呃，摧毁你的PRAM'修复。

答案 15 :(得分：0)

正如@radven和@ tomek-cejner所提到的，有时一些额外的目录可能会导致问题。也许如果命名不当？对我来说，罪犯是不同的。

  

Gruntfile.js，karma-e2e.conf.js，karma.conf.js以及整个node_modules目录。

请参阅：How to build IPA for distribution with TestFlight with XCode 5?

相关问题
最新问题