I was browsing InstallSite today when I noticed a link to InstallShield KB Q207265:
HOWTO: Implement an InstallScript Custom Action to Detect and Display Message About Whether a Directory Exists
I'm a little suprised by this article for several reasons. The first reason is that it suggests writing InstallScript custom actions for functionality that already exists in the Windows Installer. The AppSearch pattern ( InstallShield calls it System Search ) is more then capable of resolving if a directory exists by using the DrLocator table. Also you can easily create a modal dialog with a text control that displays exists / not exists messages based on the results of the first search.
Finally the article suggests scheduling the custom action in the execute sequence with a condition of REMOVE <> "ALL" to prevent execution during an uninstall. However, this means that the message will be displayed during a silent install since the CA is in the execute sequence and there is nothing that takes UILevel into consideration.
Overall I'm really surprised by the lack of quality in this article. I know InstallShield has some extremely talented and experienced experts such as Robert Dickau so I'm not sure where this article came from.
I'm not too surprised by this. I used to work for Wise. I'm not sure if IS is the same but most of our KB articles came out of the support department, where some employees were experts and others were not depending on how long they've worked with the technology and their skill level. In my early days, I made several poor deployment decisions including ones similar to this one. Still, I would hope they'd have some internal review process that would catch things like this before publishing these articles.
ReplyDeleteAs you stated, there is no need to use a custom action for this at all - but if you do at least use MsiProcessMessage. MessageBox calls in custom actions are a pet peeve of mine.
IMO, tools like InstallShield/Wise don't encourage good deployment practices. They are designed for ease-of-use which favors hiding the underlying Windows Installer technology to save the customer the hassle - which makes sense when you are trying to sell products because lets be honest, the learning curve on Windows Installer is not kind to newcomers.
WiX may be more difficult to work with in some instances but it's transparent and the design of the tool encourages (if not requires) a solid understanding of Windows Installer. I suppose a lot of it has to do with the community around WiX as well - there are many veteran deployment experts involved in the WiX community that push true best practices.
Thanks for your feedback, Chris. I've taken the liberty of updating the KB article to include the silent condition, and a note at the bottom on System Search. While I agree that following MS Best Practice is good, some of our customers also prefer the flexibility of using InstallScript code. We try to provide multiple approaches to please all of our customers.
ReplyDelete- Joshua LaMarche
Technical Support Manager
Flexera Software
Thanks Joshua.
ReplyDeleteGood points Mike. I just have a hard time letting things like this slide. We have a saying at my day job:
"Death by a thousand cuts."
You know... what's a little "poo" in the installer, right? And a little more and a little more.
Soon you have a monster. I fight so hard to prevent that even when I'm using InstallShield because at the end of the day it's not the tool, it's how you choose to use it.