Release: 2.0.4.26 (canary) 2019-09-02

Releases
21

CoCol is built on 4.5 which shouldn’t be a problem. We can still use 4.5 components.

I think the issue may be a known problem in Wix based upon what I’m reading. I’m looking for a solution.

22

Are you reading the issue I posted? Possibly it’s discussed elsewhere, but above the tl;dr is long version:

I’ve encountered this issue and found the cause.
The problem was that in the newer installer, the version of CoCol.dll was lower than the one in the already installed version of duplicati and there is a bug in WiX - when trying to install a lower version dll, the old one will get removed but because the dll in the new installer is older it won’t be installed.
Repairing fixed the problem and that makes sense because the installer no longer thinks that the dll is being downgraded.

Isn’t going from 1.5.0.24305 to 1.5.0.19417 (see images) considered a downgrade attempt of the library?

Note that the above note is from 2017, but it seemed like it’s possibly still around, so I thought I’d mention.

1 Like
23

I installed .26 over .25 and at first Duplicati didn’t start. But reparing (using the .26 MSI file) worked. Now Duplicati starts as usual.

Thanks for posting.

24

Wix (via MSI) provides for the custom ordering of installations/upgrades. The current Wix config first uninstalls everything and then reinstalls all files. This isn’t the most efficient method. Though I think it should work, unless this is some bug we’re hitting in Wix, but this is moot since there is a better method.

An alternative is to install the upgrade and uninstall the old version, which causes only changed files to be copied… a much faster upgrade. I tested this method and the upgrade installation works correctly.

https://docs.microsoft.com/en-us/windows/win32/msi/removeexistingproducts-action

I’ll put a PR in to fix this.

25

So I upgraded to .26 with logging and it failed again. So I then ran a repair with logging and it’s now working.

Repair Log

Installer Log

26

Wix installer fix PR is in. A new Canary is needed.

https://github.com/duplicati/duplicati/pull/3886

2 Likes
27

Something I’ll look at now since it seems like is shouldn’t be going to a previous version.

28

Thanks for pointing this out. I rechecked the nuget packages and 2 configs still referenced 4.5

@kenkendk We are using the latest nuget CoCol v1.6.1 and it shows version the dll as 1.5.0.19417 but the .26 MSI contains a newer version of 1.5.0.24305 built on 6/30/2019. Is there a newer CoCol that is not yet up on nuget?

29

I updated from 2.0.4.22 to 2.0.4.26. Now i get an error by trying to backup to Microsoft Onedrive v2:

System.IO.FileNotFoundException: Die Datei oder Assembly “System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a” oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.

Dateiname: “System.Net.Http, Version=4.2.0.0, Culture=neutral, PublicKeyToken=*********” —> System.IO.FileNotFoundException: Die Datei oder Assembly “System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=************” oder eine Abhängigkeit davon wurde nicht gefunden. Das System kann die angegebene Datei nicht finden.

Dateiname: “System.Net.Http, Version=4.0.0.0, Culture=neutral, PublicKeyToken=***********”

Any idea?

30

It’s an HTTP reference issue that will get corrected in next canary.

31

Sounds like there is a problem with assigning version numbers in CoCoL, probably this line:

Everything else is neatly set to 1.6.1, namely this which I think MSI should be reading:

I can make a 1.6.2 build with a fixed version number if that helps.

32

When I build Duplicati locally I get the older version number and the canary has a newer version. The file sizes are also different. I’m not sure that is the cause. Might your build be pulling CoCol from your local build?

33

That would explain it. But the build does a clean+restore prior to building. It also does a git stash to ensure the build is from a clean checkout. It should not be possible.

34

Compare the CoCol.dll (112 KB) in the .26 canary to the CoCol.dll found on nuget CoCol 1.6.1 (111 KB).

35

Duplicati v2.0.4.22 was using CoCoL v1.5.1 and later have upgraded to CoCoL v1.6.1. But the internal version number was stuck on v1.5.0.* and * is autogenerated during builds, causing the issue.

I think what you are seeing is caused by the fix to use .Net 4.6.2, where it now selects the .Netstandard 2.0 version instead of the .net45 version.

The md5 hashes are as follows:

c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.3/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.4/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.6/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.7/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.8/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.9/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.10/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.11/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.12/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.13/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.14/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.15/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.16/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.17/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.18/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.19/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.20/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /canary_source-2.0.4.22/CoCoL.dll
6479b65d69e9fec163c9358f0a35d11f  /canary_source-2.0.4.24/CoCoL.dll
6479b65d69e9fec163c9358f0a35d11f  /canary_source-2.0.4.25/CoCoL.dll
6479b65d69e9fec163c9358f0a35d11f  /canary_source-2.0.4.26/CoCoL.dll

The library md5 hashes are:

bade2b1a518564f9023b7e60aecd383f  /CoCoL.1.5.0/lib/net45/CoCoL.dll
827007b1d5d7657597bb8a7e6971227a  /CoCoL.1.5.0/lib/portable-net45+netcore45+wp8/CoCoL.dll
c746afbf3e5cb3dbb535ccf86c5a8dee  /CoCoL.1.5.1/lib/net45/CoCoL.dll
bf2617dae5e3f4cdce01a508365267f4  /CoCoL.1.5.1/lib/portable-net45+netcore45+wp8/CoCoL.dll
01b0079ab35ab4ff1e9c9dd4079f4549  /CoCoL.1.6.0/lib/net45/CoCoL.dll
a06495025438e3d6eff93f5fa02007f2  /CoCoL.1.6.0/lib/netcoreapp2.0/CoCoL.dll
157c40a6d63b2c6e3dddecfbb7c81ca5  /CoCoL.1.6.0/lib/portable-net45+netcore45+wp8/CoCoL.dll
6479b65d69e9fec163c9358f0a35d11f  /CoCoL.1.6.1/lib/net45/CoCoL.dll
f492eb1c3789f26f5d1bd25ba1c5669b  /CoCoL.1.6.1/lib/netcoreapp2.0/CoCoL.dll
37acbf7546a71ff8c9a362cd51e082b3  /CoCoL.1.6.1/lib/netstandard1.6/CoCoL.dll
fe3044845f9b2950c7fb86cf09662d30  /CoCoL.1.6.1/lib/netstandard2.0/CoCoL.dll
94d6ad06d1a9f45bf34b2d302f3d07d0  /CoCoL.1.6.1/lib/portable-net45+netcore45+wp8/CoCoL.dll
36

Ok… that makes sense. Thanks.

The CoCol version looks correct then.

37

FWIW this is what 2.0.4.26 and 2.0.4.27 have in the .msi, seen by examining the files in .msi using 7-Zip.

This matches the 2.0.4.26 zip posted earlier. Build time per their PE File header is 4/13/2018 4:47:15 AM.

So I guess I’m not confirming “the .26 MSI contains a newer version of 1.5.0.24305 built on 6/30/2019” or “Netstandard 2.0” theory. I don’t completely follow everything that’s been said, but I thought I’d note that…