13 replies to this topic

[rflum]

 I have an installation that installs 3 applications, with attendant dlls, ocxs, data files and help files.  I am trying to write a patch that upgrades a couple of executables and adds about 20 new files.
 I have had no success with this at all.  It doesn't upgrade the existing files and it doesn't add the new ones.  I have tried to set the REINSTALL=<existing features>, REINSTALLMODE=vomus and ADDLOCAL=<new features> props to accomplish this in a custom action that runs just after LaunchConditions, in the Next button on the Patch Welcome screen, and in the command line to msiexec.
Each of those methods failed to accomplish the patch.
 I have followed all the recommendations in the MSI help and in Krueger's upgrade rules.
 I know that there are a lot of you out there who have managed to do this.  What are the problems you encountered and how did you solve them?  What are the key rules to follow in the project that you are trying to patch?  Are the steps given in the MSI help inadequate / non-exhaustive?  Is there a good book or paper out there that addresses this?
 Please take the time to respond - this is driving me crazy.  It shouldn't be this hard.
 Thanks, Rob

[rflum]

I had a partial breakthrough last night - I was reading the "Preparing Packages for Patching" IS help article, and found this:
"don't select “Create installation launcher (Setup.exe)" in the Advanced Settings panel." in the File Compression section of the article.
 This is the first place I've read this.  I tried building the uncompressed patch package without a setup.exe, and then creating a patch with an update.exe, and this morning when I ran it, I was able to upgrade the existing file.
However, it won't add the new file, of course, because REINSTALL=ALL is passed in by update.exe!
 So I built a patch without an update.exe, and ran it with
> msiexec /p test.msp REINSTALL=<existing feature> ADDLOCAL=<new feature> REINSTALLMODE=vomus
 I was astounded when this didn't update the existing file OR add the new file!
 In both cases the cached package was run, which also surprised me.
 Now I'm really confused.....

[templebl]

If the cached package runs that means your package code is the same.
You are supposed to be able to add a Feature in a Minor Update without changing the Product Code. But try changing the Product Code and see what that gives you.  
Replacing files should go fine as long as the Component Codes don't change.  
If you add  a Component to an existing Feature, you need to change the Product Code (Major Upgrade).  

[rflum]

Hi, Temple,
 I change the package code every time I make a code change, no matter how minor, so there must be something else that controls which package runs.
 I have changed the Product Code, and then everything works, but I don't want to release that way, because the changes I'm making don't constitute a major upgrade.
 I have changed no component codes, nor key files.  The files and registry entries I'm adding are all in a new top-level feature.  I'm making no changes to the existing feature/component structure.  That's what's so frustrating about this - I'm not doing anything complicated.
 Thanks for your help!

[JustAFarmboy]

I've had several problems with patching.  I've finally been able to get it to work.  Here's what I do to create a patch, keep in mind that all installations I create are uncompressed:

1) Copy the MSI into a new directory with the update files.
2) Change the PackageCode.
3) Change the version number, usually just the build    number
4) Create a new sub-feature
5) Create new components for the files that I am adding
6) Add the new components to the new sub-feature
7) I set the sub-feature to "Favor Parent"

When I didn't create the new sub-feature to contain the new files, it didn't work.  Also, any versioned file must not have the same version or the WI won't update the files.  The Created and Modified dates are used when comparing non-versioned files.

I would like to to add another problem that I am having with patching.  Whenever I apply a patch, any files that were in the original but not in the new version aren't deleted when the patch is applied.  Any solutions to that problem would be appreciated.

By the way, I use Wise for Windows Installer for creating MSI files, so updating the files in the MSI is a matter of copying and saving.

[rflum]

Hey, FarmBoy,
 Why do you set the sub-features to "Favor Parent" ?
Oh, do you create the subfeature under an existing feature?
 I am doing all the same steps you are except for #7,
and the reason I don't do that is because my new feature is a top-level feature.
Any comments?
 Thanks, Rob

[JustAFarmboy]

To create a sub-feature just create a feature within another, or you can set the Feature_Parent to the name of the parent feature in the Feature table.

AS for favoring the parent, I'm not sure what attributes to use, I use Wise for Windows Installer so there is a drop-down box with that as an option.

[rjtonnis]

>>I would like to to add another problem that I am having with patching.  Whenever I apply a patch, any files that were in the original but not in the new version aren't deleted when the patch is applied.  Any solutions to that problem would be appreciated.

Do you delete the components for the files you wish to delete?  If you are not removing the component WI will not remove any files associated with the component.

[Stefan Krueger]

If you remove a file from a component, you have to add it to the RemoveFile table.

[micand]

Hi!

I´d like to join this discussion since I´m working on my first testpatch (to get the hang of it).

I ´ve successfully added a file to a existing component and it got installed. I´ve also put the new file in a separate component and got that to work. What I´m trying to do now is to remove a file. I tried just removing the file from the original component, but the file didn´t get removed. I then created a new component (Removed_Files). That didn´t do it. I saw Stefan´s remark about adding an entry to the RemoveFile table. That didn´t work either!

What am I doing wrong!?

The entry in the RemoveFile table looks like this:
FileKey = File1
Component_ = Global_Remove_Files
Filename = File1*
DirProperty = [INSTALLDIR]
InstallMode = 3

The file I want to remove is named File1.txt and is in [INSTALLDIR].

When I check the log it just says:
Action start 15:50:21: RemoveFiles.
Action ended 15:50:21: RemoveFiles. Return value 1.

Any help would be appreciated!

//Mike

[Stefan Krueger]

First of all, don't put INSTALLDIR in square brackets here.

If that was not enough to fix it, try File1.* or File1.txt instead of File1*

Since Global_Remove_Files is a new component I assume you have either placed it in a new feature and used ADDLOCAL to install this feature, or you are using the MSI 2.0 runtime files. But why not use the component that included the file previously?

[micand]

Thanks!

I found out about that the Directory was wrong when I ran a validation and then when I read your answer I changed to INSTALLDIR without square brackets. The file got deleted like it was supposed to!

About the the new component Global_Remove_Files I haven´t placed it in a new feature, but it works anyway. I just checked and sure enough I´m running 2.00.2600.0 (XP) runtime. I tried it on a 1.20 and it didn´t work. I then did as you said and removed the new component and changed the RemoveFile table to reflect the change. Having done that, everything now works great!

Thanks a bunch!

//Mike

[rflum]

Hey, Mike,
 Since you're working on a test application, would you please send me the project and tell me what steps you're going through to create the patch?
 It would be a lot faster than me asking a lot of questions.
   Rob

[Philip]

If you're using ISWI2.01 or earlier, you have to "correct" an action in the PatchWelcome dialog and compile new setup package before using the patch wizard.

PRB: Patch Does Not Install the New Feature/Files if Project is Upgraded From Old Version of InstallShield Professional – Windows Installer Edition