Auto-update of native application bundles

[Daniel Zwolenski]

Yes, the scenario you described is how I imagined it. The drawback is that the 'swap' progress and success/failure dialogs are native, whereas in mine it's java. As you say if it is just a move then it is relatively quick and can be trivial (although there might also be need to update registry with latest version and uninstall info, and delete old files, especially for delta updates, so error possibilities increase).

I'm not necessarily sold on one solution on this front, just making sure we're aware of trade offs when we choose. Agree that we need feedback on whether we care about native dialogs here or not. 

Note in mine I also version jre, so jre is in 'jre/jre6' and upgraded jre is in 'jre/jre7'. So they coexist too. Similar approach would be used for native libs.

One side benefit of my approach is that if the launcher fails to start after upgrade it could give the user the option to launch using previous app-profile. More a side benefit than intended feature and I reckon your solution could be extended to have something similar if we thought it necessary. 

Regarding how I elevate permissions, I have already something like your 'swap' program. It is launched from Java as a new process requesting elevated privileges (but the java can stay alive and monitor it for results). Only the swap process is elevated, normal app stays at normal user level. 

Note that this program could be smarter and only try to elevate if needed, so if, for example the user chose to install outside of Program Files they wouldn't get UAC prompt to upgrade, it would just work. Your swap program can be coded the same way - I found code on the web for all this, and will dig it up when we need it. Definitely can be done though. 


On 19/06/2012, at 8:58 AM, Igor Nekrestyanov <igor.nekrestyanov at oracle.com> wrote:

> On 6/18/12 3:31 PM, Daniel Zwolenski wrote:
> 
> > In your proposal the classpath is based on what is in the 'app' directory, so if v1 and v2 were there at the same time they would both get included on the classpath.
> 
> It is embedded java launcher that is part of main jar that decides what needs to be taken.
> Not everything in the app folder is used.
> 
> Anyway, here is one possible scenario (it may be somewhat different depending on update type):
> 
> 1. Application is running, update detected
> 2. Update is loaded in background, no UI is shown
> 3. Full application image is built in the temp folder (including runtime, etc.)
> 4. User is prompted to update and relaunch
> 5. If he agrees:
>         - application exits
>         - (optionally) UAC is shown for "swap" program
>         - "swap" program renames existing app folder
>         - moves new image in place of old app
>         - launches new version of application
>         - then cleanup old image
> 
> "move" is fast operation as long as we are on the same drive. No or little UI is needed ("rename" will take 1-2 seconds at most?).
> And if it is needed then in most of cases default UI should suffice.
> 
> It is possible to make it more complex and allow to customize this part of UI but would be good to see if there is a need to do this.
> E.g. we can put another app folder in the application directory and have package.cfg to mention which one is active.
> 
> > The result is that in my POC the new jars can be copied in while the old app is running, whereas in yours it can't. So in my POC the java GUI can show progress and success/error, whereas in yours the java GUI will have to be killed before the copy starts so the progress and success/error will have to be shown in a hard coded native UI.
> 
> So, what if update need to update java.exe or and of dlls or Application.exe?
> Have a different UI?
> 
> How do you elevate permissions to be able to copy files to Program Files?
> Does it mean user application will run with full admin permissions?
> 
> -igor
>