I just tested tonight with our existing system and had no issue. Is anyone else seeing something different?
So far I've done a few apps without issue. Code signed and notarized (via App Wrapper), and still the Kaju updates worked great. In my tests so far, the apps were not being app translocated. Perhaps that is the key here and the issue would be if the app had been translocated.
I do have one app with bundled helper apps, and as soon as I sign and notarize the helper apps don't work. But the update still does. So I'm doing something wrong in my wrapping. But that is for another thread. So far it looks like Kaju is working as designed.
(And off-topic, I tried putting the helper apps in Helpers or in MacOS but I'm still doing something wrong -- unrelated to Kaju.)
Regarding the notarization of Zip files for Kaju, I'm just about to release an upgrade to my app that will include Kaju for the first time. so when I do my next app update, what would the projected workflow be for the update zip file?
Notarize the app?
Notarize the zip file but attach previous receipt?
I do have Sam's App Wrapper.
are there any known problems with Xojo 2019 R1.1 on Windows 10? Update process runs fine (Zip file is downloaded and decompressed, files moved to "<foldername> - decompressed") until user clicks on "Quit & Install", then nothing happens.
Method "StartUpdate" is the last thing executed - UpdateInitiater/Deconstructor is not executed and so the UpdateInitiater/RunScript is never called...
From the Readme:
Important: Kaju does its magic by launching a command-line script when the
UpdateInitiatergets set to
Nil, which should happen when the app quits. Unfortunately, that's not always true so you should force the issue by inserting
App.UpdateInitiater = Nilinto your
thanks for the reply, but thats not the point - as I wrote the update process is running fine (UpdatewIndow is shown, zip file is downloaded and decompressed and files moved) until the last steps (RunScript in Class UpdateIntiater), which is not executed on Windows 10...
Sorry, Tim and Kem - its my fault. The line was commented out - must have happend while testing. Since updates worked fine on Mac I was searching for reasons why the won't work on Windows (except writeprotection in "program files" folder).
After uncommenting the RunScript is executed, as expected...
I did send a message via XOJO forum but I guess that did not get trough.
While seeing the limitations on windows and searching little bit about elevated privileges I found those Link here
In case the page does not work anymore the code was here :
:::::::::::::::::::::::::::::::::::::::::::: :: Elevate.cmd - Version 4 :: Automatically check & get admin rights :: see "https://stackoverflow.com/a/12264592/1016343" for description :::::::::::::::::::::::::::::::::::::::::::: @echo off CLS ECHO. ECHO ============================= ECHO Running Admin shell ECHO ============================= :init setlocal DisableDelayedExpansion set cmdInvoke=1 set winSysFolder=System32 set "batchPath=%~0" for %%k in (%0) do set batchName=%%~nk set "vbsGetPrivileges=%temp%\OEgetPriv_%batchName%.vbs" setlocal EnableDelayedExpansion :checkPrivileges NET FILE 1>NUL 2>NUL if '%errorlevel%' == '0' ( goto gotPrivileges ) else ( goto getPrivileges ) :getPrivileges if '%1'=='ELEV' (echo ELEV & shift /1 & goto gotPrivileges) ECHO. ECHO ************************************** ECHO Invoking UAC for Privilege Escalation ECHO ************************************** ECHO Set UAC = CreateObject^("Shell.Application"^) > "%vbsGetPrivileges%" ECHO args = "ELEV " >> "%vbsGetPrivileges%" ECHO For Each strArg in WScript.Arguments >> "%vbsGetPrivileges%" ECHO args = args ^& strArg ^& " " >> "%vbsGetPrivileges%" ECHO Next >> "%vbsGetPrivileges%" if '%cmdInvoke%'=='1' goto InvokeCmd ECHO UAC.ShellExecute "!batchPath!", args, "", "runas", 1 >> "%vbsGetPrivileges%" goto ExecElevation :InvokeCmd ECHO args = "/c """ + "!batchPath!" + """ " + args >> "%vbsGetPrivileges%" ECHO UAC.ShellExecute "%SystemRoot%\%winSysFolder%\cmd.exe", args, "", "runas", 1 >> "%vbsGetPrivileges%" :ExecElevation "%SystemRoot%\%winSysFolder%\WScript.exe" "%vbsGetPrivileges%" %* exit /B :gotPrivileges setlocal & cd /d %~dp0 if '%1'=='ELEV' (del "%vbsGetPrivileges%" 1>nul 2>nul & shift /1) :::::::::::::::::::::::::::: ::START :::::::::::::::::::::::::::: REM Run shell as admin (example) - put here code as you like ECHO %batchName% Arguments: P1=%1 P2=%2 P3=%3 P4=%4 P5=%5 P6=%6 P7=%7 P8=%8 P9=%9 cmd /k
and in the description it was saying :
The script takes advantage of the fact that NET FILE requires administrator privilege and returns errorlevel 1 if you don't have it. The elevation is achieved by creating a script which re-launches the batch file to obtain privileges. This causes Windows to present the UAC dialog and asks you for the administrator account and password.
I have tested it with Windows 7, 8, 8.1, 10 and with Windows XP - it works fine for all. The advantage is, after the start point you can place anything that requires system administrator privileges, for example, if you intend to re-install and re-run a Windows service for debugging purposes (assumed that mypackage.msi is a service installer package):
Do you think that could be added somehow in Kaju and have it work in Windows ?
Kaju has stopped working on Windows after a failed update. Kaju displayed an error message about the update failing because the file appeared to be corrupt (which it was, that time, because I'd erroneously pointed Windows at the macOS binary). Since then, it's doing nothing. There should supposedly be log files and/or temp files being generated, but I don't see anything in the application directory or the AppData directory (where the Kaju preferences file is located).
Any hints? Anybody?
Figured it out. To nobody's surprise, I'm sure, it was due to another stupid error on my part (when I fixed the error of pointing the Windows update to the macOS binary, I should have changed everything to 64-bit Windows but instead had one thing as just Windows rather than 64-bit Windows).