Describe the bug
It seems that Anamnesis' update procedure uses the downloaded updater to carry out the application version update. Generally speaking, this is a good approach as it allows us to update the application despite potential breaking issues in the update service. However, this also comes with the drawback that if at any point in time the updater changes its .NET version dependency, the executable will fail to run on most users' systems as they likely won't have the necessary .NET desktop runtime installed.
Expected behaviour
At the time of writing, I can think of two possible solutions that are complementary and can both be implemented:
- The update procedure should download and install missing dependencies before attempting to run the (downloaded) updater executable.
- The update procedure should fallback to the old updater if execution of the new updater fails.
Update: It is also possible to make the updater binary self-contained. Normally, the file size of the resulting executable would become significantly larger, but this can be avoided by changing the build to AOT.
Describe the bug
It seems that Anamnesis' update procedure uses the downloaded updater to carry out the application version update. Generally speaking, this is a good approach as it allows us to update the application despite potential breaking issues in the update service. However, this also comes with the drawback that if at any point in time the updater changes its .NET version dependency, the executable will fail to run on most users' systems as they likely won't have the necessary .NET desktop runtime installed.
Expected behaviour
At the time of writing, I can think of two possible solutions that are complementary and can both be implemented:
Update: It is also possible to make the updater binary self-contained. Normally, the file size of the resulting executable would become significantly larger, but this can be avoided by changing the build to AOT.