AppBorrame.app.rar (524.1 KB)
It seems to me that the three are identical.
Yep. the first one is already not signed properly. weird…
Ok, found the problem. It seems that access to the key chain can be restricted when calling code sign via SSH, as CrossBox does. There should be an error in the log, such as
> codesign: errSecInternalComponent
unfortunately, EBuild did now always recognize this as a failure (that part is fixed, it will fail the build now). I now need to research how to fix this to make kit work properly. Google has many suggestions, none of which worked cleanly for me (such as https://stackoverflow.com/questions/20205162/user-interaction-is-not-allowed-trying-to-sign-an-osx-app-using-codesign), but you might want to try them, too.
I try it later and I tell you.
1 Like
I have not gotten it to work.
I attached a log where several codesign errors appear in a rebuild.
CodesingError.rar (12.5 KB)
im working on a fix. it will probably involve having tor spwcify the keychain passwoed in the project settings, Windows side…
It does make sense.
I’d like to send you a new build of Water that has this fixed, in ~1h.
Ok, thanks. I’ll test it immediately.
Moving forward but with problems.
Water crashes when uploading to the device. Te app is uploaded to the device, but when it’s launching crashes in the phone. Later you can open the app (iOS) without problems.
I have used RB App Checker Lite and the App is signed.
It looks like it happen the same as with Fire, disscused in https://talk.remobjects.com/t/fire-crash-on-debug-run-ios-app/17735
Attached Mac Log, iPhone log and Windows log.
Windows.rar (5.7 KB)
Mac_log.rar (1.5 KB)
iPhone_Log.rar (26.5 KB)
Water crashes, or the app does? How does Water crash, does it show an exception dialog? if so, can I see the details?
It just disappears. Windows.evtx (in Windows.rar) has information about.
Curious
InformaciÛn de la excepciÛn: System.AccessViolationException
en RemObjects.Oxygene.CoreDebugEngine.LLDB.LLDBWrap_StartIOS(System.Runtime.InteropServices.HandleRef, System.String, System.String, IntPtr ByRef)
en RemObjects.Oxygene.CoreDebugEngine.NougatDebugEngine+<>c__DisplayClass7.<Start>b__0(System.Object)
en System.Threading.QueueUserWorkItemCallback.WaitCallback_Context(System.Object)
en System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
en System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
en System.Threading.QueueUserWorkItemCallback.System.Threading.IThreadPoolWorkItem.ExecuteWorkItem()
en System.Threading.ThreadPoolWorkQueue.Dispatch()
en System.Threading._ThreadPoolWaitCallback.PerformWaitCallback()
that seems to be a different exception that the one you had Fire. Carlo is working on a fix, and we’ll get young new build later today.
Thank you. I’m waiting.
Done.
Water
It seems to work, but it is unworkable. It takes a long time to build (3 min in this AppBorrame that has no code), it seems that is hooked in the process of linking (“Phase Linking for Device started”) and in the signed.
When you run it takes several minutes (~ 10 min) to reach the first stop point.
I attached two logs so you can see the times:
Build.rar (5.6 KB)
Run.rar (5.2 KB)
VS
It seems to work, but it is unworkable. It takes a long time to build (66s in this AppBorrame that does not have any code), it seems that it gets hooked in the link process (“Phase Linking for Device started”) and in the signed one.
When you run it takes several minutes (~ 5 min) to reach the first stop point.
I enclose the buid log of VS:
Build.rar (5.6 KB)
Thanks for your effort.