Hmm. I need to investigate, but I cannot look at it for the next 4 hours.
1 Like
Does below offer a clue? I’m not familiar with building the code, so this was just via source search.
I think you are on to something there. I’m not sure how that file gets updated… manually?
Looks that way. Click on the GitHub History link to see.
Then that might be important to keep in sync. I’m thinking a pre-build check on maybe the GUI project should check the file and through an error when it is out of sync. Otherwise it will eventually be forgotten.
I’m not sure how long the new chunk of code is relevant, but I’m no expert in .NET Framework builds, especially for the transition to v4 which is about a decade old already. What do you make of this info?
What does ‘useLegacyV2RuntimeActivationPolicy’ do in the .NET 4 config?
and this whole thing may or may not be relevant, but it was pretty much all I found in a source search.
2.0.4.25 Newtonsoft complaint is different, but it’s still referencing a .DLL whose exact version isn’t there.
Unhandled Exception: System.AggregateException: One or more errors occurred. —> System.IO.FileLoadException: Could not load file or assembly ‘Newtonsoft.Json, Version=10.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) —> System.IO.FileLoadException: Could not load file or assembly ‘Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference.
Why do you suppose the .csproj is this way?
and the seeming reference to Version=12.0.0.0 is visible in dnSpy, e.g. Duplicati.Library. Main shows:
EDIT:
Actually, I’m not sure it’s different, but the .csproj question remains.
I’m not so sure the 12.0.0.0 is an issue. The main issue looks to be the builds are .net 4.5.
How to use Assembly Version and Assembly File Version supports idea that 12.0.2.23222 is irrelevant:
Assembly File Version : This is the version number given to file as in file system. It is displayed by Windows Explorer. Its never used by .NET framework or runtime for referencing.
dnSpy of Newtonsoft.Json.dll confirms that’s its AssemblyFileVersion. Its AssemblyVersion is 12.0.0.0.
Should these canary’s be pulled since they are not usable?
I think pulling them would limit the damage, but sometimes damage happens fast. I wonder if this runs:
EDIT: Duplicati’s version was 6 hours ago, so I guess some repackagers pick these up in an hour or so.
Yes, that one is updated manually. It replaces the .config file for all .exe files when doing the build:
Yes, I think NewtonSoft.Json only updates the major version (in .Net versions).
The problem is that multiple dependencies use NewtonSoft.Json, but we only bundle one version. There is nothing in the Duplicati code that directly references anything but 12.0.2. Some dependency is probably not updated and still references something from 10.x.
It is not a problem as such, since the library is backwards compatible. The problem here is that there is an installer command that wipes the config files when building a release.
The reason for that wiping was originally to ensure that custom backend modules could be loaded, without requiring that they were re-compiled for the specific version.
Not sure if we want to keep that. It can also be fixed in the version stamp tool, that it can parse and rewrite the .config files, instead of fully overwriting them.
Does this from earlier in AssemblyRedirects.xml have relevance to that 10.x reference?
Not sure how much gain that would give. Once a new build is out, auto-update users should hit that one. New/manual users will most likely choose the newest also?
I have uploaded a new version, and the .config files now reference NewtonSoft.Json v12.0.0.0.
Does this manual assembly file need to be a rollup of all the dependencies for the .exe’s?
No. It does not need to be, but usually the dependencies are from somewhere down the stack of modules, and since each .exe could in principle load that module, they usually need to look the same.