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.
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
[x] Create a user setting that indicates if an upgrade is in progress
[x] 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 #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
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
msbuildpackaging 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.
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
IsNetworkDeployedproperty 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.Future tasks
Deployment procedures
patchvalue to zero).References
81
84
85
System.Deployment.Application Namespace
Upgrade an existing application to include ClickOnce