Dropbox API 的代码设计在 Xcode 4.6.3 中失败：“代码对象根本没有签名”

Posted 2023-02-18

【中文标题】Dropbox API 的代码设计在 Xcode 4.6.3 中失败：“代码对象根本没有签名”

【英文标题】：Codesign of Dropbox API fails in Xcode 4.6.3: "code object is not signed at all"

【发布时间】：2013-06-20 06:44:00

【问题描述】：

我有一个通过 Mac App Store 分发的 OS X 应用，最近更新到 Xcode 4.6.3。

当我现在运行常规构建时，我收到：

Command /usr/bin/codesign failed with exit code 1:

/Users/Craig/Library/Developer/Xcode/DerivedData/Mac-dxcgahgplwpbjedqnembegifbowj/Build/Products/Debug/MyApp.app: code object is not signed at all
In subcomponent: /Users/Craig/Library/Developer/Xcode/DerivedData/Mac-dxcgahgplwpbjedqnembegifbowj/Build/Products/Debug/MyApp.app/Contents/Frameworks/DropboxOSX.framework
Command /usr/bin/codesign failed with exit code 1

我似乎无法辨别我的项目中的任何其他变化，因此我无法判断这是与 4.6.3 更新相关的问题，还是其他问题。

我已尝试重新启动 Xcode、运行干净的构建并清理构建文件夹。

【问题讨论】：

XCode 8.2 中仍然存在此问题。当我删除测试时，我现在收到此错误：无法加载捆绑包“XXXX”，因为无法找到其可执行文件。

【参考方案1】：

对我来说，这是一个损坏的框架 PaddleMA，它： 1. 我从我的 Cocoapods 文件中删除 2.冉pod install 3.重启我的Xcode

它解决了这个问题。由于某种原因，损坏的框架会阻止它被签名，不幸的是 XCode 并没有真正清楚地显示这个错误并给你一个很好的修复建议。已向 Apple 提出要修复的错误。

【参考方案2】：

对我来说，这个问题是在我的项目中拖动一个名为“resources”的文件夹后引起的。将其名称更改为其他名称后（例如“resourcessss”），错误消失了。

【讨论】：

这是我的问题。另请注意，通常的 mac 文件系统不区分大小写，因此如果您有一个名为的文件夹或文件，例如“Resources”或“RESOURCES”也会导致这个问题。

这也解决了我的问题。剩下要做的就是从应用程序包中删除 Resource 文件夹并重新启动 Xcode.app。

我遇到了一些问题，但这个答案帮助了我。我看到我有一个名为 Resources 的蓝色文件夹和一个名为 Resources 的黄色文件夹。我还看到它抱怨的文件仅在其中一个文件夹中。我最终完全删除了蓝色的（参考，而不是文件，它们是相同的）。我还将它重命名为 Res。不完全确定这是必要的（我在删除蓝色文件夹之前做过），因为我有另一个项目，它有一个名为 Resources 的黄色文件夹并且那里没有问题。

这对我也有用。我想在这个页面上添加一个关键字。我的问题是原生脚本。所以不是真正的 x-code / 纯 ios 开发。希望这对其他人也有帮助。

对于未来的读者，如果您需要包含一个名为 Resources 的文件夹（就像我一样），您只需在添加到项目时选择 Create Groups 而不是 Create Folder References 和不会发生此错误。 （只需确保您的目标成员资格仍然为所述文件设置）

【参考方案3】：

这可能对某人有所帮助：

我终于通过反复试验找到了解决方案。在我的例子中，我有一个与构建设置下的“产品名称”变量匹配的文件夹名称。这也匹配了整个项目名称！所以我只是改变了一个领域。我更改了“构建设置”->“产品名称”。 MySpecialApp 的值已更改为 My-SpecialApp。就是这样！然后，我重新登录 Apple 开发者门户并创建了一个新的 App ID 和移动配置文件以用于开发和分发，剩下的就是历史了。通过 Ad Hoc 发行版部署时，我的版本现在可以工作。 关于此的最后说明。这绝对是一个错误，Apple 应该提醒用户他们做错了什么并启用某种自动纠正措施。 - 查看更多信息：http://www.chrisdanielson.com/2012/08/29/codesign-ipa-and-the-code-object-is-not-signed-at-all-problem/#sthash.F0nF3BbC.dpuf

【讨论】：

感谢@VBB 的回复，但不幸的是，产品名称在过去几年没有改变。 （而且我现在无法更改。）

【参考方案4】：

我遇到了同样的问题，但答案很简单：我的应用程序上的代码签名身份设置为“-”，因此只需将其设置为“不进行代码签名”即可解决问题。

“-”似乎是您执行某些操作时的默认设置，尽管我无法告诉您这些是什么。

【讨论】：

这个解决方案适合在模拟器上运行应用程序，但是当我们想要制作 ipa 或存档时，这个解决方案在我这边不起作用。

【参考方案5】：

正如其他答案中强调的那样，代码签名的工作方式发生了变化。如果您安装了任何 Xcode 5 DP，那么即使您使用的是 Xcode 4.6.X，也会使用新工具。

在这个阶段（在 Xcode 4.6.X 中）您需要做的就是采用上面建议的 --deep 标志并将其添加到您的代码签名标志（目标、构建设置）中，请参见下图。

【讨论】：

帮助了我。我想这意味着您以某种方式保证您使用的所有导入库。

根据对我上面回答的评论，这似乎实际上可能是特定于 OS 10.9 的问题，而不是 Xcode 5 的问题。

Apple 技术说明 2206 声明“虽然 --deep 选项可以应用于签名操作，但不建议这样做。我们建议您在各个阶段从里到外对代码进行签名（就像 Xcode 自动执行的那样）。使用 --deep 签名仅用于紧急维修和临时调整。”

【参考方案6】：

我想我可能已经解决了这个问题。我一直在 OS X Mavericks 上运行 Xcode 4.6.3，我的印象是任何特定于构建的工具都捆绑在 Xcode 应用程序中。

但是，codesign 似乎在/usr/bin 中。无论它是由 Xcode 安装程序之一放置，还是附带原版系统安装，我都不确定。但是通过codesign 的man 页面，我发现了这个漂亮的选项：

--deep  When signing a bundle, specifies that nested code content such as helpers, frameworks, and plug-ins, should be recursively signed
             in turn. Beware that all signing options you specify will apply, in turn, to such nested content.
             When verifying a bundle, specifies that any nested code content will be recursively verified as to its full content. By default,
             verification of nested content is limited to a shallow investigation that may not detect changes to the nested code.
             When displaying a signature, specifies that a list of directly nested code should be written to the display output. This lists only
             code directly nested within the subject; anything nested indirectly will require recursive application of the codesign command.

然后我发现了两周前（~2013 年 6 月）的这篇帖子 (https://alpha.app.net/isaiah/post/6774960)，其中提到（尽管是二手的）：

@isaiah 我问过实验室里的一个人。他说现在协同设计 要求嵌入式框架在代码之前单独签名 对整个 app bundle 进行签名。

手动重新运行 Xcode 正常运行的codesign 命令，同时在末尾添加--deep 标志，正确签署应用程序。

我还不确定这个手动签名到底有什么后果，或者我是否可以调整 Xcode 构建以自动添加 --deep 标志，但这似乎是根本问题。 （codesign 不再自动对您的 app bundle 进行深度签名。）

【讨论】：

是的 - 我能够在我的 Xcode 项目的 Build Settings 中找到“Other Code Signing Flags”选项，将--deep 添加到其中，现在构建成功执行。我们将看看这是否会通过 Mac App Store。

我不相信 codesign 以前做过“深度”签名。我一直在使用 codesign，在包含 3rd 方库的应用程序中，并且 codesign 只签署主要可执行文件（在 Context/MacOS/ 中），而其他 lib 文件需要单独的 codesign 调用。

@ThomasTempelmann 我对codesign 知之甚少，无法确切了解发生了什么变化。我所知道的是，在 10.8 和 10.9 之间（或者可能是 Xcode 4 到 Xcode 5，我同时升级了两者）行为确实发生了变化，这就是我一直在努力获得我的应用已成功提交。

为了好奇，我在 10.8 上使用 Xcode 5 已经有一段时间了，但今天我尝试在 10.9 下签名时才遇到这个问题。

Craig Hockenberry（下面的答案中的链接）解释了为什么使用 deep 是错误的