Explicit Specification of Update Directory/Path

Proposal

Allow for explicit definition of where content is to be extracted by the Onova updater.

The specific purpose of the proposal is to extend Onova to be able to update more than just the currently running application itself.

Potential Use Case

• Application consists of multiple sub-applications/components integrating with each other.
  • Each sub-application/component may be maintained and updated independently e.g. in a different repository.
  • Initial setup may bundle multiple of these applications/components together.
  • Integrating Onova in each of these applications is technically a possibility but would make no logic/sense if, for example, the individual component is a plugin as opposed to a full separate application.

Existing API

public class UpdateManager : IUpdateManager
{
    public void LaunchUpdater(Version version, bool restart = true)
}

Proposed API

public class UpdateManager : IUpdateManager
{
    public void LaunchUpdater(Version version, bool restart = true) // Calls other overload with directory = null
    public void LaunchUpdater(Version version, string directory, bool restart = false)
}

If directory is null, Onova.Updater should be ran with existing default exe path.

Additional Changes Required

It may be necessary to make a simple change to Onova.Updater to allow for the specification of a file to launch (restart) on completion of the update explicitly rather than assuming folder from a file path.

[Sewer56]

Is this a use case you currently have?

This actually is a use case I currently have.

At the end of 2017, I started working on a program known as Reloaded-Mod-Loader , which took me around 7 months to get to a version I was happy with.

Reloaded is a DLL Injection based utility allowing for modification of software behaviour through the injection of (mainly C#) DLLs which execute arbitrary code inside the target process. It’s primary use is for modding games although it does have some uses outside of the scope such as for example snooping what files a specific program is loading in real time.

One of the features of Reloaded is that it currently supports the updating of mods using Github Releases (custom implementation). As the individual mods come in the form of DLLs loaded by an external application and not directly executable, it doesn’t make much sense for them to implement their own update mechanisms. By the time they execute, they are in use as they are loaded by some process on the system. In addition, some mods consist only of assets/files, which are picked up by other mods that implement code and are used e.g. for file redirection.

At the moment, Reloaded itself uses Squirrel to update itself using Github Releases as the source.

Nonetheless, how I originally found Onova is actually because I am in the process of rewriting/refactoring Reloaded. Reloaded grew to become a very large project, with all of its libraries and sample mods spanning over 50000+ lines (and originally having no tests!). First, I split the large libraries into smaller, faster, documented, better and more testable chunks over at Reloaded-Project Github Organization. Now more recently I learned WPF and recreated the original WinForms theme in WPF and will soon be doing a rewrite of the actual launcher/loader.

I wanted to move the rewrite away from Squirrel due to slow update performance, forced install in LocalAppData as well as leaving 4MB of residue in every build and unify the update system for mods with the update system for the application itself. I already had plans as to how I would build the new update library from scratch, until I came across Onova, which is here, already exists and is exactly what I wanted to build down to the core update logic (in place updates, external executable).

Nonetheless, in addition to less code to maintain and the reasons above, building it using Onova would save me around 4.7MB in each build on dependencies alone.

---

This was a bit long but nonetheless.

TL;DR I want to update the application as well as a set of user made mods (DLLs) separately using the same update library.

---

Edit;

Forgot to say, the changes for this are rather simple so if it’s not available by the time I’ll need it, I’ll PR this as a feature myself 😉

[Tyrrrz]

Just need to make sure that the path you specify is the path to exe that starts your application. That path is used when applying update, for checking whether the application is running, and also for launching the application again after the update finished (if that option is enabled).