We are trying to release a product upgrade, but cannot build the installation as a patch because the customer may be upgrading from different original builds. The installer therefore has to overwrite existing files, but it is not doing this reliably.
The installation appears to complete properly but, on closer inspection, some files are not being replaced. Exactly which files are not overwritten varies varies from machine to machine. The only way we have found to ensure that the new file is installed is to delete the old file first -- but there are more than 2,000 files being installed, so it's not even vaguely practical to do that.
If we cannot find a solution to this then we will have to move to a different installer because, as is, it is unworkable.
Please help.
Installer not over-writing some files
Not supported by the Windows Installer
I wish you could do this as well, but it is my understanding that it is a limitation of the Windows Installer itself and not IA, so using a different installer won't do you much good.
You can use the API to delete files or Delete Files Recursively.
It is also possible that your app is running when the update is being ran, so you might want to terminate it from memory before running the update. I have beeing doing that with good results.
You can use the API to delete files or Delete Files Recursively.
It is also possible that your app is running when the update is being ran, so you might want to terminate it from memory before running the update. I have beeing doing that with good results.
-
Bob T Bunny
- Posts: 30
- Joined: Wed Jul 04, 2007 9:21 pm
Without wanting be critical of InstallAware, InstallShield has been able to set an "always overwrite" flag on files for a couple of versions now. It may not be a function that is built into Windows Installer, but they have found a way to do it.
Hopefully InstallAware can do something similar. Maybe set an option on the properties of the file, which automatically calls that delete api you mentioned, just before installing the file?
One thing IS can't do is set the Always Overwrite flag for "linked folders" (all files in a folder), you have to set it on each file individually, so if IA can do this first it would be a winner!
Bob
Hopefully InstallAware can do something similar. Maybe set an option on the properties of the file, which automatically calls that delete api you mentioned, just before installing the file?
One thing IS can't do is set the Always Overwrite flag for "linked folders" (all files in a folder), you have to set it on each file individually, so if IA can do this first it would be a winner!
Bob
I like that idea
That's a good one.
Another thing I like about InstallShield is the rock solid COM registration. I posted hints at this for IA updates. My last install project, I had to use both, InstallShield for COM and IA for the UI stuff.
...also need a better copy file feature.
If IA can pull off that, can't see much reason to ever pull InstallShield off the shelf again.
There's some non-Windows Installer based installation systems out there, that will pull it off, have strong scripting capabilities and work well on Vista, but the downside is no Vista Certification. I think from a customers point of view, they would prefer Vista certified installs that work.
Another thing I like about InstallShield is the rock solid COM registration. I posted hints at this for IA updates. My last install project, I had to use both, InstallShield for COM and IA for the UI stuff.
...also need a better copy file feature.
If IA can pull off that, can't see much reason to ever pull InstallShield off the shelf again.
There's some non-Windows Installer based installation systems out there, that will pull it off, have strong scripting capabilities and work well on Vista, but the downside is no Vista Certification. I think from a customers point of view, they would prefer Vista certified installs that work.
-
Mark Fulford
- Posts: 25
- Joined: Tue May 23, 2006 2:22 pm
IMO, the inability to force an overwrite is a big limitation that makes IA unusable for some types of setup. It forces us to another installer.
Considering that the replacement files have a newer date and version, I don't buy it being a limitation of the Windows installer. However, even if pre-deleting the files is the only answer...
Rather than me maintaining a hand-coded list of 2,500 files to be deleted before being installed, InstallAware could automatically do the same thing from a single line of script or checkbox on a dialog box.
Considering that the replacement files have a newer date and version, I don't buy it being a limitation of the Windows installer. However, even if pre-deleting the files is the only answer...
Rather than me maintaining a hand-coded list of 2,500 files to be deleted before being installed, InstallAware could automatically do the same thing from a single line of script or checkbox on a dialog box.
Wildcards
Yo can delete files using wildcards. Are they that different? If the replacements are inconsistant from box to box, I tend to think that some of the files are in use and that is why they are not being replaced. InstallShield will not replace in-use files without a reboot.
-
Mark Fulford
- Posts: 25
- Joined: Tue May 23, 2006 2:22 pm
-
MichaelNesmith
- Posts: 3452
- Joined: Thu Dec 22, 2005 7:17 pm
- Contact:
A Windows Installer tool can NOT forcibly overwrite files, because this is simply not provided for by MSI technology. Any solution that overwrites files forcibly involves a custom action of sorts, the equivalent of which in InstallAware is Delete Files Recursive.
You can read MSI documentation to see what MSI's file overwrite policies are like. It first checks file versions, and if that is not available, checks file dates. If your new files have newer dates, MSI should overwrite. If that is not happening, log the setup and see why MSI is skipping the files to overwrite.
You can read MSI documentation to see what MSI's file overwrite policies are like. It first checks file versions, and if that is not available, checks file dates. If your new files have newer dates, MSI should overwrite. If that is not happening, log the setup and see why MSI is skipping the files to overwrite.
Michael Nesmith
Install[b]Aware[/b]
[i]Home of The Next Generation MSI Installer[/i]
Get your free copy today - http://www.installaware.com/
Install[b]Aware[/b]
[i]Home of The Next Generation MSI Installer[/i]
Get your free copy today - http://www.installaware.com/
-
Mark Fulford
- Posts: 25
- Joined: Tue May 23, 2006 2:22 pm
Michael, I appreciate that MSI has limitations. However, InstallAware knows what files are being installed and, through a new command, would be capable of deleting files before installation.
The solution shouldn't be for me to hand-code the hundreds of files to be deleted (remembering to manually change these across versions). InstallAware could have a new function to delete existing files before installation. This function would, in effect, build exactly the same delete-list that you're asking me to manually create.
Recursive delete is only useful if you want to delete all files of a particular type.
The solution shouldn't be for me to hand-code the hundreds of files to be deleted (remembering to manually change these across versions). InstallAware could have a new function to delete existing files before installation. This function would, in effect, build exactly the same delete-list that you're asking me to manually create.
Recursive delete is only useful if you want to delete all files of a particular type.
Force File Replacement
Doesn't seem to me on the surface that it would be too hard to add an option to force the replacement of a file. Seems like you could just add an API to to delete file first in the background. Not sure how it would actually handle in-use files.
On the other hand, what I'm not sure about is why wildcards will not work for multiple files. seems like there would be some similarities you could specify.
I was also thinking that it would not be too hard to code a routine to write IA pasteble code from just the selection of files from a list box. I do have to say that I have done updates without using the patch selection and have had a 100 percent success rate by terminating any running instance of my app and then deleting the files myself before installing the new ones, and these have been DLL's and OCX's mainly.
The other scenario would be to code the installer so that it requires uninstalling the previous install first and this way the new files are insured to be installed properly.
As Michael said I have had no problems at all replacing files (No delete used) that have a newer file date and if they are not in use logging of the install would be the first step I would use to see what's up.
Obviously InstallShield is missing somthing or you wouldn't of tried IA.
On the other hand, what I'm not sure about is why wildcards will not work for multiple files. seems like there would be some similarities you could specify.
I was also thinking that it would not be too hard to code a routine to write IA pasteble code from just the selection of files from a list box. I do have to say that I have done updates without using the patch selection and have had a 100 percent success rate by terminating any running instance of my app and then deleting the files myself before installing the new ones, and these have been DLL's and OCX's mainly.
The other scenario would be to code the installer so that it requires uninstalling the previous install first and this way the new files are insured to be installed properly.
As Michael said I have had no problems at all replacing files (No delete used) that have a newer file date and if they are not in use logging of the install would be the first step I would use to see what's up.
Obviously InstallShield is missing somthing or you wouldn't of tried IA.
...
Use recursive delete as it is executed right away...or create a pre-req to handle the really bad ones.
I have found some consistancy to this problem. For me it is always the same files I have had problems with...just haven't really nailed what that difference is, except maybe the revision code/date and not the actual file date with version being the same. Very problematic with non-executables/dlls.
I have found some consistancy to this problem. For me it is always the same files I have had problems with...just haven't really nailed what that difference is, except maybe the revision code/date and not the actual file date with version being the same. Very problematic with non-executables/dlls.