Dropbox API的协同设计在Xcode 4.6.3中失败: [英] Codesign of Dropbox API fails in Xcode 4.6.3: "code object is not signed at all"

查看:111
本文介绍了Dropbox API的协同设计在Xcode 4.6.3中失败:的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个通过Mac App Store分发的OS X应用程序,最近更新为Xcode 4.6.3.

I have an OS X app that's distributed through the Mac App Store, and recently updated to Xcode 4.6.3.

现在运行我的常规版本时,我收到:

When I run my regular build now, I receive:

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更新相关的问题还是其他原因.

I can't seem to discern any other changes in my project, so I can't tell if it's an issue related to the 4.6.3 update, or something else.

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

I have tried restarting Xcode, running a clean build, and cleaning the build folder.

推荐答案

我想我可能已经想到了这一点.我一直在OS X Mavericks上运行Xcode 4.6.3,给人的印象是,任何特定于构建的工具都捆绑在Xcode应用程序中.

I think I may have figured this one out. I've been running Xcode 4.6.3 on OS X Mavericks, under the impression that any build-specific tools were bundled in the Xcode application.

但是,似乎codesign/usr/bin中.我不确定它是由Xcode安装程序之一安装还是随系统安装而来.但是通读codesignman页时,我发现了这个不错的选择:

But, it seems codesign is in /usr/bin. Whether it's put there by one of the Xcode installers or comes with a vanilla system install, I'm not sure. But reading through the man page for codesign, I found this nifty option:

--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.

然后我发现了此帖子( https://alpha.app.net/isaiah/post/6774960 )从两周前(〜2013年6月)开始,其中提到(尽管是二手的):

And then I found this post (https://alpha.app.net/isaiah/post/6774960) from two weeks ago (~June 2013), which mentions (albeit second-handedly):

@isaiah我问了实验室里的一个人.他说代号现在 要求嵌入式框架在代码之前单独签名 对整个应用捆绑包进行签名.

@isaiah I asked a guy in the labs about it. He said codesign now requires embedded frameworks to be signed separately before code signing the app bundle as a whole.

手动重新运行Xcode正常运行的codesign命令,同时在末尾添加--deep标志,以正确地对应用程序进行签名.

Manually re-running the codesign command that Xcode normally runs, while adding the --deep flag to the end, signs the application properly.

我不确定该手动签名的确切含义,或者我是否可以调整Xcode构建以自动添加--deep标志,但这似乎是潜在的问题. (codesign不再自动对您的应用程序捆绑包进行深度签名.)

I'm not yet sure exactly what ramifications this manual signing has, or whether I can tweak the Xcode build to add the --deep flag automatically, but this seems to be the underlying issue. (codesign no longer automatically deeply signs your app bundle.)

这篇关于Dropbox API的协同设计在Xcode 4.6.3中失败:的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆