Silent Check for Update but Visible Install

[lledden]

It seems the ideal setup for my typical application is that the 'check for available update' task should be completely silent (no UAC dialog) and if an update is available then a prompt should appear and a visible installation should start. I've been researching this a bit and experimented with using the UpdateAction tool from Ulrich but this approach doesn't appear to be possible with that tool since it requires a completely invisible/silent installation.

Has anyone attempted something like this or are there any suggestions as to an approach. Thanks in advance.

[Ulrich]

There are different situations possible with TrueUpdate:

1. Silent until an update is available
   
   The global variable g_SilentUntilUpdateAvailable will allow you to perform an update check, and exit silently if no newer version was published. Only when an update exists, the Welcome dialog (or whatever you are using) would be displayed on the desktop. The UAC dialog would be shown when the patch / update installer is started - which is a different process to the TrueUpdate client.
   
   
2. Interactive or silent update check, no UAC prompt
   
   Again, using g_SilentUntilUpdateAvailable, you can start the TrueUpdate client and have it show an dialog only when a new version is available. However, instead of asking for administrative privileges by showing the UAC, you can perform the tasks requiring elevation using the UpdateHelper tool you mentioned. Yes, the update installer or patch executable needs to be silent for this to work, but not the update check (the TrueUpdate interface) itself.
   

If you install the TrueUpdate into the ProgramFiles folder, then it can't run without administrative privileges, because it can't update itself at that location while running as logged user. For this reason, I always recommend that the update client is deployed into a sub folder of %ApplicationDataFolderCommon%.

Ulrich

[lledden]

Thanks Ulrich, I'll investigate further.

[NickG]

I'm having this problem too. My customer doesn't want the UAC prompt each time the app starts up.

I have made the mistake in putting the updater in Program Files, so am I right in thinking that I will have to move it to %appdata% in order for it to be able to update itself? I have briefly tried running my updater from this folder, but as I've changed the elevation level, it prompts for the app updater to be restarted. It successfully downloads a new version (.ts3) but it doesn't replace the original updater - if you start it again it still thinks an update is needed and just loops. So unless I'm doing something wrong, it doesn't seem like using %appdata% works?

[Ulrich]

It is hard to diagnose what you missed, but if the exe file does not get replaced, it is possible that the user account has insufficient privileges. If the file was deployed by an admin, the user may not be able to delete the file, even when it is a "public" folder.
I cover most of the issues in my post, have you read it?

Ulrich

[NickG]

Yes, I've read your post - that was what lead me to using %appdata% in the first place. However I'm not confident to proceed unless I can find out why the updater can't update itself. It doesn't write any errors to the log - it just says it needs to restart and then just exits. Is it supposed to physically replace the existing updater.exe or should it just start the new instance from a separate .exe?

[Ulrich]

The current executable will run the *.ts3, which then will replace the *.exe, unless of course the folder or executable is not writable.

Ulrich

[NickG]

Is there a reason why %appdata% might not be writable when logged in as an Admin?

[NickG]

..Actually I think the folder must be writeable as it's successfully creating the log file and downloading the .ts3 to it.

[Ulrich]

Hum... I am not sure what you mean. Being logged in using an administrator account is not the same as running as administrator, right? So even if your user account is an administrator, you still have "normal" privileges, and you still may be unable to write in a folder or replace a file created by a process running "as administrator" (with elevation). This is why I state in my post that you should set the permissions on the folder (and the files in it), making sure that a non-elevated process can write in it, and replace the files later.

Ulrich

[4Shoda]

Ulrich -

I read over all your information and I still don't get it. I guess because your example talks about a ZIP being extracted and I'm trying to run a program update (exe) which we download from an FTP site using TrueUpdate. I have the TrueUpdate program working silently but as soon as I try to actually run the program update (the exe installer) I get the error message.

From what I understand from reading your information, when our program is originally installed we need to install the original "true update" files in a special folder and then use my installer to change the security permissions on that folder. I don't actually write the installer code but I believe we use Setup Factory and the TrueUpdate files can be written to our programs data folder where the .ini file lives.

And then I think I have to also put in the update helper into that same folder and somehow have it running on my customers computers as a service? Not quite sure how to do that but I think where I really get confused is after my TrueUpdate program downloads my update to a subfolder of my programs data folder. Do I have to then use the update helper to copy that file from one folder to another which changes its permissions so I can run it and trigger the UAC? But then how is it started?

Sorry but a lot of what you include in your documentation is a little bit over my head.

Thanks for the help!

- Lisa

[Ulrich]

(.…) as soon as I try to actually run the program update (the exe installer) I get the error message.

Sorry, you forgot to mention what "the error message" is.

(…) I believe we use Setup Factory and the TrueUpdate files can be written to our programs data folder where the .ini file lives.

If you do that, you need to run TrueUpdate as administrator. The point of this thread was to explain how you can execute the update client without needing to grant user elevation. Of course, there is no problem in running TrueUpdate "as admin", but in most cases this is not needed: for a simple check if an update is available, there would be no modification of the user's system, so everything could be done with "as invoker".

And then I think I have to also put in the update helper into that same folder and somehow have it running on my customers computers as a service? Not quite sure how to do that but I think where I really get confused is after my TrueUpdate program downloads my update to a subfolder of my programs data folder.

This is an approach which should be implemented when the first version of your product is installed, so any future updates could be performed silently, in the background, without user interaction. This is a very specific use, and you may not need this for your application.

Sorry but a lot of what you include in your documentation is a little bit over my head.

If you wish to share the project files privately for consulting, I may be able to advise you what you could do to make the update procedure smoother.

Ulrich

[4Shoda]

Hi Ulrich,

It is a new program that we are releasing. I am setting up the program to do the silent check for updates or to allow for a manual "force" check for updates by passing an argument to TrueUpdate program. So, yes, I'm trying to implement what you suggest and have downloaded the updatehelper trial version for my testing prior to deciding if this approach will work. I have my TrueUpdate program running as invoker as suggested.

The program is installed in the Program Files folder and the ini files and TrueUpdate files are in the Program Data folder. When I download the update of our program, I write the file into a sub folder off the Program Data folder and use the TrueUpdate server files to launch it. That is when I get the error that you describe in your articles - the executible won't run because it doesn't have enough privileges. Specifically, TrueUpdate reports "Unable to execute installer/patch file. File execution failed, elevation required."

So to clarify my questions....

(1) If I change the security of my programs "Program Data" folder, do I need to then copy my executible around after I download it so its priveldges change or will I be able to use UpdateHelper to just run it. Your example talks about extracting a ZIP not running a program.

(2) Who makes sure the UpdateHelper service is running - the Setup Factory installer or the TrueUpdate program?

(3) Is the Program Data folder the appropriate place to put these files? I thought it was preferable to the user's application data which is buried and it is easily accessible by all users of our software on the computer.

(4) For testing this prior to release, I assume I can manually change the security of the TrueUPdate folder without doing a thing to the installer?

Thanks for your help. I'm happy to pay for the UpdateHelper but don't really think I need a consult. Just a little nudge in the right direction.

- Lisa

[Ulrich]

(…) I have my TrueUpdate program running as invoker as suggested. (…) TrueUpdate reports "Unable to execute installer/patch file. File execution failed, elevation required."

Okay, if you are running the update client as invoker, and want to start a new process with different privileges, you must run this program with Shell.Execute() rather than File.Run(). While the update client runs under the user account, the user elevation prompt will be shown when the moment comes to run the program which needs to perform the changes to the user's computer.

(1) If I change the security of my programs "Program Data" folder, do I need to then copy my executible around after I download it so its priveldges change or will I be able to use UpdateHelper to just run it. Your example talks about extracting a ZIP not running a program.

My example shows how to extract a Zip, because this operation (decompressing and copying files) is much more complicated than just running a program. The plugin has the actions required to simply run a program - but remember, this program needs to be completely silent, it cannot have a user interface and cannot wait for user input.

(2) Who makes sure the UpdateHelper service is running - the Setup Factory installer or the TrueUpdate program?

The service is installed together with your product, so it will be installed with Setup Factory. In your update script you would call UpdateHelper.Test() only to make sure that the service is available, before attempting to use it to schedule further actions.

(3) Is the Program Data folder the appropriate place to put these files? I thought it was preferable to the user's application data which is buried and it is easily accessible by all users of our software on the computer.

The "ProgramData" is the Application Data folder for all users (on Windows 7 and later). You should not use a hard coded folder name, but use the Session Variable %ApplicationDataFolderCommon% instead.

(4) For testing this prior to release, I assume I can manually change the security of the TrueUPdate folder without doing a thing to the installer?

Of course. I recommend that you change the access rights to the application data folder where the update client is deployed, just to make sure that the user running the TrueUpdate executable later is allowed to perform the auto-update of the client.

If you haven't already done so, reading this might help a little.

Ulrich

[Otutors16]

Cool I like this, have source of project?