Frage Das CoDesign der Dropbox-API schlägt in Xcode 4.6.3 fehl: "Das Codeobjekt ist überhaupt nicht signiert"


Ich habe eine OS X App, die über den Mac App Store vertrieben wird und kürzlich auf Xcode 4.6.3 aktualisiert wurde.

Wenn ich jetzt meinen normalen Build ausführe, erhalte ich:

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

Ich kann keine anderen Änderungen in meinem Projekt feststellen, daher kann ich nicht sagen, ob es sich um ein Problem im Zusammenhang mit dem Update 4.6.3 oder etwas anderem handelt.

Ich habe versucht, Xcode neu zu starten, einen sauberen Build auszuführen und den Build-Ordner zu bereinigen.


75
2018-06-23 18:32


Ursprung


Antworten:


Ich denke, ich habe das herausgefunden. Ich habe Xcode 4.6.3 auf OS X Mavericks ausgeführt, unter dem Eindruck, dass alle buildspezifischen Tools in der Xcode-Anwendung gebündelt wurden.

Aber es scheint codesign ist in /usr/bin. Ob es von einem der Xcode-Installer da ist oder mit einer Vanilla-System-Installation kommt, bin ich mir nicht sicher. Aber lesen durch die man Seite für codesign, Ich fand diese nette 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.

Und dann habe ich diesen Beitrag gefunden (https://alpha.app.net/isaiah/post/6774960) vor zwei Wochen (~ Juni 2013), die (wenn auch in zweiter Linie)

@isaiah Ich habe einen Typen in den Labors danach gefragt. Er sagte jetzt Codesign   erfordert, dass eingebettete Frameworks separat vor dem Code signiert werden   das App-Paket als Ganzes signieren.

Manuelles Ausführen der codesign befehle, dass Xcode normalerweise ausgeführt wird, während das Hinzufügen von --deep Flagge bis zum Ende, signiert die Anwendung ordnungsgemäß.

Ich bin mir noch nicht sicher, welche Auswirkungen dieses manuelle Signieren hat, oder ob ich den Xcode-Build optimieren kann, um das hinzuzufügen --deep Flag automatisch, aber das scheint das zugrunde liegende Problem zu sein. (codesign signiert Ihr App-Paket nicht mehr automatisch.)


138
2017-07-01 00:37



Wie in anderen Antworten hervorgehoben, ändert sich die Funktionsweise der Codesignierung. Wenn Sie einen der Xcode 5 DPs installiert haben, werden die neuen Tools auch dann verwendet, wenn Sie Xcode 4.6.X verwenden.

Alles, was Sie zu diesem Zeitpunkt (in Xcode 4.6.X) tun müssen, ist das oben genannte --deep-Flag zu verwenden und es in Ihre Code-Signing-Flags (Ziel, Build-Einstellungen) einzufügen, siehe Abbildung unten.

Specifying Deep Signing of Embedded Frameworks


67
2017-07-01 10:55



Dieses Problem wurde nach dem Ziehen eines Ordners mit dem Namen "Ressourcen" in meinem Projekt verursacht. Nachdem der Name in etwas anderes geändert wurde (zum Beispiel "resourcessss"), verschwand der Fehler.


12
2018-05-18 15:21



Ich hatte das gleiche Problem, aber die Antwort war einfach: Die Code-Signing-Identität in meiner App wurde auf "-" gesetzt, also habe ich das einfach auf "Do not Code Sign" gesetzt.

"-" scheint die Standardeinstellung zu sein, wenn Sie einige Aktionen ausführen, obwohl ich Ihnen nicht sagen kann, was diese sind.


4
2018-06-25 21:14



Dies könnte jemandem helfen:

Ich habe schließlich die Lösung durch Versuch und Irrtum herausgefunden. In meinem Fall hatte ich einen Ordnernamen, der unter Build-Einstellungen mit der Variablen "Produktname" übereinstimmte. Dies entspricht auch dem gesamten Projektnamen! Also habe ich einfach ein Feld gewechselt. Ich habe die "Build-Einstellungen" -> "Produktname" geändert. Der Wert von MySpecialApp wurde in My-SpecialApp geändert. Das war es einfach! Ich loggte mich dann wieder im Apple-Entwicklerportal ein und erstellte eine neue App-ID und mobile Bereitstellungsprofile für die Entwicklung und Verteilung. Der Rest ist Geschichte. Meine Releases funktionieren jetzt, wenn sie über die Ad-hoc-Distribution bereitgestellt werden.     Eine letzte Anmerkung zu diesem Thema. Dies ist definitiv ein Fehler, dass Apple entweder den Benutzer warnen sollte, dass sie etwas falsch gemacht haben und eine Art von automatisierten Korrekturmaßnahmen ermöglichen.     - Siehe mehr unter: http://www.chrisdanielson.com/2012/08/29/codesign-ipa-and-the-code-object-is-not-signed-at-all-problem/#sthash.F0nF3BbC.dpuf


2
2018-06-26 11:00



Für mich war es ein beschädigtes Framework PaddleMA welches: 1. Ich habe meine Cocoapods-Datei entfernt 2. Lief pod install  3. Neustart meines Xcode

und es löste das Problem. Aus irgendeinem Grund wird ein beschädigtes Framework verhindern, dass es signiert wird. Leider zeigt XCode diesen Fehler nicht wirklich deutlich und gibt Ihnen einen guten Reparaturvorschlag. Habe einen Fehler mit Apple behoben.


0
2018-01-08 19:41