[Fmx, iOS]: Can't start debugserver on device - device support image was not mounted

[Rollo62]

Hallo zusammen,

ich habe gerade das Update Rx10.2.1 gemacht, aber das DebugProblem bleibt ...

1. XCode 8.3.3
2. iOS 10.3.3
3. IDE und iPhone regelmäßig neu gebootet
4. iPhone regelmäßig neu verbungen, mit XCode/Devices synchronisiert
5. PAServer hatte zwei scratch-dir, und viele alte Einträge
6. scratch-dir komplett gelöscht, keine Änderung
7. PAServer + scratch-dir komplett gelöscht und neuinstalliert, keine Änderung
8. PAServer scratch-dir hat jetzt kein Cache-File mehr, wo XCode.app drin stand
   (vermutlich das iOS-Device-Support-Image aus dem XCode-Package)

Was kann das noch sein ?

Meine Vermutung ist das die "Cache" Verzeichnisse im scratch-dir da sein müssen, mit dem XCode.app device support package drin.
Das wird bei mir aber nicht mehr angelegt, siehe Anhang.
Die CacheDir scheinen die Versionsummer der Ide dranzuhaben, das hört bei mir vei 101xxx auf,
würde erklären warum es bei Berlin noch ging.

Ist das jetzt in den neuen Versionen 10.2.x so das kein CahceDir mehr benötigt wird, oder liegt es vielleicht woanders dran ?

Vielleicht hat schonmal jemand mit diesem Problem zu tun gehabt ?
Wäre nett ein paar Tips zu bekommen.

Rollo

[MEissing]

Funktioniert denn eine (minimale, leere) App von/über Xcode auf dem Device?

Häufig ist es der iOS DeviceSupport, der noch nicht/gar nicht abgeschlossen ist (loading symbols)

[Rollo62]

Hallo Matthias,

der Retter naht :dancer:

Ich habe es bisher mit verschiedensten Demos probiert, alles ging nicht.
Du hast Recht, ich habe jetzt eine neue, Empty-App gestartet, und die funktioniert.

Wenn du mir jetzt noch kurz erklären könntest woran das liegt/lag, und wie ich das in Zukunft vermeiden kann ?
Verstehen tue ich es nämlich noch nicht :stupid:

Mit "loading objects" meinst du das Synchronisieren, was z.B. im XCode/Devices Fenster passiert ?
Da bin ich von ausgegangen wenn der Animation-Kreisel weg ist hat Alles komplett geladen.
Meinst du das dies nicht unbedingt schon fertig sein muss, und man länger warten sollte ...

Und wenn ja, warum geht das dann bei einer Empty-App ?

Jetzt kann ich auch wieder eine andere (nicht-leere) App debuggen, muss mal weiter Testen.

Dankesehr, den "Empty-App" Workaround muss ich wohl noch in meiner Liste der Repair-Tools aufnehmen.

Rollo

[MEissing]

Mit einer neuen, leeren App meinte ich eine App in Xcode (auf dem Mac, kein Delphi).

Aber schön, daß es jetzt funktioniert :-)

(Loading Symbols - Ein Vorgang innerhalb von Xcode, wo die Symbolinfomrationen des angeschlossenen Gerätes auf den mac übertragen werden)

[Rollo62]

Hallo Matthias,

seltsam, die leere XCode-App hatte ich heute schon hundertmal gemacht, ohne Erfolg.

Aber eine neue, leere Fmx-App hat es gebracht, warum ?
Gibt es vielleicht neue einstellungen in den DROJ Files, die nach Neuanlage etwas anders machen.

Nach der leeren App liefen auf einmal auch alle anderen Apps durch, zumindest die 3 die ich getestet hatte, incl. Debugging.

Würd mich mal interessieren was das war, wenn jemand einen Lichtblitz hat immer her damit.

Ich hatte es aber schonmal in der Vergangenhet, das Debugging lief, und dann plötzlich am nächsten Tag nicht mehr.
Deshalb bleibe ich jetzt mal verhalten optimistisch :stupid:

Haben die neuen 10.2, 10.2.1 Versionen kein Cache-dir mehr, mit der XCode.app drin ?
Das habe ich jetzt jendenfalls nicht, geht aber trotzdem.
Vielleicht weiss ja jamand was es damit auf sich hat.
Die Debug-Suppot packages sind im XCode-Paket drin, warum sollte man ein Extrakt davon unter dem Cache-dir speichern, und dann noch unter dem Filenamen Xcode.app ?

Rollo

[Rollo62]

Hallo Matthias,

jetzt funktioniert es wieder nicht.
Das hatte ich so schon zig-mal.

Situation:
MacBook Pro, VmWare Fusion, iPhone 7, alles aktuell.
- gestern konnte ich debuggen, Projekte wechseln, etc.

1. hab 4 Projekte+das Empty ausprobiert,
2. iPhone auch mal ein- ausgesteckt
3. In den Projektverzeichnissen habe ich ein Clean-Batch, was wirklich Alles löscht, auch das mache ich öfters und i.d.R. vor jedem Platformwechsel
4. Der letzte Zustand war: Alle OK

- über nacht iPhone raus an die Ladestation, dann Mac Deckel zugeklappt
- heute morgen: wieder der bekannte Fehler

So hatte ich das schon zig-mal, und es hilft dann i.d.R. nichts (XCode-Projekt starten, Neustarts IDE, OSX, iOS, etc.) um den Rechner wieder hochzubekommen.
Das XCode-Projekt starten mache ich mittlerweile bei jedem Problem mit der Verbindung.
Auch habe ich oin der Regel XCode im Hindergrund mit den /Devices Window an, um da reinzusehen.

Zum Schluss hatte ich es eigentlich schon akzeptiert das Debuggen nicht läuft, und auf Upd1 gehofft.

Was könnte das hier noch sein ?
Ich versuche gleich nochmal den leeren App Trick, mal sehen ...

Update
- Die leere App funktioniert jetzt auch nicht mehr, Fehler s.o.
- Eine neue, leere App funktioniert auch nicht
- Natürlich habe ich auch die alte App vorher auf den Phone gelöscht
- Gemäß einem Tipp habe ich die DeviceLogs gelöscht, läuft immer noch nicht
- Neu einstöpseln hilft auch nicht
- iOS neu Booten: Ok, das hat heute mal geholfen ... die leere App läuft wieder ...

Update2
!! Nachdem es gerade noch wieder einmal funktioniert geht es jetzt schon wieder nicht.
Auch nicht mit der leeren App.
So kenne ich das schon seit Wochen (erst mit 10.2 Tokyo), Berlin hatte sowas gar nicht.

Update3
Ich habe jetzt nochmal in XCode/Devices/View DeviceLogs all Logs gelöscht.
Vorher hatte ich "This Device" ausgewählt, jetzt nochmal mit "All Logs",
danach konnte ich wieder debuggen.

Vielleicht liegt es daran, habe das hier dazu gefunden,
https://stackoverflow.com/questions/...-devicesupport
vielleicht muss man mal richtig aufräumen, ich habe mich das aber noch nicht getraut.

Update4
Habe dies hier noch dazu gefunden, und das hier schön beschrieben, traue mich aber noch nicht da etwas zu Löschen.
Denn die Infos sind schon etwas älter, und nicht zu XCode8.3.3
Wird das wirklich re-created wenn ich ein Device reinstecke ?

Es bleibt also bis auf Weiteres noch dabei: Wenn ich mal debuggen kann geht auch Alles wie Erwartet über die ganze Session.

Sobald der Wurm drin ist kann ich machen was ich will, kein Debugging möglich,
aber zumindest die App kann deployed werden und ist lauffähig zum Test.
Neu Booten half in der Vergangenheit auch nicht immer.

Gibt es nicht ein Rezept was sicher immer hilft, hat denn sonst niemand dieses Problem ?
Das Update3 werde ich noch beobachten und mich mal melden wenn es wirklich hilft über mehrere Sessions.

Rollo

[mensch72]

halbwegs sicheres IOS Debug...

Unsere IOS Fraktion arbeitet zwar wie wir alle Hauptsächlich mit BerlinU2, aber TokyoU1 funktioniert mit XCode8.3.? funktioniert mit IPhone6s und IPad"2017" reproduzierbat sicher, wenn folgendes gemacht wird:

1. Ein "Cleaner MAC"(also OSX neu, nur EIN XCode neu drauf, nur 1x die aktuellen Zertifikate geladen, nur EIN PA-Server installiert) wurde per VMware Fusion so virtualisiert, das die Nutzung die virtuelle Harddisk nicht verändert, heißt man hat bei jedem Reboot der VM 100% sicher wieder das unveränderte System ohne jegliche Dateileichen
2. Ein "Cleanes Delphi"(also Win10(1511) neu, nur EIN Delphi(TokyoU1) per ISO installiert, nur die FMX Komponenten in der IDE, welche auch wirklich IOS kompatibel sind) wurde per VM-Workstation auch so virtualisiert, das die Nutzung die virtuelle Harddisk nicht verändert, heißt man hat bei jedem Reboot der VM 100% sicher wieder das unveränderte System ohne jegliche Dateileichen.

Wenn man "artig" ist, startet man beide VM's auf einem MAC unter Fusion, ich gebe aber zu das wir auch sehr gute Erfahrungen mit dem Einstatz auf reiner PC-Hardware mit einer leicht angepassten VWwareWorkstation haben.

-> unser Grundprinzip für Test&Deploy: wir wollen bei jedem Neustart 100% die gleichen (Test)bedingungen, alleine schon zu Archivierungszwecken
-> ich kann schon unter Windows kaum noch sagen was welches Programm oder Update an Dateien/Einstellungen ändert oder irgendwo hinterlässt
-> unsere MAC Fraktion kann das für ihre OSX Arbeitsumgebungen auch auch nicht mehr sagen
-> per VMs kann man auch sehr simpel mal Fix BerlinU2&XCode8.3 gegen TokyoU1&XCode8.3 parallel testen, man braucht nur genug RAM für 4VMs im HostPC

Selbst wenn ich "jetzt" wüßte welche Verzeichnisse oder Dateien ich wo stets "manuell aufräumen" müsste, wäre mir das zu müßig und ohne Garantie das sich beim nächsten Update von OSX,XCode,PAserver,Delphi nicht doch wieder was ändert... VMs mit Auto-HardDisk-Reset sind mir da gefühlt langzeit stabiler

[Rollo62]

Ich mache es ja fasr genauso, alles möglichst clean in einer Vm.
Nur eben den MAC Hoste hatte ich bisher ausgelassen.

Die Trickserei mit mehreren Xcode Versionen musste ich auch erst seit Rx10.2 machen.
Es ging aber dabei um das AppStore Deployment.

Das man die alten Xcode Versionen mal aufräumt macht auch Sinn für mich.
Weil ich sonst nichts auf dem Host mache habe ich den bisher nicht immer neu aufgesetzt.
Apple ist ja so super und es sollte keine Probleme solcher Art.
Muss ich wohl doch jetzt mit auf die Todo Liste nehmen

[MEissing]

Ganz banale Idee: Anderes USB-Kabel mal getestet?

[mensch72]

@MEissing

naja, besser wie org. Apple USB Kabel geht doch kaum... aber stimmt schon, billiges USB<->Lightning Amazon-Kabel an einem PC-USB3 Anschluss ist nicht 100% stabil zu einer OSX-XCodeVM... aber wir gehen doch davon aus, das Rollo62 ein org. Apple Kabel zum Anschluss seines IOS Gerätes und einen org. MAC verwendet.

Dennoch könnte es eine Art von ConnectionHold Problem sein.. wenn ich zu, PAserver auch ITunes und XCode offen habe(also per USB zum IOS Gerät "immer" etwas los ist, läuft es am stabilsten...

=> Frage in den Emba-Demos sieht man quasi immer 1:1 den Bildschirm eines IPhone (?im OSx oder in der DelphiVM?).. was für ein Tool nutzt ihr bei Emba dafür?... Eventuell ist ja genau das der Trick für echtes permanentes ConnectionHold so dass ihr bei Emba garnicht die Probleme mit dem Start einer Debugverbindung über ein "schlafendes" USB-Connect kennt ?!?

[Rollo62]

Ok, ist ein relativ neues Orginalkabel.
Werde ich nochmal checken, ist aber unwahrscheinlich.
Denn XCode startet ja immer Alle Apps ohne Probleme.

Rollo

[MEissing]

- SDK neu importieren (nach löschen aus Delphi und dem Windows Explorer)
- PAServer-Scratch-Dir löschen (auf dem Mac, komplett)

- Firewall (Win/Mac) schliesse ich mal aus, da es ja manchmal klappt. Oder ist da noch irgendeine weitere "Sicherheitssoftware" installiert (Win-VM, Mac Host)?

[Rollo62]

Ich will nochmal eine Rückmeldung geben.

Ich habe versucht mich vorsichtig ranzunähern, was jetzt hilft, und was nicht.

Also das Aufräumen des XCode-Verzeichnises scheint ein Wesentliches Problem gelöst zu haben.
Danach konnte ich zumindest von "gar nicht mehr debuggen", wieder auf "die meiste Zeit debuggen" rücksetzen.

1. - alte XCode Verzeichnisse im Cache lösen: Danach ging wieder was
2. - Kabel gecheckt: Hab ich gemacht, war bei mir nicht das Problem
3. - SDK neu importieren: Hab ich gemacht
   (nach löschen aus Delphi und dem Windows Explorer): Hab ich noch nicht gemachtz
4. - PAServer-Scratch-Dir löschen (auf dem Mac, komplett): Hab ich gemacht
5. - Firewall (Win/Mac) schliesse ich mal aus, da es ja manchmal klappt. Das bringt hier nichts

Die Situation jetzt ist die Folgende:

1. - normalerweise funktionierts
2. - wenn es mal hakt, dann reicht wieder das übliche "Stecker raus, Stecker rein",
   und XCode/Devices auswählen
3. - wenn es damit nicht getan ist reicht zusätzlich iOS aussöpseln, iOS neubooten
   Project Clean (iOS.. Verzeichnisse löschen), BuildAll, ...

Wenn es dan läuft, dann ist es OK meistens über die ganze Session oder den ganzen Tag.
Wie gesagt, sporadisch, aus heiterem Himmel kommt immer mal wieder der besagte Fehler.
Auch jetzt noch.
Nur ist es eben akzeptabel, denn wenn es s.o. rückgesetzt wurde funktionierts auch wieder.

Das es nicht immer ein Wiedereinstöpseln hilft könnte ich mir dadurch erklären:

1. - Vielleicht muss man Warten mit Refresh, bis das Device aus dem Projekt/IOSDevice/Target wirklich verschwunden ist
   (Da war ich bisher anscheinend immer ein bischen zu schnell).
2. - Dann erst Wiedereinstöpseln.

Das werde ich jetzt noch mal versuchen.

Mich würde interessieren was Ihr für Erfahrungen mit dem Ein- Ausstöpseln gemacht habt ?
Ich bin doch sicher nicht der Einzige der so was machen muss :stupid:

Rollo

[Der schöne Günther]

Ich musste für den Mac einmal eine neue XCode-Version über den AppStore runterladen und installieren, ansonsten habe ich für iOS eine Windows-VM mit RAD Studio die ich immer wieder zurücksetze. Bei iOS ist es eigentlich immer nur dranstecken, Gerät erscheint sofort im RAD Studio, fertig. RAD Studio ist 10.1 Berlin mit Update 2.

[Rollo62]

Hallo Günther,

ja dankesehr für die Info.
So eine Konfiguration habe ich auch, MacBook, VmWare, Win10, ...
und so verhielt es sich auch bei mir, bis XCode 8.2.2 oder so, als iOS10.3.x nicht mehr richtig unterstützt wurde.
Die Abhilfe dazu waren mehrere XCode Versionen parallel zu installieren.

Seit Tokyo 10.2 kam dan das besagt Debug-Problem.

Die XCode-Version habe ich mittlerweile rausgeworfen, weil Rx10.2 mit XCode 8.3.3 das iOS 10.3.3 bespielen kann.
Trotzdem bleiben die sporadischen Debug-Aussetzer.

XCode kann man ja übrigens nicht so einfach löschen und neu laden, da muss man einiges aufräumen.

Das Aus- Einstöpseln, auch für andere iOS Fehler, musste ich aber schon seit Rx10.0 gelegentlich machen.

Matthias hatte ja auch schon diesen Aus- Einstöpseltrick vorgeschlagen.
Ohne den würde es schwierig werden, ich glaube das müsste jeder iOS Entwickler irgendwann mal Nutzen müssen.

Was ich meine ich dass man womöglich beim Ausstöpseln solange warten muss bis unter Project/IOSDevice/Target das Phone auch wirklich verschwunden ist.
Das kann bei mir schonmal ein paar (10-15) Sekunden dauern, in XCode/Devices ist es aber sofort weg.

Das könnte vielleicht ein Grund sein warum es mal hilft, und mal nicht ?
(wenn man es mal wieder zu eilig hat ...)

Was ich ergänzen könnte war auch ein mögliches Problem mit VmWare, wenn der vmware-vmx Prozess plötzliche 200% CPU-Zeit zieht, ohne das in dem Wim10 Gast irgendwas passiert.
Das hatte ich auch etwas aufgeräumt, so dass diese Lastspitzen jetzt nicht mehr auftreten.
Das war wohl ein bekanntes Problem mit VmWare Fusion, sollte auch in der aktuellsten Version OK sein.

Rollo

[Rollo62]

Nochmal ein Statusbericht:

Bis heute ging es "normal", also Probleme relativ selten, aus- einstöpseln hatte meist schnell geholfen.
Seit heute morgen habe ich dann verstärkt versuchen müssen den Fehler wieder wegzubekommen.

Der Reihe nach mehrmals:

-01 Ausstöpsel iPhone
-02 Refresh und warten bis die IDE das Symbol aus der Liste verschwindet
-03 Einstöpsel iPhone
-04 Auf XCode/Devices das Phone auswählen
-05 Refresh und warten bis die IDE das Symbol wieder in der Liste hat
//
-06 Fehler bleibt, also als nächstes mit iPhone Reboot
//
-07 Ausstöpsel iPhone
-08 Refresh und warten bis die IDE das Symbol aus der Liste verschwindet
-09 Reboot iPhone
-10 Einstöpsel iPhone
-11 Auf XCode/Devices das Phone auswählen
-12 Refresh und warten bis die IDE das Symbol wieder in der Liste hat
//
-13 Fehler bleibt, also noch ein paar Mal versucht 01-06/07-12 (manchmal hilfts erst beim 2-3 Mal)
//
-14 Auf einmal kam statt DebugServer-Fehler der bekannte 0x80002d Fehler
//
-15 Also nochmal Zyklus 07-12
//
-16 !! Danach gings wieder (der 0x80002d Fehler lässt sich bisher gut beseitigen)

Ich liebe Systeme die sehr vorhersagbar sind, OSX/iOS ist das leider nicht.
Die folgenden Eskalationsstufen musste ich für die Fehlerbehebung heute noch nicht machen:
- PAServer resetten mit /r
- PAServer neustarten
- IDE neustarten
- Win10 neustarten
- VmWare neustarten
- Mac neu starten

Bisher bleibt es also bei meiner funktionierenden Methode:

- alte XCode Verzeichnisse im Cache lösen: Danach ging wieder was
- Kabel gecheckt: Hab ich gemacht, war bei mir nicht das Problem
- SDK neu importieren: Hab ich gemacht
(nach löschen aus Delphi und dem Windows Explorer): Hab ich noch nicht gemachtz
- PAServer-Scratch-Dir löschen (auf dem Mac, komplett): Hab ich gemacht
- Firewall (Win/Mac) schliesse ich mal aus, da es ja manchmal klappt. Das bringt hier nichts
- und dann bei Fehler Zyklen 01-06 und 07-12, teilweise mehrmals

Das die IDE/PAServer ein Problem hat schliesse ich mittlerweile aus, weil man das System s.o. wieder ans Laufen bringt.

Das blöde ist nur das diese ganze Fummelei mal locker 30-60 Minuten dauern kann bis es wieder läuft, und dann plötzlich geht es wieder und bleibt auch den Tag oder Tagelang so.

Falls noch jemand einen Tip hat wie man das schneller in den Griff bekomment wäre ich sehr dankbar.
Ich werde nächstes mal versuchen einmal Zyklus 01-06 (das hilft in 90% der Fälle),
dann 07-12, und wenn das nicht sofort hilft einmal Win10 und VmWare neu booten.

Ich hoffe das ich bald mal eine idiotensichere Regel finden kann :stupid:

Rollo

[Rollo62]

Ich will hier nochmal berichten von der langen Odysee mit dem Debug-Problemen,
welche wohl durch verschiedene XCode Versionen hervorgerufen wurden:

Bin jetzt endlich dazu gekommen VmWare mit MacOs auszutesten, und was soll ich sagen:
Debuggen von iOS funktioniert auf Anhieb wieder, in der cleanen VM :-)

Jetzt bin ich auf folgender Konfiguration

• VmWare Fusion 10.1

• MacOs 13.2

• XCode 9.2

• Win10 1703 (im Moment hakt hier das Update zu 1709, muss ich wohl neu aufaetzen)

• Rx10.2.2 Tokyo

Wieder kann ich nur sagen: Virtualisieren, Virtualisieren, Virtualisieren ...
Da hab ich mich mal wieder selbst nicht an mein Motto gehalten, und prompt Probleme geerntet.

Die virtuellen Maschinen haben mir mal wieder den Tag (das Leben) gerettet, das Ganze ist definitiv sein Geld wert.

Jetzt arbeite ich auf sauberen VM-MacOs-XCode9 mit VM-Win10-Rx10.2.2, und
ich kann jederzeit bequem zwischen verschiedenen Versionen/Konfigurationen wechseln.

Ok, das VM-MacOs Image ist auch schon 31GB groß, und es dauert etwas beim Kopieren, aber das Alles ist unter USB3.0 viel weniger Stressig als noch mit echter Hardware herumzufummeln.

Das es wieder geht bestätigt meine Vermutung mit dem DebugProblem:
Das nämlich mein reales MacOs nach mehreren Updates und XCode Aufspielungen und Frickeleien nicht mehr "sauber" ist.
Irgendetwas hat wohl im alten System gehakt, das wäre nur mit einem echten System-Reset und Update auf dem Hardware MacOs zu bereinigen gewesen.
Den spare ich mir jetzt durch die VM's.

Mit der sauberen VM kann ich jetzt wunderbar arbeiten, ohne Altlasten,
und bei irgendwelchen Updates mache ich

• vorher einfach eine Kopie der ganzen VM und installiere dann,

• oder ich nehme wieder ein jungfräuliches, cleanes VM, je nach Notwendigkeit.

Das auch die VM mit MacOs so gut läuft hätte ich nicht erwartet, und ich kann jedem
VmWare Skeptiker nur raten:
Macht soviel virtuell wie möglich, das erspart euch eine Menge Nerven.

Nach dem Großreinemachen über Weihnachten bin ich jetzt wieder flott, und warte auf das nächste größere Desaster, sei es Win10, iOS, Android oder was auch immer :stupid:

Jedenfalls Notiz an mich selbst: Egal was kommt, immer zuerst virtuell Denken :-D

Rollo

[Darlo]

Was ist denn dein Host-System? Welche Hardware?

[Rollo62]

Unter OSX mit einem MacBook Pro, hauptsächlich wegen der direkten Bluetooth Unterstützung und dem schnellen Debugging.

Vorher hatte ich einen Win7 Rechner mit VmWare für Windows, aber seit ca. 4 Jahren bin
ich fast komplett auf OSX als Host umhgezogen.
Macht vieles einfacher und direkter für die OSX und iOS Entwicklung.

Seit ca. XE7 lief es auch ganz zufriedenstellend, nur seit letztem Jahr, und den vielen halbgaren Updates von Apple war der Wurm drin.
Jetzt habe ich Hoffnung das es erstmal wieder so stabil läuft wie vorher.

Rollo

[arnof]

Gleiches Problem:

MAC OS aktualisiert; xCode neuster Stand und Rio neuster Stand.

App kam am iPhone an ; aber in Delphi Meldung siehe oben.

Lösung:

XCODE einmal starten und das Devicestool einmal öffnen; da stand das das Gerät Busy ist und nicht Debugger kann -> warten-> Gerät wird automatisch vorbereitet-> Meldung geht weg-> Delphi geht auch wie es soll ;-)

[Rollo62]

Hallo arnof,

da hast Du Glück gehabt.
Normalerweise funktioniert es gut, und Tage/Wochen ohne Problem.
Aber wenn es kommt, dann kann es mal schnell gehen, wie bei dir, oder auch hartnäckig bleiben.

Deshalb habe ich mal meine Checkliste der Möglichkeiten die geholfen/empfohlen werden gemacht:
DebugServer not mounted: # may be enough sometimes
- Check Connection
- Check Provisioning in Options, use right Wildcard
- Check & sync. Target device (sometimes old device is still visible)
- # 1. Try Clean Project
- # 2. Try remove App (via XCode/Devices & Simulators/Apps Delete)
- # 3. Try Close PAServer
- # 4. Try Delete PAServer ScratchDir
- # 5. Try Unplug
- # 6. Try Shutdown iOS
- # 7. Try Close RadStudio
- # 8. Try Close XCode
- # 9. Try Re-Boot VM-OSX
- # 10. Try Re-Open XCode
- # 11. Try Re-Boot iOS
- # 12. Try Re-Plug w/ XCode/Devices&Simulat. open, watch "yellow" DebugServer update
- # 13. Try Re-Start PAServer
- # 13. Try Re-Start RadStudio
- # 14. Try Open Project w/ iOS64
- # 15. Try Check Connection (Project\Edit Connection\Test)
- 16. Try Check SDK (Project\SDK)
- # 17. Check Project settings: Debug --> Development
- # 18. Try Sync. Device (Select Target device)
- # 19. Try BuildAll Project (Debug\Development)
- # 20. Try Debug Project (Debug\Development)
- 21. Try Start XCode dummy project
- 22. Try Start RadStudio dummy project
//
- 23. Try Update latest iOS

Muss nicht immer Alles gemacht werden, aber oft sind einige Schritte nötig.
Ich bin immer noch dabei mal eine definitive Checklist hinzubekommen, das Dumme ist nur das es sich anscheinend jedes Mal anders verhalten kann.

Hier sind die Provisioning-Probleme noch gar nicht mit eingerechnet, die kommen bei mir Ende Mai wieder auf mich zu :stupid:

[Rollo62]

Nochmal ein Nachtrag:

Ich habe gerade wieder mal den Fall gehabt, und der "einfache, kurze" Weg hatte wieder nicht gereicht,
ich musste
- # 9. Try Re-Boot VM-OSX ausführen.

Vorher hatte es aber im RadStudio beim Sync'en des iPhones (es war immer dasselbe an dem PC)
eine Exception "ListIndex out of bounds (- 1)" gegeben, bei dem Öffnen der Auswahl der Devices.

Für mich scheint das so als würde RadStudio nicht immer mitbekommen wenn das iPhone an und ab-gesteckt wird,
denn ich sehe oft das bereits lange abgestöpselte Geräte noch in der Liste angezeigt werden.

Weil das am Ende eine Info ist die wohl von XCode oder sogar vom drunterliegenden Macos kommt ist es verständlich warum XCode und evtl. VmWare Images geschlossen werden müssen, wenn irgendwo im System noch ein "Zombie" des Gerätes herumspukt.

Mittlerweile habe ich mich dran gewöhnt, dass dies mal ab und zu alle paar Tage passiert.
Blöd ist nur das der ganze Prozess immer locker 5 Minuten dauert, Zeit für eine Kaffepause :stupid:

Wenn jemand eine bessere Erklärung hat, oder sogar einen einfacheren Workaround dafür, würde ich mich sehr freuen eine Info zu bekommen.
Denn das Problem nervt mich jetzt schon seit mehreren Jahren.

[Rollo62]

Nochmal hier das immer wiederkehrende Thema.

Auch Jim McKeeth hat dazu was verfasst.

Das ist leider etwas verkürzt, was dem noch hinzuzufügen wäre:

• ! Nach dem Update sollten iOS und MAcos einmal nei gestartet werden
• Dann am Besten MAcos starten, und
• XCode starten, mit dem geöffneten Devices Window (ist noch leer)
• Dann ersat iOS booten und verbinden
• Warten bis im XCode Devices-Fenster das Phone angezeigt wird
• Dort sollte nach einem Update zumindestens einmal ein gelber Hinweis im oberen Bereich stehen.
• Auf jeden Fall warten bis das Kopieren abgeschlossen ist, denn das kopiert das besagte DebugImage zum iOS.
• Dann mache ich immer noch ein neues XCode Projekt mit dem aktuellen SDK, und erzeuge einmal
  ein leeres XCode Projekt und starte das auf dem iOS Device.
  ! Damit kümmert sich XCode darum das iPhone mit neuem iOS einmal komplett einzurichten,
  inclusiver Provisioning File, etc.
  Damit Alles zusammenpasst nedde ich das leere Projekt 1:1 wie mein Projekt (gleiche Bundle ID).
• Auch nicht vergessen das neue iOS im SDK-Manager upzudaten und auszuwählen, denn sonst kompiliert man gegen das vorherige SDK.

Das Problem ist wenn das DebugImage mal vergurkt ist, dann kann man das eventuell nicht mehr so einfach draufbekommen (da hatte ich schon öfters mal was versucht, ohne Erfolg).
Deshalb ist der erste Schritt nach einem Update so wichtig.