I'd like to discuss people's experiences with building Basic MSI installers and steps that need to be taken to make sure future patches work 100% of the time on deployed sites.
Things like:
- Dynamic file linking. Should you avoid using dynamic file linking if you plan on producing/deploying minor upgrades in the future?
- Custom Actions. Can CA's be 'fixed' by a minor upgrade/patch should you happen to deploy a new installation package with a broken CA.
- What type of CA is best to use? VBScript? MSI Dll? I generally use VBScript, but was reading a blog that stated that use of VBScript CAs can unpredictable if the target systems have anti-virus configured to block script execution. Certain objects such as the FileSystemObject may not work. If I use an MSI DLL instead, will changes to the DLL (i.e fixed actions or new actions) be available when a patch is being applied to an installed site?
- New components. When adding a new component can it be added to an existing feature that has already beed installed on the target system or should it be placed in a sub-feature using the 'Favor Parent' setting? Should the 'Re-evaluate condition' be set to YES.
Is expecting 100% success with patches unrealistic with MSI?
Currently I'm getting around 94% success rate on our installed sites. The recent failures have been due to Error 2709 - Component is not found in the component table. Makes no sense seeing the the previous patch worked fine and the same component it is complaining about was in the previous patch.
Any input gratefully appreciated.
-Shawn
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Planning ahead for patches
Started by
smc0862
, Oct 20 2010 13:18
4 replies to this topic
jcarlos10
-
- Full Members
- 13 posts
Posted 20 October 2010 - 20:50
Shawn,
These are my two cents:
-Dynamic File Linking. We had a lot of trouble using DFL and performing minor upgrades (Using InstallShield 12). The behavior got quite unpredictable. We even got to a point where our product became uninstallable after applying a minor upgrade. Pointing to the previous MSI when building your release should help avoid problems. I understand that newer versions of InstallShield handle DFL in a much better way and internally follow better practices for handling key files. I haven't tried them yet, so I cannot tell you for sure.
-Custom Actions. I have been able to replace custom actions and change their conditions by applying a patch as long as the original doesn't interrupt the installer. But you have to be very careful with this, because if your broken CA doesn't allow the upgrade to finish, the new MSI will not be recached. A very respected install developer told me once that "if the install is already out in the wild you are pretty much out of luck", and I think he's right, so it's better to make sure your installer is bulletproof right from the beginning.
-Type of CA. I am convinced that there are much better options than VBScript, and have stopped using VBScript for a while. Right now what I use is C# via DTF. The development is much more robust and personally I think it's a better experience to program in C# than in VBScript. More information on why not to use VBScript is here.
For the other topics you ask, I'm sure that more experienced developers can provide some information.
Regards,
Juan C. Becerra
These are my two cents:
-Dynamic File Linking. We had a lot of trouble using DFL and performing minor upgrades (Using InstallShield 12). The behavior got quite unpredictable. We even got to a point where our product became uninstallable after applying a minor upgrade. Pointing to the previous MSI when building your release should help avoid problems. I understand that newer versions of InstallShield handle DFL in a much better way and internally follow better practices for handling key files. I haven't tried them yet, so I cannot tell you for sure.
-Custom Actions. I have been able to replace custom actions and change their conditions by applying a patch as long as the original doesn't interrupt the installer. But you have to be very careful with this, because if your broken CA doesn't allow the upgrade to finish, the new MSI will not be recached. A very respected install developer told me once that "if the install is already out in the wild you are pretty much out of luck", and I think he's right, so it's better to make sure your installer is bulletproof right from the beginning.
-Type of CA. I am convinced that there are much better options than VBScript, and have stopped using VBScript for a while. Right now what I use is C# via DTF. The development is much more robust and personally I think it's a better experience to program in C# than in VBScript. More information on why not to use VBScript is here.
For the other topics you ask, I'm sure that more experienced developers can provide some information.
Regards,
Juan C. Becerra
smc0862
-
- Full Members
- 54 posts
Posted 21 October 2010 - 11:30
Juan,
Thanks for your input and the links to the those blogs. Some very good information contained in them. I agree that the packages needs to be fully tested and our QA staff do a good job, but it difficult to test for every situation. As one of the blogs stated, "we are dealing with hostile environments". Every system is potentially different.
I typically use VBScript due to their ease of use and I generally do not have problems with them, but after reading the potential problems with anti-virus, I will probably change my strategy here.
-Shawn
Thanks for your input and the links to the those blogs. Some very good information contained in them. I agree that the packages needs to be fully tested and our QA staff do a good job, but it difficult to test for every situation. As one of the blogs stated, "we are dealing with hostile environments". Every system is potentially different.
I typically use VBScript due to their ease of use and I generally do not have problems with them, but after reading the potential problems with anti-virus, I will probably change my strategy here.
-Shawn
jcarlos10
-
- Full Members
- 13 posts
Posted 21 October 2010 - 17:48
Shawn,
The documentation for installing our products have a note that reads: "Please disable any anti-virus program before running the installation program".
I think this was added after some clients complained that the installations were failing with no apparent reason.
Regards,
Juan Carlos
The documentation for installing our products have a note that reads: "Please disable any anti-virus program before running the installation program".
I think this was added after some clients complained that the installations were failing with no apparent reason.
Regards,
Juan Carlos
smc0862
-
- Full Members
- 54 posts
Posted 22 October 2010 - 16:56
Juan,
We have a systems group here that actually installs our software onto servers that we then install into our customer sites. So the anti-virus, although a concern, should not impact us too much. But if we hand out the software for customers to install, having a note such as yours is a good idea.
The issue that I'm faced with now is that our latest patch is failing on several of our customers systems with an error 2709 (component not found in component table). The odd thing is that the previous patch worked fine which contained the component in question.
SP4 did not have the component.
SP5 contained the component and it was added as a sub-feature favoring the parent. Customers sites patched fine up to SP5.
SP5a was a small patch containing a fixed version of this component. Out of 140 SP5 sites that were pacthed, 7 sites threw the 2709 error.
This is what prompted my original post. The not knowing why this error is being thrown on a few systems and not all of them. Is it the patch? Is it the target system? Can it be fixed to prevent future patches from failing the same way? It's frustrating as hell!!! Plenty of google hits on error 2709, but none with resolutions.
Thanks for your input...
-Shawn
We have a systems group here that actually installs our software onto servers that we then install into our customer sites. So the anti-virus, although a concern, should not impact us too much. But if we hand out the software for customers to install, having a note such as yours is a good idea.
The issue that I'm faced with now is that our latest patch is failing on several of our customers systems with an error 2709 (component not found in component table). The odd thing is that the previous patch worked fine which contained the component in question.
SP4 did not have the component.
SP5 contained the component and it was added as a sub-feature favoring the parent. Customers sites patched fine up to SP5.
SP5a was a small patch containing a fixed version of this component. Out of 140 SP5 sites that were pacthed, 7 sites threw the 2709 error.
This is what prompted my original post. The not knowing why this error is being thrown on a few systems and not all of them. Is it the patch? Is it the target system? Can it be fixed to prevent future patches from failing the same way? It's frustrating as hell!!! Plenty of google hits on error 2709, but none with resolutions.
Thanks for your input...
-Shawn