Modify WinNUT Update Routines (ClickOnce deployments)

[gbakeman]

The old MSI Installer/Setup system is not CI/CD friendly, so the need has arisen to find a new packaging and deployment system. Per #85, ClickOnce is a native msbuild packaging system that looks like a good solution. Prior to completing that, the WinNUT client needs to gracefully transition from the old system to the new one.

Stage 1 - Integrate GitHub client library

The current system relies on parsing HTTP queries sent directly to the GitHub web API, and presents a Form control prompting the user to update. To prepare for integrating the new updating method, it would be good to have a solid foundation first. The updating system should be moved to the common library as much as possible, providing events to the WinNUT client as needed.

• Integrate GitHub library for updating #133
• Update Overhaul Part 1 - Octokit Library #176

This was accomplished in the above items. Functional update check and download code was moved to the Common library. WinNUT triggers an update check at startup when conditions warrant, and the user can manually perform an update check using the menu. When a valid update is detected, the new update Form is launched. Similar to the one previous, it will display the changelog and confirm if the user wants to install the update. The update is then downloaded, and launched, and WinNUT shuts down.

Stage 2 - Support ClickOnce migration

Now that ClickOnce build automation is working in #81, the ability to migrate to a ClickOnce installation needs to be implemented. The IsNetworkDeployed property can be used to verify if the current instance is a ClickOnce application. When an update is detected that contains a ClickOnce installer, and the current running instance is not, then a user setting should be set that an upgrade is in progress. The ClickOnce installer will be downloaded and launched, and the WinNUT instance terminated. On the next launch, the previous user setting will be checked, and if it's true, then launch an uninstallation of the MSI package. Make sure to reset the setting after.

• Create global variable that indicates if the current running instance is a ClickOnce deployment
• Create a user setting that indicates if an upgrade is in progress
• Check the upgrade in progress user setting at startup, and if it's true, launch the MSI uninstaller for the old product code.
• Modify update routine to download ClickOnce deployment
  • If current instance is not ClickOnce, set user setting and continue with update

Future tasks

• After full deployment, remove code for manually updating Settings Program settings not carrying over to new versions #135
• Consider paring down update code to rely on native ClickOnce update routines for checking and downloading updates
• Remove upgrade in progress user settings
• Remove Setup Deployment project and all references to MSIs in build automation

Deployment procedures

• Adopt true Semver versioning scheme for 2.4 release cycle (resetting the patch value to zero).
• Switch to dual ClickOnce and MSI deployment system with the next pre-release
  • Maintain this throughout the 2.4 release cycle to catch everyone upgrading
  • Starting with the 2.5 release cycle, remove the MSI build system and associated project, leaving only the ClickOnce deployments

References

• Release Building #81

• EV Certificate signing #84

• New Setup/Installer Build System #85

• System.Deployment.Application Namespace

• Upgrade an existing application to include ClickOnce