I likely don’t know all the reasons, but I think a goal was to avoid needing administrative permissions such as the Linux root password or the password for a Windows account in the Administrators group.
What has actually happened is that autoupdate has had some troubles. Windows service requires a restart of service (or Windows) to activate, and I’m seeing some sign (like you) of a broader problem.
Release: 2.0.3.13 (canary) 2018-10-31
Added code to allow the Windows Service to correctly autoupdate
2.0.3.14-2.0.3.14_canary_2018-11-08
Removed the WindowsService restart fix as it did not work as expected
Activate downloaded upgrade sometimes fail was technical discussion, and issue seems worse now because TrayIcon previously seemed OK, and now it seems to have the same problem as Service…
What I haven’t been able to get is a “won’t run” after getting fresh .msi install, then update to 2.0.5.1.
Tried 2.0.4.23 Beta (previous latest Beta), 2.0.4.26 Canary (from September “assembly” fixing days), and 2.0.4.30 Canary. I can get “Activate” button to not bring Duplicati back up, but manual works fine. Rebooting also works. None of this was a Windows service, just the default .msi install and TrayIcon.
If you found 2.0.4.5 in the updates folder, possibly your Program Files was 2.0.3.3, the Beta before it. That’s one I haven’t tried yet.
If the folder is still there, you can compare it to the Program Files view of 2.0.5.1 for that file, but I think these all start from the same bunch of files, before diverging into .msi, .zip, and format for autoupdater.
I’m neither a build expert nor an assembly expert.