Sometimes I need to have LaunchConditions based on the installation/execution state of a service. For example a customer might require that a package only be installable if indexing service or IIS is running.
Unfortunatly, despite 8 years of development, Windows Installer *STILL* does not have extensions to the AppSearch pattern to facilitate this type of checks. It's a shame because the table extensions ( ServiceLocator ) would be really easy to implement without hurting existing installs. So basically we are forced to write `Evil` Custom Actions....... Ok, now that my overview rant is done, let's get onto something interesting:
Recently a thread on InstallShield Community got my attention. sks2004 and rguggisberg were noting that the InstallScript function ServiceExistsService() wasn't working on Vista without elevation while the SC QUERY command was working without elevation.
Upon examination I suspected and confirmed that the ServiceExistsService function was calling the OpenSCManager API function and requesting too many privledges. While I didn't have access to InstallScripts source code, I did have access to an ancient service wrapper from the InstallScript 5 days located over on InstallSite.
Sure enough, inside the source I could see the SCM initialization functions generically requesting the SC_MANAGER_ALL_ACCESS rights. The call would fail and the service would go undetected. Finally BryanWolf ( Macrovision Dev ) stepped in and confirmed the bug and advised that WO IOC-000059857 has been created. Until the issue is addressed, the work around is to request administrator elevation for the client side UI sequence or run the CA in defferred with system context. If neither of those are acceptable, I posted a modifed version of the InstallScript code on the forums.
So my two take away points are:
1) Vista Security changes continues to manifest itself in obsecure ways. You might think your doing a read-only operation but the underlying stack asks for more.
2) I really, really, really wish Windows Installer would provide support for more use cases via the standard actions. Yes I know custom actions are more evil then standard actions.... but they are completly unavoidable when the standard actions won't support the use cases that your PAYING customers require.
I've run into this problem using MSI custom actions.
ReplyDeleteMSI really is a horror story. Sparse and poorly assembled documentation, obscure logging, and then theres Orca(ick). If you need to anything complex it fails you immediately requiring you to write bootstrappers, chainers and custom actions...and rebundle your frankenstein monstrosity. It really only handles the simple things adequately... but then why not just use a self extracting zip or the nullsoft.
WiX is the only thing I've encountered that makes it useable.
Until you have to try and install/uninstall/upgrade your package that is...