Running the Server from the ZIP looks good.
Doesn’t look like this solved the in-place upgrade issue. I attempted an in-place upgrade on one of my machines that was running 126.96.36.199. Manually downloaded the x64 MSI file and upgraded. Afterwards Duplicati would not start. I had to uninstall Duplicaati and reinstall 188.8.131.52 before it would start again.
Not good for me either. Tried upgrade from .26 (the one machine I did a repair after the upgrade) to .27 and it worked which looked hopeful, however another machine from .22 to .27 failed, and I couldn’t even fix it with a repair like before with .25/.26. Have gone back to .22 (downgrade/repair) on this one so I can test another release.
Thanks. I’ll look into it.
Was Duplicati running when you were upgrading? Did it ask about shutting down Duplicati?
I always stop the service, and when on a machine with a GUI stop the tray icon. Then check in task manager for any left over processes.
There’s a CoCoL 1.6.2 on nuget.org with Release Notes, “Added new features and simplified API.”
What might be more relevant is that version numbers went up (lots to choose from - all the same):
VALUE "FileVersion", "184.108.40.206" VALUE "ProductVersion", "220.127.116.11" VALUE "Assembly Version", "18.104.22.168"
Previous history based on nuget.org downloads, get .dll with 7-Zip, and look with Resource Hacker:
1.5.0 was 22.214.171.12493
1.5.1 was 126.96.36.19905
1.6.1 was 188.8.131.5217
Updated libraries: NewtonSoft.Json, AzureBlob, AWS, SSH, SharpCompress, Meg, NGetText, MimeKit, MailKit, AlphaFS, CoCoL
184.108.40.206 crashes with System.IO.FileNotFoundException, missing file or assembly “CoCoL” #2788
was the result, analysis, and two workarounds, one by repair, and one by hack with Resource Hacker, which potentially someone could play with again to see if it helps current is-upgrade-a-downgrade bug.
Version Information is (presumably very old and established Win32 info). Though .NET adds versions beyond what conventional .dlls have, I suspect install strategy looks only at the traditional versions, so Resource Hacker information is probably more relevant than the info from a .NET tool such as dnSpy.
I don’t know what’s up with CoCoL 1.6.2 in terms of what its Release Note says. All GitHub has is the:
Fixed the assembly version on .Net 4.5 and PCL assemblies.
Nope, it wasn’t running. I closed the TrayIcon process before running the installer.
The installer is not replacing some dll’s because the framework upgrade wants to use different dll’s but the version numbers are the same and the wix installer doesn’t replace those files. @ts678 mentioned this as a previous issue.
It seems the most reliable is to use the previous method of uninstalling first then installing the new version. The CoCol has been updated and this resolves the issue of it not copying.
So shouldn’t a repair after installing/upgrading to .27 also force it to replace the files? In my case from .22 to .27 a repair afterwards had no effect unlike the previous two releases.
There were some changes, but mainly new methods and overloads. Nothing that affects Duplicati.
The primary reason for the release was to make the version number follow the NuGet package version number.
I would expect it to but I’ve also seen the repair not work as expected. Hopefully a 220.127.116.11 will be out which should correct the upgrade issue.