Updating software version using TrueUpdate

[Chris L.]

Hello,
I am trying to make sense of some things that were left outstanding by some developers leaving - We use SetupFactory to do the initial install of our software. Then, we use TrueUpdate to update any files that need to be over time. What some customers are reporting is two-fold:

1) we can set the version of our software so that it appears in that Apps & Features section of Windows so users can see what version it is that way. However, how do we update this version value/setting when we just replace the files using TrueUpdate? I understand it may be a matter of setting a registry or something, but my knowledge of all the commands is limited.

2) With regards to the uninstall, it seems as though not all files that may get updated with TrueUpdate will be removed if clients were to uninstall our application (using the process created from the 'initial' setup-factory install. Any suggestions?

Thank you,
Chris

[Ulrich]

Please open Setup Factory, then go to Uninstall - Control Panel. On this dialog, click the Help button. You will see the product documentation for the Control Panel settings, which show you where the product information is stored in the registry. Note that, if your setup and product is a 32-bit program, you would need to check the 32-bit hive. Check the "Unique Registry Key" of your setup, open it on your device (or where the product was installed), and inspect the data stored in the registry.
You will find that the version can be saved as part of the "DisplayName" and/or "DisplayVersion". You can update these values with the registry actions provided via Lua scripting in TrueUpdate.

When you install the initial version of the product, a list of the files and folders created by Setup Factory will be saved in a file named "uninstall.xml". If you use Setup Factory as well for updating / overwriting an existing release, typically the uninstall data file would be updated, merging the new files / folders into the existing list. If you download the files directly and deploy them manually, then this file is not updated with the new information, and when the uninstaller attempts to roll back the installation, first by deleting the files and then by removing the folders, it would fail, as a folder may not be empty, because there are new and unexpected files.
This would need to be addressed from the start, when the setup and uninstaller are designed and first deployed. If there is the chance that new files are placed into the application folder, you could typically use an action such as Folder.DeleteTree() to empty any remnants from the folder, or use File.Find() to obtain a list of the files, and delete them individually before going to the step where the folders would be removed from the user's system. However, you cannot update these installation/uninstallation scripts and actions now, using TrueUpdate.
I mentioned the "uninstall.xml" file above. You can, again using Lua scripting and the provided XML actions, update the file processed by the uninstaller, adding the files and folders deployed after the initial installation. In this manner, the uninstaller should be able to process all files as if the were part of the first install, and remove everything.

Ulrich

[Chris L.]

Hi Ulrich,
I appreciate the response. Most of what you state makes sense (though, admittedly, I am fairly far removed from developing theses days). However, if I may, a couple clarifications, based upon the above:

We have over 40 clients and not everyone gets the same files as part of the install. We have a little more work on the Setup Factory side, but we use a .config file with TrueUpdate so that we only have 1 'update' process, but separate configs for each (for server names, specific shortcuts etc.) Based upon what you state above, do you think it would be better if we just used SetupFactory and basically 'reinstalled' our software each time? There are some aspects that only need to be done 1 time, but we could probably check for those as well.

Most of the clients use a login script that they will enable the TrueUpdate executable, but that could just be whatever 'installer' exists in server-based folder as well. Thoughts?

Thank you,
Chris

[Ulrich]

Hi Chris, even if you have different config files with customizations for each client, TrueUpdate should still be able to handle the changes in the XML file. This, of course, depends how you process these updates. For example, if you have a zip file and decompress it, you can use the Zip actions, extract the file names contained in the archive, and check if these files are already listed in the XML file, or if they are new and should be added. If you download files via FTP or HTTP/HTTPS it would be similar - TrueUpdate would at some point have access to a list of files to process, and you could update the XML as needed.
Now, you also could use TrueUpdate just to check if there is a new release for the current client, perform the download, start the uninstall and then reinstall... as long as the TrueUpdate client is not part of the setup, or you might run into an issue when the uninstaller is attempting to remove a file currently in use.

Ulrich

[Chris L.]

Good Morning Ulrich. I appreciate the response. I know there is much more we could be doing, but I need to get someone else here up-to-speed on the software and apply the ideas you stated.

I would love to utilize FTP/HTTP(S), but I would need to convince those 40 clients (mostly gov't) that it would be 'ok'. Thanks, again.