This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Files not copied after a patch installation
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
‎Jun 16, 2013
02:08 PM
Files not copied after a patch installation
Hello,
I am facing a strange issue where the files are not copied after a patch installation.
Up until now, we were delivering updated versions of our product using .msi(major upgrades). However, now we want to ship our updates using .msp files.
There are around 5 files in 5 different components. Each of these files are unversioned and are the key files for the respective components.
Somewhere during the product lifecycle, someone introduced entries for these files in the RemoveFile table, so that the latest version of the files is always copied during the upgrade process. I am not sure as to why this was requiered, as the File hashing for unversioned files should have allowed upgrading of these files, without requiring an explicit removal(using RemoveFile table) and installation using the InstallFiles . This was done when the upgrades were delivered using msi files.
All was working.
Now , we have decided to release updates to our product using a msp(patch ) file. However, it's surprising that the files are not re-installed during apatch.
i.e the remove file table deletes these files and the InstallFiles standard action does not restore them. I would have expected these to be restored as they are they key files for the respective components and missing key files to be restored.
The windows installer log files indicates that the corresponding components are marked for installation.
I also see the following snipped in the log file:
Allowing installation of component: {199327E3-7FBE-4D9F-8DED-38DBDEDEEC03} even though a modified unversioned keyfile exists and file versioning rules would disable the component
Is it because windows installer detected that the existing file on the disk was modified and decided not to replace it-atleast thats what the log message indicates.However, the Removefiles action goes ahead and cleans it whereas the InstallFiles does not do anything as the decision not to install the file was already taken earlier on in the Execute sequence.
Could someone explain to me as to why this behavior?
Regards,
Kiran Hegde
I am facing a strange issue where the files are not copied after a patch installation.
Up until now, we were delivering updated versions of our product using .msi(major upgrades). However, now we want to ship our updates using .msp files.
There are around 5 files in 5 different components. Each of these files are unversioned and are the key files for the respective components.
Somewhere during the product lifecycle, someone introduced entries for these files in the RemoveFile table, so that the latest version of the files is always copied during the upgrade process. I am not sure as to why this was requiered, as the File hashing for unversioned files should have allowed upgrading of these files, without requiring an explicit removal(using RemoveFile table) and installation using the InstallFiles . This was done when the upgrades were delivered using msi files.
All was working.
Now , we have decided to release updates to our product using a msp(patch ) file. However, it's surprising that the files are not re-installed during apatch.
i.e the remove file table deletes these files and the InstallFiles standard action does not restore them. I would have expected these to be restored as they are they key files for the respective components and missing key files to be restored.
The windows installer log files indicates that the corresponding components are marked for installation.
I also see the following snipped in the log file:
Allowing installation of component: {199327E3-7FBE-4D9F-8DED-38DBDEDEEC03} even though a modified unversioned keyfile exists and file versioning rules would disable the component
Is it because windows installer detected that the existing file on the disk was modified and decided not to replace it-atleast thats what the log message indicates.However, the Removefiles action goes ahead and cleans it whereas the InstallFiles does not do anything as the decision not to install the file was already taken earlier on in the Execute sequence.
Could someone explain to me as to why this behavior?
Regards,
Kiran Hegde
(2) Replies
‎Jun 19, 2013
03:37 AM
Could someone comment on my question above?
Thanks,
Kiran Hegde
Thanks,
Kiran Hegde
‎Jun 19, 2013
08:19 AM
Another way to look at this issue is that a patch is just a repair after a transform (the patch information) is applied to the msi. So the implication is that your REPAIR functionality also has a problem that should be addressed. You might want to set the patch aside and test the REPAIR functionality for a similar change to a file that you would expect to be 'repaired', with a verbose log.
Also take a look at the MSIENFORCEUPGRADECOMPONENTRULES property.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa370093(v=vs.85).aspx
Also take a look at the MSIENFORCEUPGRADECOMPONENTRULES property.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa370093(v=vs.85).aspx