Modify WinNUT Update Routines (ClickOnce deployments) #97
Description
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.
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.
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.
Enable ClickOnce deployment at all levels
- Initial ClickOnce automation support in Release Building #81
- Review process, document
- Work on personal fork to complete development and testing of full ClickOnce building and deployment to a GitHub repository
- Prepare documentation of entire process in WinNUT wiki
- Merge in changes (don't bump WinNUT version yet)
Enable WinNUT ClickOnce migration
Now that ClickOnce build automation is working, the ability to migrate to a ClickOnce installation needs to be implemented.
-
Implement ability for WinNUT to understand the circumstances of its current deployment (NoInstall, MSI, ClickOnce)
- The
IsNetworkDeployedproperty can be used to verify if the current instance is a ClickOnce application. - With build automation, somehow embed this information statically into the binary.
- The
-
Modify update check routine to find both MSI and ClickOnce installers
-
Determine if migrating automatically or prompt user
-
Modify GUI(s) to support displaying and notifying about the ClickOnce installer and migration
-
Implement routine to support MSI -> ClickOnce migration path, including removing the MSI version of WinNUT
- launch an uninstallation of the MSI package
-
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
ClickOnce features
- Access local and remote data in ClickOnce applications
- Migrate data storage
- ClickOnce and application settings
- Take advantage of app settings
- Localize ClickOnce applications
- Consider impacts of translations
- ClickOnce and Authenticode
- Skipping for now due to complication. Will reconsider if necessary.
- Choose a ClickOnce update strategy
- Remove custom updater and use ClickOnce built-in updating
- Alternatively: keep custom updater, but use GitHub library to fetch update information.
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
patchvalue 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