Kaju self-updater talk (v.2.x)

I’m new to Kaju, but it looks like a great addition to my app.

Unfortunately, I’m running into a problem with the Windows install. My zip file includes the VComponents files for Valentina. The log shows a failure trying to copy the vresourses folder into the install location. The relevant section of the log is below:

"Looking for item C:\\Program Files\\BC Kaju Tester\\vresources" "...found, copying" C:\\Program Files\\BC Kaju Tester\\vresources\\* The system cannot find the file specified. 0 file(s) copied. "...FAILED! (Error 1)" "Attempting to restore old application"

On first glance, it appears to me that the script will not handle subfolders when copying the contents of a folder.

Could this be the case? I created a test app that does not use Valentina and all works fine.

Could there be an invisible character in the folder name or in one of the file names that are gumming up the works? Does that folder have files in it? If you replace the contents of that folder with, say, a text file with an innocuous name, does it work? If you remove that folder but include another with an innocuous name and an innocuous file, does it work?

FWW Kagi doesn’t work anymore with a ‘future’ macOS.
It gives a warning the downloaded .zip file is from an unidentified developer and it does not unzip the file.
It looks like the only way to upgrade is to use a Notarized .pkg file.

That’s a major bummer.

Ug

[quote=440421:@Kem Tekinay]Could there be an invisible character in the folder name or in one of the file names that are gumming up the works? Does that folder have files in it? If you replace the contents of that folder with, say, a text file with an innocuous name, does it work? If you remove that folder but include another with an innocuous name and an innocuous file, does it work?

Like [/quote]

Here is the directory structure that failed:

Here is what I tried:
• I removed the Valentina files completely and the update worked as expected.

• I created another version with the Valentina files removed and an innocuous folder with the same structure as vresourses - a folder with one subfolder containing a text file. This worked as expected.

• I created yet another version that included the Valentina dlls but not the vresources file, and that worked.

• I created a version that included the vresourses files, but I retyped the folder names manually to insure there were no special characters. This failed.

The good news is that I really don’t need to reinstall the Valentina files as I have no expectation they will change unless I renew my license and upgrade to a later version. They will be installed via the initial upload of my software. But it is puzzling that this folder will screw up the works.

Interesting.

Suggestion: include this folder zipped, and have your app examine it on startup. If the installed files are missing, or you’ve somehow determined that the downloaded files are newer than the installed, you can install/re-install them. The switch Kaju includes when it launches your updated app can help here.

Or you can store the hash of the zip file in your preferences and compare that on launch to see if the file has changed.

[quote=440531:@Kem Tekinay]Suggestion: include this folder zipped, and have your app examine it on startup. If the installed files are missing, or you’ve somehow determined that the downloaded files are newer than the installed, you can install/re-install them. The switch Kaju includes when it launches your updated app can help here.

Or you can store the hash of the zip file in your preferences and compare that on launch to see if the file has changed.[/quote]

Thanks for this suggestion, but I’ve been using these Valentina files since 2015 without a change. As a hobbyist, I don’t expect to upgrade until I’m forced to as all is working well. So, I’ll just leave them out of the install. This is a nice feature of Kaju that it only replaces what you give it so I can get away with this.

As I have time, I may fiddle around with this to try your solution or figure out why it won’t work the way I had it just for my own satisfaction. But for now I’m going to go forward with what I have that works.

Thanks for your help and for providing this product.

[quote=440460:@Christoph De Vocht]FWW Kagi doesn’t work anymore with a ‘future’ macOS.
It gives a warning the downloaded .zip file is from an unidentified developer and it does not unzip the file.
It looks like the only way to upgrade is to use a Notarized .pkg file.

That’s a major bummer.[/quote]

I’m looking to add self-updating capability to macOS apps, but don’t know how to interpret the above statement. This is for non-MAS store apps.

Is Kaju still viable for use with Catalina? What effect, if any, does Notarization have on the process? Does having bundled helper apps included (as part of the *.app) make a difference?

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?

Codesign app.
Notarize the app?
Notarize the zip file but attach previous receipt?

I do have Sam’s App Wrapper.

Thanks

Hi,

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 " - 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…

Any ideas?

From the Readme:

Hi Tim,

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…

Are you saying that you added that code to the Close event as specified in the Read Me that Tim highlighted, and it still isn’t working?

1 Like

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…

Hello Kem,

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[/code]

and in the description it was saying :

[quote]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):[/quote]

Do you think that could be added somehow in Kaju and have it work in Windows ?

Thanks again.

Possibly, but it’s not a priority for me. Feel free to do a pull request off of the develop branch and I’ll consider it.

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