InstallShield Tips and Techniques

June 27, 2011

InstallShield Upgrade Strategy

Filed under: Reference Materials — shieldmaster @ 9:42 pm

Quite a concern with customers is what strategy should they follow when delivering future updates to their application. The confusion as to what to delivery (Small Updates, Minor Updates, Major Upgrades, Patches) leaves the customer paralyzed with indecision. Couple that with having a part-time InstallShield developer (or consultant), and you will need to evaluate a strategy that blends reliability with ease in creating and QA testing an upgrade.

In this post, I would like to outline a roadmap for your Upgrade Strategy, giving both Pros and Cons as well as realistic guidance that experience has provided.

Packaging Options

First, let’s discuss the various packaging options that are available to you.

  • Each upgrade can be packaged for delivery as a full MSI installation which can offer existing clients a method to deliver just the updated files, or a full replacement of the original package. The advantage of creating a full MSI installation is that it can be delivered to new customers and they will be able to install and configure as easily as the original installation.
  • An upgrade can be packaged as a Windows Installer patch file that offers existing customers a smaller footprint, and will apply binary file differences that will upgrade a file from the previous version to the newer version. The effort to create this is relatively simple, but must be tested as much as a full upgrade package. In addition it can only deliver updates to existing customers after a full installation – a new customer cannot install a Patch package and have a working program.

Windows Installer GUID Codes

The GUID Codes associated with each InstallShield package play a major role in how Windows Installer determines whether the package being installed is considered a new installation, or an update that is being handled as a Major or Minor upgrade.

  • Package Code – must change for each build. Pretty much ignored for your requirements.
  • Product Version – MSI Property – Only 1st three fields used by Windows Installer for version comparisons (Build # ignored)
  • Product Code– MSI Property – GUID of product. If two packages with same name have different ProductCode’s, MSI treats both packages as different!
  • Upgrade Code – MSI Property holds GUID of family of products – used for patching purposes. Essentially never change for life of application!


Here is a matrix that graphically displays when each GUID should be changed:

Now, let’s discuss the various vehicles that InstallShield provides to deliver updates to your customer.

Small Update

This type of update is characterized by just some simple product changes – so small in scope that you don’t alter the Product Version number. Some requirements you must adhere to when preparing the installation to be delivered as a Small Update:

  • Can add a new component to an existing feature
  • Can add a new component to a new feature
  • Can add new sub-feature with new components
  • Cannot change MSI Package name
  • Cannot move or delete a feature
  • Cannot move/delete component
  • Cannot change Component GUID
  • Cannot change the Key file of a component

In practice, delivering a new full MSI Package without changing the Product Version ensures you will have no means to track which customer has received this package. Granted the Package Code will always be regenerated, but that is not easy for the customer to determine. Realistically this might be a method to rebuild the package while it’s in the QA stages – I just don’t see a practical use for delivery to customers.

Minor Upgrade

This is the typical solution that most developers deliver to their customer base. Characterized by a full rebuild of the package with the Product Version changing (goes from version 2.1.3.xx to 2.2.0.xx), it most often will contain newly compiled binary files that resolve a customer reported defect. When the new customer receives this package, a full installation will occur with all of the User Dialogs presented with version 2.2.0.xx installed.

When an existing customer (v2.1.3.xx) receives this package, they will see a small dialog asking “Do you want to upgrade the application? Y/N) – and then they would just see the progress bar as the updated binaries are applied. Note that no User Dialogs will appear, the same destination drive/directory are maintained, plus any features selected within original installation are preserved with no ability to change.

A patch can be created that provides a method to deliver the Minor Update changes in a smaller footprint versus delivering a full MSI package.

Note that it is critical that you have followed “Best Practices” when creating the components – and key files are set for all versioned binary files. If you keep all of the non-versioned files in a component, it would be recommended that you select a versioned file as the Key file of the component.

Some requirements you must adhere to when preparing the installation to be delivered as a Minor Upgrade:

  • Can add a new component to an existing feature
  • Can add a new component to a new feature
  • Can add new sub-feature with new components
  • Cannot change MSI Package name
  • Cannot move or delete a feature
  • Cannot move/delete component
  • Cannot change Component GUID
  • Cannot change the Key file of a component


Major Upgrade

This is the method by which developers introduce a significant change to the application, which would require the user to completely uninstall the original application and then the new application is installed. With the authoring of a Major Upgrade entry, this process is accomplished seamlessly when the new installation is executed by an existing customer.

Most importantly, you decide when a new release qualifies as a Major Upgrade, for example version 2.2.0.xx to 3.0.0.xx might qualify, but you may want to have 2.2.0.xx to 2.3.0.xx be handled as a Major Upgrade, especially if a new feature is introduced and you want the customer to be able to choose it during installation.

Some requirements you must adhere to when preparing the installation to be delivered as a Major Upgrade:

  • Can add a new component to an existing feature
  • Can add a new component to a new feature
  • Can add new sub-feature with new components
  • Can change MSI Package name
  • Can move or delete a feature
  • Can move/delete component
  • Can change Component GUID
  • Can change the Key file of a component

As you can see, it’s pretty flexible since the original installation is being removed you have free rein in doing anything you want with Features and Components.

You can specify the behavior of how the Major Update is applied, you have the following choices:

  1. Completely remove the original application, registry entries, and files, then install the new application. Note that none of the original files are preserved or backed up during the process.
  2. Overwrite the original application, then weed out obsolete files as necessary.

Realistically, I always choose option #1, because it offers the customer the flexibility of choosing a different drive and destination folder.



Here are the Pros and Cons that I am aware of with each upgrade approach ( I am ignoring Small Updates completely):

Minor Update


  • Works consistently when a versioned binary files has newer version number (matches InstallShield product version).
  • Allows you to create small “Patches/Updates” from this new MSI package.
  • Process is typically “built” into an installation, requiring overt entries to the Upgrade table. Accomplished simply by altering the Version number.
  • Can use Patch process to deliver changes in a smaller footprint


  • No user dialogs presented, so customer has to live with the original drive and directory.
  • If package delivers a registry entry, which is modified by InstallScript Custom Actions – or during the user dialogs, this may not be done during Minor Update, consequently you might have empty variables in the registry after the update. Modifying the REINSTALLMODE properties can prevent the registry from being rewritten. Creating a new Custom Action that runs with Condition=Installed will also work towards resolving this issue.
  • Application files that are configured by the customer during application execution should be preserved – but you have to watch to ensure they are not overwritten by the template within the CAB files. Sometimes a InstallScript Custom Action that preserves the user configuration files before the Upgrade process and then another to restore it after the Upgrade process is necessary.
  • Delivering new non-versioned files (XML, INI, CFG, etc) may not be delivered consistently (Refer to link regarding File Versioning rules). Only alternative to ensure new non-versioned files are consistently delivered are to modify the REINSTALLMODE properties to force all files to be delivered (overkill at best), or create an InstallScript Custom Action before the update step to delete the critical non-versioned files to ensure that they are always delivered.
  • Cannot make significant changes to organization of the package (for example, restructure the Features)



Major Update


  • Allows unlimited reorganization of Features and Components – essentially a vastly different package than the original one
  • Allows you the ability to wipe out troublesome packages that were originally delivered that are not easy to properly apply updates to.
  • Full user dialogs presented, allows existing customers to choose different Features, specify a different drive or destination folder
  • Removes existing product silently at beginning
  • To denote a Major Update, you must:
    • Regenerate the Product Code GUID
    • Change the Version Number
    • Author a Major Upgrade entry in the Updates table



  1. to run a Custom Action during uninstall of Original Product, use condition “Remove=”ALL” not “UPGRADINGPRODUCTCODE”
  2. To run a Custom Action during upgrade, use condition “UPGRADINGPRODUCTCODE


  • Must be mindful that the uninstall may not completely remove all or the original installation, which could pose problems for the new installatino



These recommendations are based on years of providing consulting services to small development shops that don’t have a Full Time Dedicated InstallShield Developer. Consequently, your upgrade strategy should focus on creating Upgrade packages that are:

  • easy for the customer to apply and relatively Bulletproof so that valuable hours are not wasted dealing with customer upgrade issues.
  • Able to consistently build with repeatable results
  • QA can handle the iterative testing to ensure files are delivered correctly in all scenarios


  1. Small Update – don’t even think of them in a customer environment!
  2. Realize that creating Minor Upgrades will require extensive InstallShield package testing and particular attention to the treatment of non-versioned files. Don’t create a Minor Update unless you are going to devote the testing to ensure all files correctly updated.
  3. Patches require extensive testing, far beyond their worth in the field – which is mainly a smaller download size. I would just create Minor Updates, test correctly and release this to both existing and new customers.
  4. If you have no user configured data to be concerned with, then I recommend that you consider every release a Major Upgrade. It removes the requirement to ensure non-versioned files are correctly, and you are sure everyone is correctly updated at the end. If you don’t have a dedicated InstallShield developer, or limited QA testing time this is the way to go.

    As far as the treatment of user configuration data/files goes, if you put in the System Search and/or InstallScript Custom Actions, and they are proven to work correctly – then releasing a Major Upgrade becomes quite straightforward and easy to manage for future releases.


Hope this helps!




  1. Thanks for posting this. I am new to install shield and needed to know which way to go. My only problem now is making minor upgrades that do not include the pre-requisite files.

    Comment by Daniel Brown — July 11, 2011 @ 7:36 pm

  2. Thanks for the post!
    Right now the issue I’m facing is that when I’m upgrading, the new files get wiped along with the old files after the installation, and inverting the order doesn’t allow me to have a good upgrade because some of the files get wiped before I get to use them to upgrade.
    Any ideas?

    Comment by dv1 — August 10, 2011 @ 9:57 am

    • During a Major Upgrade you have two options to preserve files/customized data – you can author Custom Action to archive files or you can use System Search to retrieve customized data values. Otherwise you will lose the registry values – or INI/CFG files that are outside of the Windows directory.

      Comment by shieldmaster — August 10, 2011 @ 9:47 pm

  3. I’m also new to InstallShield (IS2011) and hoping to read and learn more from your blog!

    I am using it to package our nightly builds (Generate Package Code=Yes) and the files are included dynamically so if files are added or deleted, there is no need to update the IS project (we are using Installscript MSI).
    The problem is that MSI decides not to install EXEs during Upgrade with the log message:
    Won’t Overwrite; Won’t patch; Existing file is of an equal version
    The EXEs have newer compile dates, even though they are the same binary since the source code didn’t change.
    Other java jar files get this message:
    Won’t Overwrite; Won’t patch; Existing file is unversioned and unmodified – hash matches source file
    The jar files have newer compile dates as well.
    Lastly, newly added files do not get installed with this message:
    To be installed; Won’t patch; No existing file

    Is there a setting in InstallShield or MSI to always install new files and only overwrite older files?
    The full package is 40Gb, and uninstalling and re-installing would not be feasible every time we build.
    I am not updating Product Version or Product Code since this is an internal development build (not ready for release).
    Any suggestions you have would be greatly appreciated.

    Comment by Andrew Chen — November 11, 2011 @ 9:43 pm

    • The built-in updating process for files employ one of two methods, for versioned binary files it looks at the version number only – a newer date is meaningless to the process. For non-versioned files (ini, jar, etc.) is looks at the time/date stamp – which as you have seen is not reliable. You have two options, 1) Set a key file in each component using a versioned file that you can use to trigger the other files to be installed, or 2) Alter the REINSTALLMODE property to be a value “amus” from its default “omus” – this will force all files to be reinstalled regardless of what the file would normally be handled.


      Comment by shieldmaster — November 12, 2011 @ 1:39 am

  4. Thanks for the tip. I tried the package with REINSTALLMODE=amus, but it still didn’t install all the files.
    It seems the only solution is to remove the previous install and re-install, but that isn’t practical in my environment.
    Looks like I will need to change my IS project from Installscript MSI to Installscript only and not use MSI.

    Comment by Andrew — November 14, 2011 @ 12:53 am

  5. I hope you can help me. I am doing a major upgrade. Some of the files that I’m installing are newer version of the old files, but I’m putting them in a different folder under “Program Files”. The upgrade seems to work (new files are where they’re supposed to be, the registry is updated correctly, shortcuts are okay), but the old .exe files still remain in the old folder. Is there a setting I’m missing that would delete these files or do I need to write a script to do this?

    Comment by Platinum Blond — April 12, 2012 @ 10:10 am

    • You are not missing anything – but what you will need to do is to add an entry to the table “RemoveFile” – which can only be done by using the Direct Editor section of the InstallShield UI. There is considerable reference data to guide you. The entry in the RemoveFile table will both remove the obsolete file, and delete it from the MSI Cache.


      Comment by shieldmaster — April 12, 2012 @ 6:47 pm

  6. I was under the impression that you should not add new features to a minor upgrade (at the top level), is this true? I have tried to add a new feature to the top level and the new feature does not get added when the upgrade process is done. If I make it a major upgrade then the installer then will uninstall and reinstall, which in some cases it is not the best solution.

    Comment by David McNulty — May 8, 2012 @ 1:59 pm

  7. May be I am missing something, but I do not agree with this strategy of Minor Upgrades and/or small upgrades. What if my package has 10 services. I have fixed major bugs in 2 of the services. If I create a Minor upgrade, it will upgrade all the services while I need to upgrade only two. Please note that services get stopped, overwritten, re-registered and started, which may cause outage.

    Comment by AKM — February 26, 2013 @ 10:09 am

    • The focus of the Blog entry was for the majority of customers that we assist – these customers who don’t have Full Time InstallShield resource. They need to be able to manage quarterly updates in the easiest, most trouble free method possible. For them a Major upgrade strategy that provides a consistent method is best. For the InstallShield experts, we can handle properly the creation of Minor Upgrades – we know what to evaluate in the MSI log. This is not possible for the vast users of InstallShield authoring tools.


      Comment by shieldmaster — February 26, 2013 @ 6:18 pm

  8. Hello,
    I wanted to create major upgrade patch, but it wrote “ERROR: Since MSI 3.0 will block installation of major upgrade patches with sequencing information, creation of such patches is blocked.”. Is there any switch to force use MSI 3.1+ or major upgrade patches are not supported? Do you recomend major upgrade patches?
    Many thanks,

    Comment by Marek — September 9, 2013 @ 3:38 am

    • Creating a Major Upgrade Patch is hard for most IS Developer to conceptualize. You could create a Major Upgrade Patch by authoring entries in the RemoveFiles section – but that seems too complex. I recommend strategy of Major Upgrade option of uninstalling old installation and installing new installation.


      Comment by shieldmaster — May 24, 2016 @ 10:27 pm

  9. Hello shieldmaster,

    There’s a legacy application deployed in production and there’s quarterly upgrade for that.

    The Upgrade source binaries is now available for this quarter. But before this package is going to deploy it must be converted into MSI. So moving forward all quarterly upgrades for this application will handled by Windows Installer.

    How should I handle this scenario? No removal of legacy is required only installation on top of it.

    Your comments and suggestions are appreciated

    Comment by Jeff — August 6, 2014 @ 2:01 am

    • Sorry for the delay.

      My recommendation would be to use AdminStudio (evaluation copy works) to perform your installation to capture it within MSI framework. We did that quite a bit in converting legacy apps to MSI packages.

      Comment by shieldmaster — May 24, 2016 @ 10:30 pm

  10. I hope you can help me. I am using InstallShield (IS2012) to package our product and auto generate fortnight builds(twice a month) . I want to know automated way to add autoupgrade item pointing to previous setup file to perform upgrade validation during the build process. (Media -> Upgrades -> prepare setup for upgrade scenarios) .I did not find any commandline options to achieve this. Is there any API support to set these properties?

    Thanks in advance for any help.

    Comment by Shiva — September 2, 2014 @ 6:42 am

    • Honestly have not done a lot of ISM modification during automation with the simple exceptions of ProductCode and ProductVersion. Why don’t you setup the ISM with Major Upgrade item, don’t specify version numbers – and make changes to the ProductCode and ProductVersion so that the new MSI will always upgrade any previous version that shares the same Upgrade Code?


      Comment by shieldmaster — September 2, 2014 @ 11:55 pm

  11. Shieldmaster please help.
    I have received a project that was created in IS2012 Spring, my installshield version is 2013 pro.
    After replacing binary file ONLY, two executables, i have changed the following: Package code, Product Version and product code.
    When using the installer to upgrade an existing version the following message appears “A newer version of this application is already installed on this computer…..”
    What am i doing wrong?

    Comment by NoamB — October 21, 2014 @ 7:36 pm

    • Sorry for the delay – I lost the feed for these emails.

      If you still haven’t resolve the problem, I suggest that you recheck the version number – it doesn’t appear to be correctly incremented. There is a custom action that disallows downgrading ISPreventDowngrading. This may need to be corrected.


      Comment by shieldmaster — February 27, 2015 @ 7:02 pm

  12. I am using 2015 version of InstallShield. My requirement is to prevent upgradation of my software from v2.3 to v2.4 with a prompt. But should allow v2.4.1 to v2.4.2

    Comment by Ab — March 21, 2016 @ 9:56 am

    • Looks like a Custom Action is required – use IS_MAJOR_UPGRADE=YES as the condition and then you can evaluate the upgrade scenario and allow or disallow it.

      Comment by shieldmaster — May 24, 2016 @ 10:24 pm

  13. Very nice post. I just stumbled upon your blog and wanted to say that I’ve truly enjoyed surfing around your blog posts.
    In any case I’ll be subscribing to your rss feed
    and I hope you write again very soon!

    Comment by Elizbeth — May 31, 2016 @ 2:12 pm

  14. Hi,

    Thanks for the crisp explanation.
    I’m looking at a scenario where I want a major upgrade to install at the same location as the old installation without prompting me to specify it.
    Basically I want the user to install in the same folder as the existing installation automatically/quietly.
    How do I set this up in the installer?

    Thanks in advance.


    Comment by Shekhar — July 29, 2016 @ 10:46 pm

    • Use System Search to pull the value from InstallLocation – for example this application installed has this entry: HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\{1502F427-F988-C5A0-DC84-BB03C560F72A} – this provides the installed location for the application. Then use Custom Action to reset the INSTALLDIR to this location and you are able to install the new app to the original location after a major upgrade.


      Comment by shieldmaster — July 30, 2016 @ 11:37 am

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Blog at

%d bloggers like this: