2.0.4.27-2.0.4.27_canary_2019-09-03
- Fixed issues with the MSI packages not upgrading correctly, thanks @BlueBlock
- Fixed some assembly redirects and package references, thanks @BlueBlock
- Code cleanup for EPOCH times, thanks @warwickmm
1 Like
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 2.0.4.21. Manually downloaded the x64 MSI file and upgraded. Afterwards Duplicati would not start. I had to uninstall Duplicaati and reinstall 2.0.4.27 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", "1.6.2.0"
VALUE "ProductVersion", "1.6.2.0"
VALUE "Assembly Version", "1.6.2.0"
Previous history based on nuget.org downloads, get .dll with 7-Zip, and look with Resource Hacker:
1.5.0 was 1.5.0.25193
1.5.1 was 1.5.0.24305
1.6.1 was 1.5.0.19417
Updated CoCoL in UsageReporter was 1.5.0 to 1.5.1 change in v2.0.2.9-2.0.2.9_canary_2017-10-01
Updated libraries: NewtonSoft.Json, AzureBlob, AWS, SSH, SharpCompress, Meg, NGetText, MimeKit, MailKit, AlphaFS, CoCoL
2.0.2.9 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 2.0.4.28 will be out which should correct the upgrade issue.
1 Like