11 replies to this topic

[deramor]

Hello-

 

I have more of a upper level design question rather than a specific problem.

 

I would like to know what the correct way to handle an installation life cycle from version 1.0 of a product to version x.y with a number of patches in between.

 

Currently, my overnight builds generate major upgrades every build.  Each build can upgrade any previous build.  This gives us the ability to upgrade the fielded version 1.0 with 2.0 and so on.  I am having problems creating patches.  I read somewhere that the combination of major upgrades and patches don't work together.  So I am at an impass.  I need to have each new version of my product upgrade all previous versions but I also need to be able to patch specific versions too.  What would be your suggestions at a high level on how to do this?

 

I currently use Basic MSI projects and have IS 2010 - 2015 available to me though most installers are in 2010.  I havn't made the transitions yet for lack of time.

 

Thanks for your input.

 

Edit: fixed some spelling errors.

Edited by deramor, 23 September 2015 - 20:47.

[Berto]

Hi,

 

Our product works the same way: only major upgrades and each version can upgrade each older version.

 

When I got the request (years ago) to make patching available I had a look at the 2 technologies InstallShield is supporting:

1) Patch Design

2) QuickPatch

 

Now I fairly quickly gave up on Patch Design since our installer is really complex and does several non-standard operations like e.g. "updating databases". I had too many problems. Now it was a long time ago so i do not remember exactly details but i believe Patch Design could work if your installer is only doing basic stuff (installing files, reg keys, services, ... etc).

Next, I had a look at QuickPatch and had several issues as well (an InstallShield consultant at the time warned me: never use it!). Since i did not have many other options i worked through the issues I encountered with QuickPatch by applying workarounds and reporting bugs. InstallShield development was so nice fix these bugs in the next releases and i can say now that QuickPatch is working like a charm. It's easy, it's fast and the size can be kept very small (it will be not much more than the size of the files you need to patch). Management here was thrilled and we already used it several times patching thousands of customers.

 

Another nice advantage of QuickPatch is that you can make "accumulating" patches. 

Example:

Patch 04.71.0001 is created to patch file1 in base version 04.61.0001

Patch 04.72.0001 is created to patch both file1 and file2 in base version 04.61.0001

In stead you can configure QuickPatch to make patch 04.72.0001 target both 04.61.0001 and 04.71.0001 to install both file1 and file2 (if not already patched)

 

The biggest drawbacks of QuickPatch: 

- you can only target 1 specific base version. So if you have 5 releases in the field and they all need the same file to be patched, you need to make 5 patches.

- you can only use/re-use custom actions that are existing in your base installation (that's why I initially created some extra custom actions in my base msi that I only schedule to run during a patch if required)
A QuickPatch is in fact an intelligent "repair" running ...

 

There's also a third option which i know my colleague is using (200 000 installs!): an installation that is leaving no traces.

The idea is that you just create a new installer from scratch that will do its thing (like a patch) but leaves no traces behind (no reg entries, no entry in ARP panel ...)

This link explains it a bit:

https://msdn.microso...519(VS.85).aspx

Working this way is in fact not good practice but it seems to do the job.One of the pain points i think is that using this technique the patch will not update the productversion so you would have to find a different way to know which version is patched or not. The biggest advantage is that you can do (patch) anything you want.

 

Hope this helps a bit ...please let me know if you have more questions ...

 

Krgds

Berto

[deramor]

Thanks for your reply Berto. 

 

I can see why things can get complicated authoring full installs and hiding them from the system.  I would preffer a "real" patch since then MSI functions such as MsiEnumPatches can be used to track software.

 

In my spare time, I have been fooling around with both the Patch Design view and Quick Patch projects.  For the same installer, I get errors about sequencing from the patch design view when I build but nothing for Quick Patch projects.  I was curious why both would show different behavior since they both (according to documentation) are creating a pcp file and running it through Msimsp.exe with PATCHWIZ.DLL.  The error I got was: Since MSI 3.0 will block installation of major upgrade patches with sequencing information, creation of such patches is blocked.

 

This error promted my initial post.  I was curious if I was missing something in my normal application lifecycle that made patching not possible.  Did I make a design decision that causes this error or not.

 

Also in your reply you mentioned "...created some extra custom actions in my base msi that I only schedule to run during a patch if required"

What were the conditions you used to denote only running CAs during a patch process?  I ran across the property PATCH in the MSI docs.  Is this what you used?  Is this set in the original cached msi or the patch itself?

 

Regards,

Rob

[Berto]

I've never done a "Major Upgrade" patch ... not sure this is even possible or advisable.

 

What i mean is: suppose you already have released version v3.00.0001 of your product

If you create a quickpatch ... it's not supposed to bring e.g. version v3.00.0001 to v4.00.0001 ... because this would be a major upgrade itself.

A quick patch can however bring version v3.00.0001 to v3.59.0005 fine ... so when you enter the productversion for the QuickPach, make sure you do not change the digits before the first dot of the original product version.

 

About your second question: yes ... the PATCH property is triggering the custom actions during the QuickPatch

Also note that you can choose which custom actions of your cached msi need to run during the patch ... whether or not they have the PATCH condition ... you can even change the condition of these custom actions manually if you want. Pretty impressive.

 

 

Krgds

Berto

[deramor]

I've never done a "Major Upgrade" patch ... not sure this is even possible or advisable.

 

 

I guess this is really the heart of the matter.  However I am confused since you say you also produce Major Upgrades and are able to patch.

 

Did I say something in my previous post that pointed you to a different conclusion? 

 

My builds produce installers with updated ProductVersion, ProductCode, and PackageCode in every build. 

I have 2 Upgrade Items.

A prevent downgrade and a major upgrade item.  Settings on the upgrade are: Having the same upgrade code and any earlier version.

 

I suspect you are doing the same thing. 

 

I would prefer to use the patch design view to generate a patch since it appears to include files in a more automatice way than a QuickPatch.  Something in Installshield is performing a delta between 2 given installations and generates a patch from it.  The problem is that error message I mentioned before.

 

With your past statement about QuickPatches working well for you, I can accept this as a solution.  I have tested them breifly yesterday and found them to provide what I needed.  I just wanted to better understand the process so I can make more informed design decisions.

[Berto]

Sorry again for the confusion ... 

 

As you probably know the ProdutVersion format = major.minor.build (e.g. 01.00.0001).

Our Major releases are "Major Upgrades" and are relatively big. For the Major releases we make sure the major part is incremented (so 01.00.0001 to 02.00.0001). This is just the way we work. (In theory  any part of the productversion can be changed for a major upgrade to happen (if productcode & packagecode are changed also)).  

 

But ... if we want to create a QuickPatch, we never raise the major part! I think to recall that InstallShield will complain somehow or give a warning if you try to create a QuickPatch that increments the major part of the productversion. So i would advise to not created a QuickPatch that goes from 02.00.0001 to 03.00.0001 .... this is in fact what i meant by saying that we do not do a QuickPatch "Major Upgrade" ... i meant a "Major release" (which in our case is all about that major part in the productversion). If we create a QuickPatch we just make sure the minor part is incremented: e.g a patch for Major release 02.00.001 could have as producversion 02.15.0456.

 

So, if we just need a quick fix or small enhancement we create a QuickPatch that can target a specific Major release (again, multiple QuickPatches will be required to target multiple major releases ...).

 

About the "A prevent downgrade and a major upgrade item": yes, we too have these set.

 

I guess there's nothing wrong (afaik) with the Patch Design ... but it's just not working out for us (complex installer). The QuickPatch gave me an easier way to perform patching.

 

Let me know if you would have more questions.

[deramor]

Thanks Berto.  Sounds like we both have issues with the Patch Design view.  I am happy with using a Quick Patch project at this point.  The versions I would target would be something like 1.0.234 -> 1.0.235.  Basically a point single file replace for specific bug fixes.  I agree that using a patch to get to a future release is not the way to go.  I wouldn't expect a patch to be able to bring a product from 1.0 -> 1.1 or even 2.0. 

 

Are you aware of any functionality I gain or lose by using Quick Patch projects over the Patch Design?

I found this comparison: http://helpnet.insta...tchStrategy.htm

 

Looks like, in general, the patch design view allows for a greater and more serious changes to the layout and design of a release.  Conversly, a Quick Patch is more basic and focuses on updating existing files and registry entries.

 

Edit: after looking at the comparison in more detail, some functionality that is missing from Quick Patches we have done in the past and would likely need to do in the future.  Any ideas on what caused the previous error "Since MSI 3.0 will block installation of major upgrade patches with sequencing information, creation of such patches is blocked."

 

Edit2: I'm seeing a lot of forum posts about "Applying Major Upgrade as a patch" but that is not what I am trying to do.  Just to clarify, I want to generate a patch for a release.  The release just happens to be a Major Upgrade.

Edited by deramor, 28 September 2015 - 22:05.

[Berto]

According to the comparison chart the Patch Design allows more functionality than a QuickPatch. This was the initial reason i first wanted to opt for the Patch Design also. But I do not think at the time (±4 - 5 years ago) I got a the Patch Design to work once. There were always things going wrong.

 

You can also work around some of the extra functionality of the Patch Design with a QuickPatch ... some examples.:

• you can not add a new component to an existing or new feature with a QuickPatch: i have worked around this by adding new files to an existing component of an existing feature, and create a dedicated component later on in the next major upgrade release
   
• you can not edit an ini file with a QuickPatch: i have an InstallScript custom action that is taking care of updating the ini files ... this works fine with a QuickPatch
  Note: this custom action needs to exist in the major release that you will be patching
   
• I also created custom actions to run a batch file or an exe if i would need this during a QuickPatch. I just need to add the batch or exe as a new file to the QuickPatch and make sure the custom action gets set to run when applying the patch.
  Note: these custom actions needs to exist in the major release that you will be patching
   

So, if you're in the opportunity to still add some functionality (custom actions) to your basic msi that you could use during patching ... you can do a lot with a QuickPatch beside adding/removing files and registry keys (we're even updating XML files and some databases with the QuickPatch).

 

About "Since MSI 3.0 will block installation of major upgrade patches with sequencing information, creation of such patches is blocked."
Not 100% sure but I think this related to that major part of the product version.

(Maybe this helps a bit: http://blogs.msdn.co...22/454552.aspx)

Try building the QuickPatch by only changing the minor or build part of the productversion ... or disable "create patch sequencing entry" in the "advanced" tab of the "General Information" => Build Settings.

 

If i change the major part anyway when creating a QuickPatch, the log is saying:

ERROR: The patch being created has a minor update transform that changes the major product version field from 08.59.0003 to 09.99.0003. Minor updates that require patchwiz to generate sequencing information automatically should not change the major product version field

 

If i change the major part anyway but disable "sequencing": i get a dialog box saying:

A minor update patch is changing the major product version field. It is recommended that minor updates not change the major product version field; do you want to proceed anyway?

(fyi: the dialog just popped up and went away seconds later ... did not have the apportunity to press yes or no ... strange ...)

 

About: Edit2: I'm seeing a lot of forum posts about "Applying Major Upgrade as a patch" :

I understand what you mean ... we are doing exactly the same. I think that a "QuickPatch" that changes the major part of the productversion is considered as a "Major Upgrade Patch". So I would just try to avoid that.

 

Krgds

Berto

[deramor]

Thanks for your thoughts.  Your workarounds for added functionality are interesting.  They would allow me to perform most of what our previous patches had to do.  However I am trying to stay away from workarounds since most of our older products were installed with a lot of hacks.  I'm still undoing that mess so I don't want to potentially add to it if I can help it.

About the blog post you mentioned, It seems like he was talking about using a patch like a major update.  This is not what I am trying to do.

Heath explains that going from version 1.0.0 -> 2.0.0 should be performed by a major upgrade and not a patch.

What I am trying to do is go from 1.0.0 -> 1.0.1.

 

I tried to use the patch design again since I wanted to be sure I removed as much user error from the process as I could.

Long story short, I got it to work but with some caveats.

 

1. I needed to provide the new setup release settings with the previous package msi to fix an issue with dynamic files and new components.

Do you do this and if so, do you have any suggestions on how to do this in a process?

 

2. I was not able to disable custom actions like I was able to do so in a Quick Patch project.  Is there any way to get this functionality through the patch design view?  I suppose I could always add NOT PATCH to the conditions on the CAs I want to skip but that assumes I know ahead of time these should not be run.

[Berto]

About: What I am trying to do is go from 1.0.0 -> 1.0.1.

I know, and we're doing the same, like going from 1.0.0 -> 1.0.1 or going from 1.0.0 to 1.1.0 ... but never from 1.0.0 to 2.0.0.

The document from Heath is indeed about that last step. I just think that this is what they mean by a "Major Upgrade-patch" ... while we are just "patching a Major Upgrade" (which is something different). I was just trying to point out that (like Heath) we should stay away from making a patch that will go from 1.0.0 -> 2.0.0 ... since then you might see these error messages that you encountered (like you said:  "Since MSI 3.0 will block installation of major upgrade patches with sequencing information, creation of such patches is blocked.").

 

About your question 1 & 2:

I'm not really familiar with Patch Design so can't really help here (I just played around with it a couple of times ±5 years ago). 

I also try to stay away from using dynamic files.

 

Krgds

Berto

[deramor]

Thanks Berto.  The weird part about that error was that I was only trying to go from 1.0.x -> 1.0.x+1.  Anyway I thought it was my environment and I confirmed that since I cleaned things out and tried again.  The error went away.

 

I've been in contact with Installshield support over the Custom Action customizations.  Though quick patch projects allow you to enable/disable your CAs, this is not entirely obvious through patch design.  In order to implement this flexibility, one would only need to modify the original CAs before you build your "latest" package.  The modifications should get included in your patch created through Patch Design.  

 

Because of some of the limitations of quick patches, I'm going to give the Patch Design View a try.  Thanks for allowing me to use you as a sounding board for ideas. 

 

I hope to write up my process for internal use.  If I can make it publicly available I can post it here.

 

Regards

[deramor]

Now that I am actually trying to create a real patch, I am reading through my own documentation of my findings from October.  I am getting an error message :

Since MSI 3.0 will block installation of major upgrade patches with sequencing information, creation of such patches is blocked.

 

Keeping with the high level discussion of this thread, at a more basic level, how does everyone handle product updates?

 

My company generates a release 1.0 of a product.  When we generate release 1.1, it is a fully new package.  1.1 needs to remove 1.0 before it installs itself.  To accomplish this, I authored a major upgrade item.  This works fine.

 

When I try to create a patch with this major upgrade item part of the base version and also part of the new version, it generates the error above.

 

So I would like to know if anyone else has to support upgrading a product from release to release, uninstalling the previous version, and creating patches for this project.