View Full Version : Is there a secret recipe to make patches and upgrades work?

10-16-2003, 05:52 PM
as the subject implies...isdev7 is causing massive frustration...perhaps some more experienced users can shed some light?

I am using isdev7.03

can somebody tell me if minor upgrades and major upgrades work in this version? If they don't, what version do I need to upgrade to so that they will work. For a major upgrade, I have had to resort to coding my own detection of an older version during the "On Begin" phase and running the uninstall myself.

can somebody tell me if patching works in this version? Again, if not, then what to I need to upgrade to? The process sounds simple enough. I have tried to create a test patch, but it does not work. Here are the steps I took in trying to create a simple test patch...is there something wrong with what I have done?

1) open original project "Sept2003"
2) choose "Save As..." and call the new one "Oct2003"...now change one of the files in the installation, "abc"
3) in Summary Information Stream,
-change "Subject" from Sept2003 to Oct 2003
-change "Package Code"
in Add/Remove Programs,
-change "Comments" from Sept2003 to Oct2003
in Product Properties,
-change "Product Name" from Sept2003 to Oct2003
4) do not change "Upgrade Table" in Direct Editor because Major Upgrade does not work...use custom InstallScript which detects new versions
5) build new uncompressed installation of Oct2003
6) open patch creation wizard
7) create "Oct2003-patch.pcp" in "Create a new patch creation properties file"
8) for the "Previous Packages" part, right click on "Previous versions" and add the original package "Sept2003"
. Select "Sept2003" and:
-set the "File Name" to the "Sept2003.msi"
-keep everything else here default
9) for the "Newer Package" part, select the new file "Oct2003.msi"
10)for the "Patch Package Identity" part, use the default "Oct2003-patch.msp", generate a new "Patch Package GUID"
11)for the "Previous Patches" part, keep the defaults "Disk ID: 2" and "File sequence start: 2079"
12)for the "Windows Installer Service", keep the default "Create patch launcher", set OS support to "WinNT/2K", the version to 2.0
13)for the "windows installer location" extract from update.exe
14)for the "installscript engine" extract from update.exe
15)for the ".net framework" do no include or set up .net framework
16)for the "Patch Creation Settings", check "allow version numbers to differ", "allow product codes to differ",
"use entire files in patch package"
17)for the "command line settings" do not change anything
18)patch creation wizard says "abc" differs and is putting it in the patch update.exe

when I run update.exe I get:

1628: Failed to complete installation.

Variations that I have tried that also failed:
-do not create the update.exe file, just create the .msp...if I try to install the .msp, I get something like "you need to run setup.exe to install this file"
-put the upgrade code into the upgrade table and rebuild the Oct2003 installer package and then try to create a patch...the same "1628" message happens.

10-17-2003, 04:51 AM
From my experience, patching and upgrades just don't work with "Standard" projects. I encountered all kinds of weird errors and never got it working correctly.

Eventually, I switched to the "Basic MSI" project type (which is actually a Standard MSI setup, while the Standard project is a InstallScript project :D).

With the Basic MSI setup, getting patches working was way less of a PITA, i.e. my patches are working without major problems now.

I know this won't help you much... if you can, I'd suggest to switch to the Basic MSI setup.

Oh, in any case, you should get SP4 for IS7.

10-17-2003, 07:28 AM
The one thing that I found out about creating patches is that you will be more likely to have a successful patch only after you've created a successful upgrade.

I always create a minor upgrade first, make sure that all is working as expected, then create the patch with pretty much default options in the wizard.

I had a lot of problems creating a patch from a major upgrades, so I would recommend you create a minor upgrade first.

I am also using InstallScript projects. The patches tend to be bigger though than for BasicMSI.

10-21-2003, 03:04 PM
well, I've basically come to the conclusion that developer 7 has been broken in this regard from the very beginning and it has never been fixed (yes, I've installed sp4 as well). Considering that we originally upgraded from installshield 5 because of this supposed feature, I feel robbed right about now.

For others who have tried to do the patch/upgrade thing using developer 7 and failed...I would say forget it - its not worth throwing hours into a black hole. Developer 7 is terminally broken and apparently will never get fixed. Accept that you were cheated and if you're not too too mad with installshield, check out devstudio9.

I downloaded the new devstudio9 evaluation and found that it can create a patch which ACTUALLY WORKS when using pretty much the same steps that I outlined in my original post.

10-22-2003, 11:40 AM
In all humility, I guess I'm one of the lucky ones. I have been creating patches for my Standard project under all SP's of the ISDev 7 series. To even my surprise, I was able to successfully creat a major upgrade that detects and uninstalls previous versions. Currently I'm using ISDev 7.04. Sure I've had to put in many support calls, put in a LOT of time and patience, but the problems were usually narrowed down to one of the following:

1) Accidently changed a component ID.
2) Didn't rely "COM Extract at build" for my dll's.
3) Upgrading from 7.03 to 7.04. Specifically, created build "A" under 7.03....upgrade to 7.04....create build "B" under 7.04 and tried to create a patch from "A" to "B" under 7.04. Problem was due to a MergeModule's component ID changing...which was out of my control.
4) Didn't set one and only one key file in each component.
5) When something, like a MergeModule, forces a reboot, my silent install fails since the dialog order changed.
6) Generally breaking any of the "Minor Upgrade Rules".

I would, however, have to agree that I'm discovering that the Basic MSI project seems MUCH easier to manage and deploy. I am having a heck of a time getting my Standard MSI Projects to deploy using Intellimirror, Elevated Privledges, or SMS. For that reason, I would agree that Basic MSI is the way to go.

As for your patching problems, I'm not sure how much help I'd be to you. But for what it's worth, ISDev 7 does seem to be working for some of us with a high pain-tolerance and patience level...oh, and a support subscription ;) .

10-22-2003, 12:54 PM
I forgot to mention this, but maybe this will help...

At some point early on in my patching experience, I read an article that suggested that a bug was discovered in ISDev7x that causes version comparison to be backwards in the patch creation wizard. So, early in my "patching" steps, I made it a habit of changing the "Version Relationship" setting of the "Previous Packages" dialog of the "Patch Creation Wizard" to "New Version <= Previous Version" and have been successfully using that condition throughout my patching experience in ISDev 7.

Note: I first saw this bug reported in InstallShield's sister site, InstallSite.org. I have since been unable to find it, or any other clear confirmation of this "bug." As a matter of fact, while attending the "Making Sense of MSI" workshop in early 2002 or late 2001, I asked an InstallShield product evangelist and the trainer about the "bug" and they both looked at me like I was out of my mind....went as far as to tell me that I wasn't even making sense (I WAS greatly offended and took their smug attitudes as extra "salt" on an already demeaning insult...but that's another story). More recently (Summer of 03), during a support call, I mentioned this and was told simply to keep doing what I've been doing...as if there was a "bug" but he/she didn't want to talk about it. The closest I've come to any form of documentation is...

Some other helpful articles (I'm sure you've already read/seen most, if not all of these....but just in case, here they are again):

FAQ: What is the Best Way to Author a Patch?

HOWTO: Successfully Authoring a Patch

Hope this helps...