I understand that CreateProcess a better way to go is than ShellExecute. What to do if the owner of the computer have changed the windows explorer into an other shell application?
It is easy to go upwards from un-eleveated to elevated. But backward is a real challenge.
The solutions i found on the internet are very complex but nevertheless unreliable.
For now I think it is the best way to pretent that the owner of the computer have not changed the shell, so I can call ShellExecute to launch the application un-elevated with help of the explorer. If ShellExectute ends with an error, prompt the user that he to have manual start the application, and quit the updater. I think that a silent update do not have this problems because this kind of updates are usually done under full administrator credentials.
Well done, but did you know that it is possible for a running application to rename itself ?
I used this (dirty) trick with my .NET application, on update it renames itself to e.g. software.bak and can then download the new software.exe.
Do you have a solution (like running the new temp instance with admin rights using a user created for the software that can have admin privileges on c:\program files\mysoftwaredir) in case (mosto often) when the users have no write rights on dirs and in OS like W10 where you need always elevation even if part of admin Group ?
We tested this solution with a product we are developing which runs under Administration privileges. The rule is that an elevated process can create other elevated processes, so during the automatic update, since the program that initiate the update has a UAC of Administrator, it downloads and runs the new version elevated as well.
This single application solution do not work for users that run at user level with UAC.
To update, the application have to ask the user for elevation or an administrator account with password. The update process is fit in a second application (updater) with an elevatated manifest, called by the main application as an elevated "runas" child process with parameters. The updater do the update of the application and then the updater starts the application at the user level (using ShellExecuteEx with "explorer.exe" as lpFile and the application filename as lpParam) so that the application can access the profile of that user. To make it more professional, the updater must also be able to do a self update. The flow is now more complex which I do not specify here.
"Single application solution" you mean a single file? One executable? Well, that's not correct. We have many products which are defined as such that they require Administration rights.
I just tested it and it 100% works. Here is what you have to do:
1. Download the source code of this article
2. Make sure the version string is 1.0.0.1
3. Go to the project's settings and set Linker -> Manifest File -> UAC Execution Level to: "requireAdministrator". (see: 2017-09-19.png (59.8 KB))
4. Build SG_AutoUpdate.exe
5. Run it. When you double click it, you will have to confirm the UAC prompt. Then everything will work as before, exepct for the fact that the new version downloaded and silently started will also require Administrator privileges however in this case, no elevation prompt will appear! and yet, you will find that the version that is running is 1.0.0.2.
Here you can see the new version running even though there was no elevation prompt displayed after the update. 2017-09-19__1_.png (206.8 KB) 2017-09-19__2_.png (76.7 KB)