>>Another, easier way, was to have the version number in the filename, and just place the new exe in the same folder, then edit the task in the scheduler to run the new exe instead. That way the old exe would continue until it would regularly exit, and the next run would use the new exe. The trouble with this approach is that I need to know the password of the account under which it runs, which I didn't, for several clients.
>
>Most likely I won't know the password either. And I can easily choose the time for the update when the program will not be running, since it will only run one time per week for about 2-3 minutes. What I read in your message is that Windows does not actually move the application file (EXE) to another folder. Therefore, once this project goes into effect, I will simply replace the EXE one time and see what happens.

The "moves to another folder" is an illusion you get if you don't specify the "start in" folder (without quotation marks even if it contains spaces, without the final backslash - both are considered errors by the morons who wrote the dialog/scheduler, and there's no error message; learned this the hard way). In such cases it uses some default folder related to the account under which it runs as its set("default"), so it may not find its .ini or .xml files at all, not knowing where they may be. So be careful to specify the location, and to run it a few times manually from the scheduler, i.e. not just by doubleclicking it in the explorer (then it runs where it is, under your credentials - your temp folders, your appdata folder etc etc), but by clicking Run in the scheduler (then it runs under the given accoun't credentials etc). Then you can see whether it runs OK or not. The run button may not be enabled for the task, there's a checkbox in the task properties dialog, IIRC page 1, the caption may not be clear but it's something "allow the task to be run ...".