IMO specific failure behavior when dependencies are below spec (and spec is mono v5) is interesting to learn the symptoms (and this gave the same as After update to 2.0.4.27 duplicati crashes on synology), however a better plan is to prevent problems by ensuring dependencies are met (to the extent possible).
Every OS that Duplicati builds for probably has some way of declaring dependencies, but I don’t think the packaging and installation code has been touched. Bumped required Mono version to 3.0 for Debian build (citing a different OS build) was three years ago, however the required mono version is still 3.0 in master.
The Synology methods for declaring dependencies is in https://global.download.synology.com/download/Document/DeveloperGuide/DSM_Developer_Guide.pdf. Field Name: install_dep_packages takes version information in the INFO file but Duplicati’s doesn’t give any. There’s also PKG_DEPS also not used.
Covering dependencies for initial install doesn’t solve the autoupdate-into-fail scenario, but mono version reading at runtime appears possible. Methods range from running mono --version (but what if there are multiple mono installations – there do seem to be solutions), but one method that I tested is reflection, i.e.
GetType("Mono.Runtime" then GetMethod("GetDisplayName" as in example code in the article below:
How to find what versions of C# and .NET/Mono are being used?
Ignoring the people who had to update mono to get beyond TLS 1.0, reports so far appear to be Synology users who apparently have a large variety of mono builds due to a variety of things like CPU architectures which makes me wonder if Duplicati’s packages will look like this when it moves to bunde the framework.
One challenge with packaging is that not many people know that. One challenge with testing is access to needed equipment, but possibly @Wim_Jansen would be willing to assist, if Synology testing is needed.