View Full Version : QuickPatch rules ?

01-23-2003, 09:51 AM
What are the rules concerning the creation of subsequent patches for an installation ?

I have a base installation.
I patch it once.
If I create a second patch, can I apply the patch to a base installation, or can I only apply it to an installtion with the first patch already installed ?


01-23-2003, 05:46 PM
Yes it's possible. Basically this is done in the History View (in General Information). I'll try and expand through an example:

Suppose you have you base setup (Setup1). You create a QuickPatch for this (Patch1). You update some files in Patch1 and build. Now while Patch1 is open in Express, on main menu go to Tools->Create a QuickPatch. This will create a QuickPatch of Patch1 (Patch2). Note that from this point onwards you will be dealing with QuickPatch projects only. That is you see only the Files and Registry entries.

Now in Patch2, update some files and then go to History View. Notice that it will show Setup1, Patch1 and Patch2. All three have been selected. So if you build Patch2 now the follwing scenarios will work:

Setup1 -> Patch1 -> Patch2
Setup1 -> Patch2

In both cases the end result will be the same.

Now in the History View if you deselect Pacth1 and build, ONLY the following scenario will work:

Setup1 -> Patch2

Trying Setup1 -> Patch1 -> Patch2 will give an error message saying it's (Patch2) not a valid patch.

Hope this helps!

01-24-2003, 06:39 PM
Thanks Chandima.

If that is the case, does the patch info get stored on the users' pc then ? It must remember that there was a "patch1" applied, or, does "patch2" look for file versions the same as "patch1" ?

It all sounds a little too complicated - I know it's Microsoft. It would have been simpler to be able to create a patch and apply it, regardless of version.

All I want to do is copy a new exe file and ocx to the users' pc !


01-27-2003, 01:34 PM
I'm afraid this is all imposed because of the strict rules Windows Installer patching has. The Patch does get registered on the machine but I'm not quite sure where this happens. All I know is that once you run the patch, you will see the corresponding msp file in C:\Windows\Installer.

The QuickPatch would be an ideal solution for you (because it'll take less than 5 minutes - hopefully!) to create a patch that installs two files. The default setting of the QuickPatch project would be to install these two files regardless of whether it's running on the original setup or patched version.

The alternative would be to use a normal setup project that installs these two files. You would set the "Use Add/Remove Programs" option to No then. Problems with this is:
1. You will need a Custom Action to determine whether your setup exists on this machine. There is sample code for this in a link of this property.
2. You will need a Custom Action to set INSTALLDIR so that the files are installed to the right place.
3. If you re-run the setup it will simply re-install (because it's not registered with Windows Installer).

11-26-2003, 01:52 PM

After reviewing several community articles I believe I understand how QP's work. I do however have one question that I have not seen addressed (maybe I just haven't found it yet).

I have an original setup (Setup1.0.0) and I create a patch (Patch1.1.0), later I create another patch (Patch1.2.0). I follow your instructions above so that Patch1.2.0 is can be applied as follows:

Setup1.0.0->Patch1.1.0->Patch1.2.0 (ie the patch is cumulative)

Now, what I don't understand is as follows: Every time I create a patch I create a whole new base setup, so new users won't have to download Setup1.0.0 and Patch1.2.0, they can just install the base setup Setup1.2.0. My question is this, if now I have another patch (Patch1.3.0) do I have to create two different QP files? That is, one for Setup1.0.0 that has been patched to 1.2.0 and one for the Setup 1.2.0? See below for a little clarification:

1st QP file for users that initially installed Setup1.0.0


2nd QP file for users that initially installed Setup1.2.0


New base setup file to reflect 1.3.0 changes for new users


Where Patch1.3.0a and Patch1.3.0b are my newly created patch files.

I think you see the problem I'm getting at, for every new base setup I have to create a patch file for all previous base setups, so when I get to base setup number 50, I'll have to create 49 QP files. Is this correct? There has got to be an easier way. Any help is GREATLY appreciated.


Ben Abbott
12-19-2003, 05:15 AM
Hi Jeff,

I have exactly the same issue as you do. I have done a lot of experimentation using older versions of our software and it would appear that you do need to create different QPs depending on the original setup that was used to install the application.

Here is my situation:

I have Setup1.0.0, Setup2.0.0 and Setup3.0.0. Using the History feature of QP, I have managed to build a patch to do the following:

Setup1.0.0 - Patch2.0.0 - Patch3.0.0

i.e. if the user installs v1.0.0, they can use the patch to get v3.0.0, via Patch2.0.0 if necessary. The problem is that if the user installs v2.0.0 (i.e. using Setup2.0.0), the patch will not work, reporting that it cannot find the applicatin to be patched. This seems very contradictory to me, given that in the history we have stipulated that the patch also applies to v2.0.0.

It seems the only answer is to release patches for Setup1.0.0 and Setup2.0.0. Of course, the problem is that as your product develops, at some stage you will release v4.0.0. This implies that you need patches for v1.0.0, v2.0.0 and v3.0.0. The logistics of trying to maintain this are a nightmare :( As you point out, by the time you get to release 50, you need 49 QPs...

As far as I can see, the best solution is to always use the same base setup and all new releases are patches on that base setup until a major new version is released, in which case you release the brand-new full installation. I think this is the route that my company will probably take.

This seems such a shame because by all accounts, it should be possible. I understand that InstallShield's hands are tied by the limitations that Windows places on patching but what a crying shame - something that should be so easy to do, isn't (and doesn't that just sound sooo familiar...!).

BTW. There does appear to be one feature to get around this issue and that is the "Generate Package Code" option on the "Express" options in "Build Your Release". However, having reviewed postings to this community, I would not recommend switching off this option.

BTW2. If somebody from InstallShield is reading this, I would very interested to know your opinion on what I have written here. I am currently in the process of reviewing the deployment policy for our software and need to determine the best strategy for deploying future releases.

02-19-2004, 01:33 AM
Would just like to bring this thread back to the attention of Chandima hopefully (or another InstallSiheld Rep).

Chandima do you concur with Ben Abbott's summary of how QuickPatches work in terms of new releases.

I am now in exactly the same situation as Ben and as I write this I was in the middle of creating a very similar scenario that Ben created to work this out myself.

By the looks of it I can stop my testing as Ben has confimed my suspicion regarding new builds and QuickPatches.

I am using ISE5 SP2, as topic was addressed quite some time ago, is it still relevant in v5, SP2 of ISE?

Thanks to all