Implement a publisher
dady8889 opened this issue · 7 comments
Introduction
As this project seems to be my main alternative to Squirrel while converting my apps to .NET Core 3.1 / .NET FW 5,
I would like to put out the idea of a dedicated (Windows) installer / publisher in similar fashion to Squirrel.
(I will be using the term .NET 5 for whatever the correct version will be.)
Notes
I guess making the Installer/Uninstaller parts are the hardest, however I will have to replace Squirrel eventually and it's good to have some plan at least. This project does not need to be made under the Onova name, but if I ever start working on this, I will fork Onova. If Squirrel finishes the rework on time, I guess this will not be as needed. But still, I have issues even with the current working Squirrel so creating this would still benefit me (at least).
Publisher
- Implemented in .NET 5
- Available NuGet as Onova.Publish
- Works the same as
dotnet publish, except it creates additional files for the Onova update system
Input
- Config file (e.g. some simple XML, not necessarily NuGet nuspec)
- CLI (publisher.exe -> read config file from $(SolutionDirectory) -> output to ReleaseDir)
Output
-
Zip package
-
Changelog file
-
Version A - Read config file and append the changelog entry into a unified CHANGELOG file with version tags
- This would mean that the Resolver would have to fetch just one file to get the whole changelog
- On the other hand, the Resolver would have to use some sort of regex to find the last entry
- The changelog could get gigantic and would defeat the purpose of this system
-
Version B - Copy changelog from config and paste to a new .changelog file that will have the same name as the zip package
- Probably easier to implement and suits my use case better
- If you want to show the user a list of all changelogs, you have to iterate over the manifest file and fetch all changelogs
-
Reason for this:
- I need to show the user a changelog before the download happens, currently in Squirrel I just put it into a nuspec and then during update I fetch the whole package, before the user clicks yes/no (which is obviously bad in every aspect I can think of)
-
This feature also needs to implement custom Resolver (probably can reuse WebResolver)
-
-
Manifest file (publisher scans ReleaseDir for *.zip and creates text file for WebResolver)
-
Installer file (executable installer that embeds the zip for the newest version)
- Must also contain an uninstaller
-
Hash file
-
Only a suggestion to implement - it is not required but I guess that it would be nice if the updater could also fetch a hash of the update package and check it in similar fashion to Squirrel
-
Why a standalone file? - The manifest file for WebResolver already contains the version number, I guess it could also be appended after the package URL to not break existing Resolver infrastructure (haven't looked into the implementation)
-
Suggestion: If both Changelog and Hash files will be implemented, it is advised to create new Resolver that will get everything under one roof (e. g. AdvancedWebResolver)
-
Installer
-
This file is generated using Onova.Publish
-
Probably compiled at runtime (during publish) using Roslyn
-
Version A
- Implemented in .NET 5
- Uses the trimmed (.NET 5 containing) single package or the single file package with prompt to install if FW is missing, whichever actually works
-
Version B
- Implemented in .NET 4.6.1
- Nothing extra should be needed, let's assume every system has this FW
- We can check if .NET 5 is installed
Properties
- Executable (.exe) file
- Contains the newest .zip package from publish
- Installer and uninstaller have icons (set in the publisher config)
Run
- Creates a folder in %localappdata% and extracts the embedded zip package
- Creates entry in Start Menu (also creates app publisher's name folder)
- Creates Windows registry entry for uninstaller
- Run the app itself after installation
Uninstaller
- Do whatever works on Windows to uninstall the correct files and itself (probably the same as Squirrel)
This sounds like a great idea. The good thing about Onova's design is that it's unaware of how the application appeared on the computer in the first place, so it doesn't matter which installer is used. But having a tailor-made installer for Onova makes sense.
Just to throw it out there - what's wrong with using NSIS or MSIX for Windows. Then again - Windows is only one of the OSes that would need to be supported. There's Linux, MacOS, *BSD as well. Probably more.
Nothing, I guess. In my case, having a full blown installer for a 5 MB application feels kinda weird, especially when I have multiple of those and I would probably have to create the installers and update packages separately, which is just pain that I don't want to bear. I will look into MSIX, that looks promising.
In that case what you'd really want is probably not a traditional installer - but a way for the application to detect if it's being run from some random folder or what's considered the "user install location" for the current platform and provide hooks for copying the application to any such folder. Say AppData for windows, ~/.local/bin (for systemd) for Linux.
For some platforms, like windows and .NET Framework - there could be standard dialogs and such for doing it - while for other platforms (.NET Core on any OS) it just provides hooks like the ones available for the update framework that's currently available.
Hi.
Unfortunately I have to descope this issue as the project has moved into maintenance mode, which means that new features are unlikely to get implemented.