Key files and optional install files

[RonC]

I have a install package built with setup factory where a user can optionally select one or more modules to install. Assume that over time, I have modifed at least one file in each of the optional modules and I need to identify key files in each of the modules to correctly determine the version. The way I read your documentation seems to indicate I will not get a match on a previous version "if all key files do not match". If a user did not elect to install a module in which their have been changes to the code, and I include the new file as a key file, it seems I will never detect his version of the software correctly. Is there a way to do this?

I do write the current version of the software to the registry, but it does not seem from the documentation that I can use this as a key in identifying the version. Is this true?

[Mark]

Hi,

In general if a file is not a necessary file (i.e. if the file may or may not be installed) it should not be used as a key file. So when choosing your key files only choose files that will be installed each time the installation completes successfully.

From your description it seems like you should not select any of the files from the optional modules as key files. Instead add all optional module files to each version in Visual Patch. That way when Visual Patch updates it will update any of the optional module files that it encounters. You will probably have to set the module files to only install if a previous version of the file exists.

Sorry, but it is not possible to use the version information stored in the registry to help Visual Patch determine what version is installed. This is because Visual Patch does it automatically for you. You can however read the information from the registry and then use it in version specific actions.

[RonC]

Thank you for responding to my post, but you have not addressed my issue. Let me present it more clearly.

I have just released the first version of a product(1.0.0.0) that has optional modules. Now I find a bug in one of the files in an optional module, fix the problem and need to deliver the patch(1.0.0.1).

I prepare the patch as you suggest, using key files that are not in any of the optional modules. The patch in this case successfully executes by using those key files to determine that the user has Ver 1.0.0.0 installed.

The problem occurs when I need to install the next patch. The only difference between Ver 1.0.0.0 and Ver 1.0.0.1 is in a file in an optional module. Since the modified file in Ver 1.0.0.1 may or may not be on the user's machine, and that is the only difference between the two versions, I now have no way to define keys for Ver 1.0.0.1 that differ in any way from the first version if I am limited to using keys(files) that must exists on the user's machine. How do I select keys in the 1.0.0.1 version to distinguish it from Ver 1.0.0.0 as the version differ by only one changed file that is contained in an optional module. As a note, I do write all version changes to the registry, and that information readily exists on the user's machine to let me know he has Ver 1.0.0.1 installed but you provide me no way to get at it.

I am amazed that you do not allow registry interrogation to be used as keys that could easily establish version info, modules installed, etc. By only using files that must exists on the user's machine as keys, you effectively limit the patch process only to those install packages that do not contain optional installation modules. I hope you have suggestions for making the versioning process work for my install package and the scenario presented above.

Please consider making registry keys as an option in the next release. I recently purchased Setup Factory and TrueUpdate which are both excellent products with a rich set of operators. TrueUpdate has a registry mechanism for version detection and could be used as a model for extending your keys concept. The statement in your reply " This is because Visual Patch does it automatically for you", does not seem to ring true, unless I am missing something. I cannot figure out a solution for the problem presented above.

[Mark]

Hi Ron,

Thanks for clarifying your problem to me. I now understand the difference between version 1.0.0.0 and 1.0.0.1.

In a situation like this what you can do is follow my first suggestion (no key files in your modules), and then time-stamp your key files when you put out version 1.0.0.1. The will create a key-file difference between version 1.0.0.0 and 1.0.0.1 that Visual Patch will be able to catch.

Thanks for the suggestion regarding the use of Registry key to help make version determination. This is a very good suggestion and I have added it to our suggestion database.

[RonC]

Hi Mark,
Thanks for the response. I understand conceptually what you mean by timestamping my key files. Probably a dumb question, but how do I accomplish that. Will I need to recompile a key file to accomplish that?

[Brett]

You want to use a "touch" utility. Do a search for "touch" and maybe "time date stamp" as well on Google or a file download site. You should be able to locate a free utility to do this fairly quickly.

Try this one: http://www.gregorybraun.com/FMXTouch.html