search

KnossosNET / Knossos.NET

Repository for the Knossos.NET launcher, currently in development.
GNU General Public License v3.0
23 stars 10 forks source link

Fix update system once again #114

Closed Shivansps closed 8 months ago

Shivansps commented 8 months ago

The root of the problem seems to be that once we move/rename the running application executable to ".old", this is weird as ive been using this process to update me work apps for years whiout issue. This problem seems to be caused by using independient builds (builds that dont need .net to be installed on the user system to run)

It looks like that classes that has not been used before moving the executable may fail to work, and this seems to change depending on the OS. For example, in Windows my update system was working fine, yet on linux i could not chmod or start the new instance of the application because starting a process now created a "System.IO.Pipes not found" exception, something that i was able to work around by calling chmod two times, one before moving the executable and one after.

This is a kinda large rework: -I fixed all problems with the old system (at least for Windows and Linux), there were several. Cleanup starting too early and trigerring a file in use, a call from invalid thread when displaying an error message, properly catch and handle sharpcompress exception during "auto mode" decompression.

-I changed the moving the files of the currently running application to the last possible moment

-Downloaded Knet files are now extracted to a "kn_upload" folder were the app executable is, before moving them.

-Added a "-forceupdate" cmdline argument.

This argument forces the knet to download the currently avalible version in repo, no matter of the version. This can be used to test the update system of the main branch before creating a release. And it is what ive been using to test the update system.

Using the -forceupdate argument also prints some progress text to console, this is probably something you can only see in Linux and mac if you start it with this argument from terminal.

notimaginative commented 8 months ago

Couldn't the update script be an asset, which is then just saved out and executed? That would make them much easier to update/edit in the future.

The mac version will need to be able to handle a regular update and a bundle update, so it might get a bit complicated/long. And technically the linux script could have a special condition to handle the appimage as well. For that matter, the windows script could conditionally download and run the installer (silently) rather than using the plain archive.

Shivansps commented 8 months ago

Ok after the last change i update the first comment: 1) Update system now has two phases, phase 1 is the one that finds updates, display them, downloads the files and extract them (if needed). Phase 2 is done by a external script that waits until Knet closes, update the files and re-opens de app. 2) AppImage now also uses this system.