I happen to have a peculiar situation where Microsoft’s .NET release for Mac would be highly preferable compared to installing Mono on a Mac. How hard would it be to convert the client to utilize the MS release instead? (Assuming there’s nothing Mono has that is not supported in the MS .NET)
If Mono turns out to be the path of least resistance, I saw murmurings online that Mono and .NET will be largely merged with each other with the release of .NET 6. Will Duplicati be updated to utilize .NET 6 on Macs in that event?
(I could be totally off here, bit of a .NET newbie, so thanks for the help!)
No guarantees that it does anything but eat your firstborn but Scroll
all the way down on Duplicati Github Actions Artifacts Build and try the osx build. I don’t have a personal mac to test this on. I would only expect the server and command line executables to work.
I would claim that it will continue as a .net 5 port until something only exists on .net 6 and would be useful or the port is complete at which point going to 6 should be trivial (Barring some political issue about the self contained builds we are sporting now).
Thanks for the input. I heard Microsoft wasn’t able to get everything they originally wanted into .NET 5 by ship date. I don’t know if anything we care about got delayed. One reason to favor low requirements is to support more systems. On that note, I’ve wondered (but haven’t asked until now) why we target .NET 5 instead of .NET Standard 2. Must be something, but might add some source and deployment downside.
Regarding artifacts, my struggles to run one ended here. Are you able to run those, or have further steps?
Maybe this is apples and oranges. I was trying a .NET Framework artifact, because “nightly” doesn’t exist.
Thanks for the input everyone! This gave me plenty of reading materials for my needs. Looking forward to seeing the branch develop, and I’ll play with the artifact.
I originally started going down the rabbit hole of porting as much as possible to .netstandard before finding the fork that was further along but going to .net5. Going to .netstandard for some libraries (Notably the backends) would reduce the effort of merging develop repeatedly into the .net5 branch (the csproj files have to be hand resolved whenever anyone updates a dependency).
Note executables cannot be .netstandard and there are some libraries that cannot as well because of features they use. Technically you could target both runtimes for some of those libraries but there are code changes so you end up in a bit of conditional code hell.
So the mentality I’ve been using at the moment is to run headfirst into getting the .net5 branch mergeable. The trayicon on linux and autoupdater so far is the biggest problem I am seeing. The autoupdater there seems to be consensus that we can just ditch for the moment, while there is probably a desire to make it work the world doesn’t stop if its gone. The trayicon may be a harder sell. It would not surprise me if it is desirable to call the…net5 port Duplicati 3.0 to follow semantic versioning.
I can try and merge the mainline again after I get this stupid debian bug I’ve been chasing worked out.
I’ve merged the latest master into my branch. I switched to Avalonia UI for all platforms, but my testing last night on a rented m1 mac mini revealed an issue loading the tray icon though the webpage appeared briefly before the trayicon issue crashed the app.
I’m only planning on renting the mac for 24 hours so I’ll see if I can fix it today and maybe make a .dmg to make installing easier