lmodern1878
09-28-2024, 09:10 PM
Hello:
I've been working on a project for the last couple days and ran into a sticking point. Find below the details:
The application in question is a "maintenance wizard" for my existing project. How it works is that it uses setup types to determine of the user wants to "Repair", "Modify" or "Remove" the application. The repair and modify functions use zip files that correspond to each feature and an INI file to determine what is already installed. On initial installation, a hidden folder called "repair" is created in the installation folder with the zip files for the selected components and in INI configuration file This maintenance application is compiled and included as a support file and at the end copied over to the repair folder.
If the user chooses "repair" the tool reads the feature state from the INI file and unzips the needed ZIP files to the program's installation directory thus "refreshing" the original file set. The "Modify" functionality is half-baked because it uses features to add to an existing installation but cannot take them away. Again, the program reads in the INI to determine what's already there and hides the features already installed, the user picks the new features to add and then the installer unpacks the relevant zip files to the correct destination folder, puts the relevant zip files from a temp directory into the Repair folder and updates the INI file and then makes each feature its own separate install log.
Now the remove option: In the application's main installer, I've unset the "hide modify" option in the "add/remove" page or project properties and leveraged a registry feature at HKLM\Software\Microsoft\Windows\CurrentVersion\{Pr oductGUID}\ModifyString so Windowes knows where to look for what to do if the user chooses "Modify" rather than "Remove". If the "Remove" feature is selected, the maintenance application again reads from the configuration file and determines what's already installed and stores the state of the features in a variable as a bitfield where 1 is "installed" and 0 is "not installed. If the user asks to uninstall the uninstaller from the main setup.exe launches (unbuild32.exe) with the /U followed by the path filename of the log to that feature (example: Unbuild32.exe /U C:\MyApp\Uninst_feature1.log" and repeats this process 5 additional times with the last operation being to uninstall the original program (example: unbuild32.exe /U C:\MyApp\Uninst_MyAppMain.log). The problem comes that after the main app's uninstaller runs, it tries to clean up after itself and remove everything it originally put there (including maintenance.exe which is in use).
I've set the maintenance.exe to set the installer flag to "always delete installer" in an if statement thus "if %_SB_SETUPTYPEID%="Remove" then..." at the end (after the user clicks finish) and what gets left behind is the "repair" directory (example: C:\MyApp\Repair) most times it's empty but sometimes maintenance mode installer is left behind. I've investigated the "Reboot/Resume" functionality that is a no go.
Thus the question becomes how can I create a "delayed" action (e.g. move, delete, etc.) that way if the user chooses "remove" everything is removed and at the next reboot any files/folders in use have the necessary actions taken.
I've been working on a project for the last couple days and ran into a sticking point. Find below the details:
The application in question is a "maintenance wizard" for my existing project. How it works is that it uses setup types to determine of the user wants to "Repair", "Modify" or "Remove" the application. The repair and modify functions use zip files that correspond to each feature and an INI file to determine what is already installed. On initial installation, a hidden folder called "repair" is created in the installation folder with the zip files for the selected components and in INI configuration file This maintenance application is compiled and included as a support file and at the end copied over to the repair folder.
If the user chooses "repair" the tool reads the feature state from the INI file and unzips the needed ZIP files to the program's installation directory thus "refreshing" the original file set. The "Modify" functionality is half-baked because it uses features to add to an existing installation but cannot take them away. Again, the program reads in the INI to determine what's already there and hides the features already installed, the user picks the new features to add and then the installer unpacks the relevant zip files to the correct destination folder, puts the relevant zip files from a temp directory into the Repair folder and updates the INI file and then makes each feature its own separate install log.
Now the remove option: In the application's main installer, I've unset the "hide modify" option in the "add/remove" page or project properties and leveraged a registry feature at HKLM\Software\Microsoft\Windows\CurrentVersion\{Pr oductGUID}\ModifyString so Windowes knows where to look for what to do if the user chooses "Modify" rather than "Remove". If the "Remove" feature is selected, the maintenance application again reads from the configuration file and determines what's already installed and stores the state of the features in a variable as a bitfield where 1 is "installed" and 0 is "not installed. If the user asks to uninstall the uninstaller from the main setup.exe launches (unbuild32.exe) with the /U followed by the path filename of the log to that feature (example: Unbuild32.exe /U C:\MyApp\Uninst_feature1.log" and repeats this process 5 additional times with the last operation being to uninstall the original program (example: unbuild32.exe /U C:\MyApp\Uninst_MyAppMain.log). The problem comes that after the main app's uninstaller runs, it tries to clean up after itself and remove everything it originally put there (including maintenance.exe which is in use).
I've set the maintenance.exe to set the installer flag to "always delete installer" in an if statement thus "if %_SB_SETUPTYPEID%="Remove" then..." at the end (after the user clicks finish) and what gets left behind is the "repair" directory (example: C:\MyApp\Repair) most times it's empty but sometimes maintenance mode installer is left behind. I've investigated the "Reboot/Resume" functionality that is a no go.
Thus the question becomes how can I create a "delayed" action (e.g. move, delete, etc.) that way if the user chooses "remove" everything is removed and at the next reboot any files/folders in use have the necessary actions taken.