Early preview of .NET8 builds, codename `2.0.8.108`

Releases
1

As announced in the latest canary/experimental/beta, the plan is to move to .NET8 builds going forward.
For those that want to help out or try the very latest, I have prepared a set of builds that use the .NET8 build & package process.

I hope (again) that this will be the last debug build and that we will be able to release canary builds going forward.

This build has a these fixes reported on the previous build:

  • Suppressing Avalonia log messages
  • Fixed error on Windows decrypting database
  • Fixed issues with Docker images

The packages are signed (Windows + MacOS) and the GPG signatures are included.

Upgrade notice

Since RC4 encryption is no longer part of the open-source SQLite libraries, the builds will detect and remove the RC4 encryption before connecting to the database. If your security setup previously depended on this feature, make sure to adjust.

The file naming structure:

The filenames are named after operating system, chip architecture and intended use, e.g. linux-x64-gui.
The -gui builds also include the -cli executable, but are generally bigger due to the UI libraries.

The suffix denotes the installer type:

  • .zip: Generally just the files, zipped.
  • .deb: Debian package
  • .rpm: RPM package
  • .pkg, .dmg: MacOS packages
  • .msi: Windows Installer

Docker images:

Docker images are pushed with the tags 2.0.8.108 and Debug.

List of images

2

Looking good on Windows 10 so far. An install over a running 2.0.8.107 Windows service fared better than previous no-exe-files result. Did something change, or maybe it depends on what was installed previously?

The small issue of About → System info → UserName being wrong remains. Another possible bug is this:

ServerVersion : 2.0.8.108
ServerVersionName : - 2.0.8.108

whereas ServerVersionName used to be longer, e.g.:

ServerVersion : 2.0.8.1
ServerVersionName : - 2.0.8.1_beta_2024-05-07

Possibly this why the Duplicati portal report looks kind of redundant in displaying the new debug Version:

image

3

duplicati-2.0.8.108_debug_2024-05-08-win-x64-gui.msi installed over 2.0.7.1 beta (my test setup is now behind the times by a version).

It appears to have worked perfectly. I did not encounter any issues this time, the database decrypted without any manual intervention required.

A side question: The installer used to offer several configurable options, such as whether or not to add a Desktop Icon, Start Menu entry, or “Launch Duplicati at startup”. The installers for these debug versions don’t offer those choices at all.

Are those things gone for good, or is this just an artifact of the way the debug installers are built?

I ask because in nearly all of the places I have installed Duplicati I have set it up to run as a service and prefer to keep all the user-facing parts hidden.

4

I usually turn off the “Launch Duplicati at startup” (actually when you log on) and omit start after install.

Even if there’s a reason for a simplification, don’t we want to at least get a person to accept a license?

second syntax was able to get some of the things I don’t want turned off. I don’t think I ever saw the current debug installers do the start after install, but they did do some other things such as add a start link to folder
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp which starts Duplicati on logon.

5

I guess I’ll also mention that what I would describe as command line foreground/background has changed, although I’m not sure if it’s better or worse than it was. One thing improved due to the single process is that Control-C in Windows won’t kill the parent but leave its child (which does main work) up in the background. Downside of that is that it’s now easier to kill Duplicati early by terminal/tab close, or Duplicati stops closes.

6

I tested after editing the Windows service to use a user that is not SYSTEM, and it worked.
I tested bringing up TrayIcon as SYSTEM (using psexec to get there), but it won’t come up:

C:\Duplicati\duplicati-2.0.8.108_debug_2024-05-08-win-x64-gui>Duplicati.GUI.TrayIcon.exe

C:\Duplicati\duplicati-2.0.8.108_debug_2024-05-08-win-x64-gui>Unexpected error: System.PlatformNotSupportedException: Operation is not supported on this platform.
   at Avalonia.Threading.Dispatcher.MainLoop(CancellationToken cancellationToken)
   at Avalonia.Controls.ApplicationLifetimes.ClassicDesktopStyleApplicationLifetime.Start(String[] args)
   at Duplicati.GUI.TrayIcon.AvaloniaRunner.Run(String[] args, Action postInit)
   at Duplicati.GUI.TrayIcon.TrayIconBase.Init(String[] args)
   at Duplicati.GUI.TrayIcon.AvaloniaRunner.Init(String[] args)
   at Duplicati.GUI.TrayIcon.Program.StartTray(String[] _args, Dictionary`2 options, HostedInstanceKeeper hosted, String password, Boolean saltedpassword)

In contrast. 2.0.8.1 Beta TrayIcon will come up. I bypassed this problem a bit by running Server instead.
UserName : HP4$ is what About → System info said, so problem seems to be in saying SYSTEM, like.

image

I hope the release note improves to offer migration guidance, and show changes since previous Canary.
Duplicati.Library.AutoUpdater.exe is gone, and Duplicati.CommandLine.AutoUpdater.exe runs differently.
I’m not sure about the installer plan, but I see the UI disappeared in the Multi arch build pull request.
Giving an overview of the autoupdater work would be good for those (most?) who weren’t watching it all.

Consider an attempt at explaining all to Canary users a warmup to having to explain to Beta community.
Ideally some of this stuff should be in the manual too, although developers don’t always help doing that.

People might be asking questions such as what they should stop or uninstall first. Not all is tested well.
Install with Windows service up said it needs reboot later, but Sysinternals PendMoves didn’t confirm it. Things seemed to work, but I rebooted anyway, which is when I found my unwanted Duplicati TrayIcon.

Another Windows service scenario I worry about (and might test) is when somebody has autoupdates. Service installed at that point points to old autoupdate area which probably won’t find the .NET 8 install.

Lack of tests on a wide range of OS and storage destinations is worrisome. Should we maintain a list?
Canary users were sort of warned of a rough ride, even though they’re often luckier. How much to test?

7

I see, I was writing the wrong version into the version field.

The previous builds were based on WiX which is Windows-only. To support this, I was using a local virtual machine with Windows and WiX. The build then copied files into the VM and built the MSI. This was not portable, because the Windows license is not free, so anyone wanting to replicate this would need to replicate my VM setup with their own Windows license.

For the new build system I have used msitools / wixl which is an open-source MSI build system. While it works, it is quite under-maintained and lacks a lot of the features that were used in the previous MSI packages.

For the immediate future, I plan on sticking with msitools, but if anyone has a better option I will look at it. Improving MSI tools looks like a way forward, but it is quite dated code-wise and very tied to the Gnome libraries.

An alternative is to run a “proprietary” build system that cannot be reproduced by the open source community. I have seen others that advocate hosting a signing service, so the build can be done as part of the CI and then signed outside the CI, but I think this is error prone and dangerous.

The previous behavior was an unintended side-effect from the auto-updater, so I consider it acceptable that it now works as a normal process.

Not sure why it worked before, but generally, the SYSTEM user does not have a desktop, so there is no tray to install the icon in. I would think you can right click and “Run as Administrator” and that will run under the UAC so it is still tied to your desktop session, but has additional permissions.

That part has not been changed, but it is using System.Environment.UserName. The behavior may have changed, or maybe this is another artefact from changing the autoupdater.

I can try a small change to use System.Security.Principal.WindowsIdentity.GetCurrent().Name on Windows.

Yes, these seems like good points to include in the changelog.

Yes, that is the reason for canary builds, so users can opt-in to helping iron out rough areas.

I would say stopping the application before update/uninstall is generally the safe approach. The second part is that the MSI changes that auto-selects the tray icon?

I can understand why someone would do that, which is another reason to not install updates this way.
If someone has done that, it would still break later, because the updater would create subfolders that would break the validation check.

I think that list would be hard to maintain.

The .NET codebase is roughly working the same, so most destinations will work the as before, same goes for the core algorithm. Major pain points are around the removal of the autoupdater, the change in build system, and the new installer packages.

8

I’m doing this from a login session, from a Command Prompt that looks like:

image

where I can launch the below app too, and have it display to the system tray.

image

so basically I’m pushing back on the remark about not having a desktop here.
Regardless, I don’t know if anyone would normally do this except for a test…

Generally an elevated administrator gains access to most files one may want.
Both Administrators group and SYSTEM user tend to have widespread ACLs.

If you mean the tool change to a more limited one (really no UI available?), yes,
assuming you were referring to the unwanted TrayIcon part of the second part.

The current installer doesn’t seem very flexible in terms of what’s on or off, but
I did cite above an awkward way to force it, using an arcane syntax of msiexec.

It’s not even an intentional sequence. Just install windows service after updates.
Canary user who autoupdate probably have a string of updates hanging around.

There are definitely some pitfalls in the old way, and surely some in the new too.
At least getting closer to normal behaviors might be less surprising to the users.

Each build level gets ironing, and gives ideas for what to document for next level.

Eventually it may become too much, but it’s just a couple of people, for this build.
Perhaps we could encourage quiet testers to talk a bit about what they’ve tested.
Alternatively, there’s Duplicati Inc. and whatever gear and destinations they have.

Weren’t there changes for Thread.Abort vanishing, and maybe “Make all backends async” (open issue)?

Current topic posts look a little Windows-heavy. I wonder if anybody is testing other platforms? We could examine previous debug build topics to see, or maybe users will give reports on what’s working well now.

You also have usage reporter data that might show implied success by seeing continued backup usages.
There is a link usage count in the List of images above. It looks Windows-heavy, but that’s how we are.

9

I have had one random crash at startup with the PlatformNotSupportedException on MacOS, but I cannot reproduce. It looks like it happens if some events are triggering a redrawing of the tray-icon before it has fully loaded. If that is the case, maybe fixing it will also make it work for Windows.

It looks like there is actually a bit of UI supported, it is just not documented anywhere that I can see:

True. That has been removed, but the way it is used by Duplicati, the removal is not problematic.

It was problematic that it was used at all, because it could cause exceptions in places it should not, and (potentially) corrupt the state. It also was not working like it should because the thread being interrupted might not be the thread performing the stuck tasks (i.e., another thread may do the actual stuck upload).

The removal should not have any effect, except that it will no longer throw inside unexpecting code.
There is still a hand-rolled version of a cancellation token in there, that will stop whenever the process returns to C# code. Either running the backends in isolated processes, or implementation a real cancellation token should be done asap.

The Thread.Abort() calls are only activated when force-stopping a backup, and that has had a < 100% chance of working.

True, a snapshot says we have around 75% Windows clients.

10

About → Changelog has gaps. As this is the “project changelog”, e.g. as said here, will it stay gappy?
Actually the above 2.0.8.1 has gaps and issues too – 2.0.8.0 vanished, and 2.0.8.1 said experimental.

2024-05-08 - 2.0.8.108_debug_2024-05-08
==========
Latest debug build for .Net8, these are fixed in this version:

- Suppressing Avalonia log messages
- Fixed error on Windows decrypting database
- Fixed issues with Docker images

2024-04-19 - 2.0.7.103_canary_2024-04-19

(technically off topic here, but here’s the Beta)

2024-05-07 - 2.0.8.1_beta_2024-05-07
==========
After almost a year, a new experimental build is ready!

Since we are switching the underlying framework to .Net8, this release will be the last that runs on .NET 4 / Mono.
The new releases will be built with the framework included for minimal dependencies.

Thanks to all the amazing contributors and community for supporting the project!

For this release the following major changes are included:
- Updates to various third-party libraries: mail, Ssh.Net, RestSharp, FluentFTP, Sharp.Xmpp, Uplink
- Improved error handling with interrupted backups and damaged local database
- Removed defunct links and backends
- Changed to MIT license and removed donation messages
- Even more options!


As always, a detailed change list is in the project changelog.

2024-04-19 - 2.0.7.103_canary_2024-04-19
11

Yeah, that was a slip-up on my side.

No, I will try one more debug build which may have gaps, but then I will switch to canary builds, which auto-commits the last message so we do not have lost messages.

12

I took a deep dive with wixl and managed to patch it enough to get the previous options back into the installer.

With my newly gained knowledge of the internals of MSI and WiX I can take on the task of creating the long-requested “Install as service” option. But before I do that, I would like to beef up the security a bit, because I do not like a service running with Administrator privileges being accessible via HTTP.

1 Like