search

encratite / RiotControl

An elaborate statistics tracking system for League of Legends. It used to be a centralised PostgreSQL based system but now it's a stand-alone SQLite application. It was written in C# and makes use of the LibOfLegends RTMP library. It is licensed under the terms of the GPLv3. Unfortunately I stopped working on it in 2013-08. Check out the website for a longer explanation.
http://riot.cont.ro.lt/
GNU General Public License v3.0
33 stars 15 forks source link

Implement automatic updates for all RiotControl/RiotShield packages #51

Closed encratite closed 12 years ago

encratite commented 12 years ago

This was requested by numerous people today and it was only now that I realised that I hadn't actually added this to the issues yet.

This would require the implementation of three additional projects. They shall be known as RiotControlUpdate (WPF version for Windows) and RiotShieldUpdate (command-line version for Linux and such), both of which yield an Update.exe binary and a RiotUpdate class library which will be relied upon by both. It would be nice if Update.exe had no external dependencies. I'm not entirely sure how to make binaries like that with Visual Studiko but it's probably possible.

Now, one of the primary issues with writing self-updating applications is that they can't actually replace their own binaries while they are still being used. This is why at least two separate applications are required to deal with this.

This also requires the introduction of server-side version information. My local packaging system would have to start adding revision information to the archives created. Once uploaded these could be stored in an nginx-autoindexed directory. It can be read by RiotControl/RiotShield to determine the latest revision available to compare it to the one of the current assembly used.

Should the newest revision that is available be newer than the current one, the user will be offered an update dialogue in RiotControl. If the user chooses to update, RiotControl launches the Update.exe and terminates.

In the case of RiotShield, the user will not be offered any such dialogue but it will print information about the version check in the command-line. The user will have to launch the Update.exe manually.

Once the updating application has been launched it will download the most recent archive from the website. Identifying the right archive requires the introduction of a new field in the configuration which is different for each one of the three release types that are currently being offered. In the case of zip files it might be able to use the C# API to extract it, I am uncertain. Otherwise I might have to start adding some kind of unzip.exe, not sure. For the bz2 the application can simply use tar xf on Linux.

It will be extracted to a new Update directory. This requires special treatment of the bz2 file again, as its directory structure differs from that of the zip files. It is packed in a UNIX style way with an additional top level directory. All the DLLs and EXEs except for the Update.exe will be copied to the main directory of the application. The Update.exe cannot be overwritten yet as it is still running. At this point the Update.exe terminates and relaunches the main application. The main application then needs to check the Update directory. It then replaces the Update.exe and removes the Update directory.

Profit.

encratite commented 12 years ago

I greatly simplified the way the updates are applied - it's only one independent Update.exe for all versions. I decided not to make a WPF version after all. There is no library either. Appears to work... for now.