Battle plan for migrating to .Net8

A small update:
I have started the big task of getting all installers working with the new build system in PR #5135.

It is time consuming work, but so far I have managed to get builds for:

  • Windows x64+x86+arm64, msi & zip packages
  • Linux (generic) x64+x86+arm64, zip
  • MacOS x64+arm64, zip+dmg+pkg packages
  • Debian x64+arm64, deb

My next step is looking at the Fedora RPM packages and finally the Docker images.
I expect the Docker images to fairly easy, but the RPM build to be challenging.

The updater changes for the current 2.0.x line needs to be updated to handle the switch.
I have done some of this work in PR #5129 but it still needs the UI to also support this change. I think I will use a the notification mechanism, so clicking the “download” button will create an error message saying “please visit … for a manual upgrade”.

There is some comment in the Avalonia docs that mentions you need to install:

libice6, libsm6 and libfontconfig1

I assume Ubuntu has these installed by default.

I al all for changing the prefix. I think it was the recommended style back then, but it is no longer.
I would advise not going all-in on the change now, because it will delay the real work and cause massive merge conflicts. I would prefer having .Net8 in the master branch and then doing these cleanups in individual PRs. So for now, I recommend sticking with the m_prefix (unless you are writing new code).

Cool I was not changing much of old code. My plan for the old code change was to remove it after we rewrite it with new style API.

I did not had the time to much last couple of days, I just wrote Websocket endpoint and tested if this works, I planned to work on the FE first to make sure that it is actually connecting to WS and consuming messages.

So for now:

  • make WS works
  • change FE to use WS for notifications instead of polling
  • make sure new serverstate endpoint works
  • make sure that Duplicati still works with some backup/restore process
  • but I am not sure if I want to do it manully everytime so I will probably write some Selenium tests for that
  • if new endpoint works remove the old one

just repeat it for every API endpoint afterwards and it is done. :slight_smile:

My progress is now:

  • Docker builds are working
  • Fedora RPM builds are working
  • The .Net4 builds can now detect a “manual update required” and has a custom UI for it

Synology packages will initially not be provided as they depend on the old HTTP server in DSM which is no longer present. All newer stations should be able to run Docker and use it that way, but later it would be nice with a real .spk package.

I need to go through testing on each platform and make sure everything is working as expected. The manifest files and signing parts are also missing some smaller tweaks.

My immediate plan is then to move on with getting the manual updater fixes into a new canary build.

I will hold back the 1MiB block size update and CACHEDIR.TAG to avoid introducing anything new that could break.

If it goes as planned, that canary can be promoted to beta and will be the last .Net4 build :rocket:


with a good release note, I hope. We can probably anticipate some questions, but will get others. Potentially a How-To would avoid some repetitious queries, or at least give something to point to.

RuntimeInformation.ProcessArchitecture Property might possibly be helpful to help guide choice.

Encrypted server database will have to be dealt with while there’s still an SQLite that can do that.

Install-over-old versus uninstall-old-and-install-new needs advice, and possibly in both directions.

All the potential variations of Service, Server, TrayIcon, and CommandLine need to be explained.

I’m not sure what the custom UI works in. Web UI is rather obvious, but that’s not the only place.

I guess the old folders full of updates become obsolete in the new design. Do they get removed?

We should try to stop people from full manual deletion of base install, if they used portable-mode.

Despite all our efforts, somebody will have migration pains, but at least we should make an effort.

Are we going to start version numbers with 2.1 or something so we can tell versions apart easily?

1 Like

It took me sometime. Still quite messy but it works. FE connects via Websockets and receives serverstate info.

my propososal for endpoints are small, simple methods like that

Would that be something you would be interested to merge into net8 branch (not sure if this is master or still the kestrel-avalonia-update)?

Yes, there is a place for putting in a link that explains all the things that needs to be handled manually.

I think this is only part of the selection, but hopefully we can write a good guide on how to update.

Yes, that is a bit of an annoying issue. I will make a tool that can remove the encryption. The tool will only work on .Net4 or Mono, similar to the current Duplicati. Depending on the roll-out, we can consider if this tool should be downloaded or bundled with the initial releases.

Something like this: Different ways to make a Duplicati backup • Duplicati ?

I was thinking of the WebUI. The CLI parts are also able to display the message.

Not currently. They are just left lingering so it is possible to downgrade.
We can of course explain how to remove the update folder.
If there is a need for it, we can provide a removal tool.

I do not see special considerations for portable mode? Installing the new version instead of the current one should do the same?

Yes, that is no doubt going to happen. The Synology issue has already been brought up.
I will start a new topic keeping track of known migration issues.

Yes, I was thinking that this warrants a minor version upgrade.

I have not yet merged into master. I would like to make the final canary build before I merge. I hope I can complete this very soon.

The current head for me is #5135 but it mostly just adds things around the installer. I still need to fix the build pipeline and tests.

I would very much like the websocket fixes in, as it removes the old http server, but a separate PR would make it easier to include.

Presumably English only, like so much of Duplicati outside of some fortunate program strings.

Still being in a forum battle with the oddities of the AUR (Arch) package and its unusual setup reminds me that there are third party packages and automatic updaters that may break as we change things or require manual steps.

There’s also RuntimeIdentifier (has a mention in Issues) and OSDescription, if they’d help any.

Might work. User would have to know their system somehow, so might need to run OS queries.

That’s the challenge of high flexibility I meant. They can also use various combinations of those.
I don’t know if the migration document has to follow the same format, but it must cover all cases. Installation itself is simpler, now that there aren’t updates everywhere, but stop everything first…

I actually wasn’t sure the CLI used to check each run (update server hammer). It used to be that:

  --auto-update (Boolean): Toggle automatic updates
    Set this option if you prefer to have the commandline version
    automatically update
    * default value: false

I agree it’d be good to allow that. I don’t know if the DB version bump is still in the plans though.
Preventing accidental runs of old code has merit, but needs an escape path, if run is intentional.

“full manual deletion” meant remove the install folder, which is where portable mode database is.

Its cool to me.
I would just hate to see my work done around this going to waste because of something.
I can continue work on this to make it cleaner, and test it a bit more.

As for merge process, I do not care if this will be master or not, now or in 2 months. Just do not want to waste time on this; I have other projects I am working on currently.

Knock on wood, based on what I have read they would likely see it update to the last .net4 version and then think there are no updates. Which is probably reasonable. I would consider .net core migration to be a major version change in duplicati. So requiring a manual intervention in my opinion could be expected.

PS: Excited seeing all the work going into this, and thinking through all the nuance.

I see, that would be terrible :confused:

If it goes into the kestrel branch I foresee no major headaches with merging :crossed_fingers:

Yes, in any case, since the base framework is now .Net, any dependencies would need to change for packagers. My current builds are using self-contained so there are actually no additional dependencies for the binary packages, except for the GUI parts on Linux.

1 Like

ok cool! I will cleanup the code a bit, test it and rebase my branch on top of origin.