WiX service installer and custom install events

5
votes

I have an existing (C# based) windows service that is derived from the Installer class and I currently use the MS supplied, command line InstallUtil to install it and uninstall it. This works fine and as part of my system I have attached event handlers to the AfterUninstallEventHandler and CommittedEventHandler events. In my case I simply use them to log messages to a custom event log - showing the install and uninstall dates and times and program versions.

At the moment I am experimenting with Wix v3.5 Beta 1 to package up a bunch of my stuff including this service and I am using the Wix ServiceInstall and ServiceControl to replace what I manually did with InstallUtil.

However it seems that Wix uses a totally different mechanism to InstallUtil for installing services. This is seen in the name and description of the service being controlled by Wix (as opposed to what was embedded in the service program) and that my events no longer fire (which, if a different install mechanism is being used I doubt that they would).

So is it possible for Wix to perform a service installation in the same manner as InstallUtil or am I just going to put up with the differences?

Edit

Christopher has suggested factoring out the service related definitions from my code and moving them into the Wix installer project. This makes me uneasy as now I either have to find a way to share information between two separate systems (which I have no idea how to share between the code and Wix projects) or put up with defining the information in two separate locations (very bad software practice).

1
wixwindows-serviceswindows-installerinstallationwix3.5
Then have your installer store the name of the event source in a registry key or app.config and have your service read that value and use it to access the event log. I really don't see the "very bad software" practice. It's merely a contract between your service and the installer where the installer creates event source "x" and the service writes to "x". At the end of the day these are just registry entries that MSI handles well. The bad practice would be to have MSI do everything except this and then reinvent the wheel with out of process code. – Christopher Painter
One final thought: Let's pretend this was a winforms app that wrote to an eventlog. Let's say an administrator installed the MSI but never ran the program. Then a non-administrator started up the program. How would it have permissions to create the event sournce? However if the MSI created the event source it would be able to. – Christopher Painter
Ok .. stating the relationship between my installer and service as a contract was a helpful idea for me (and I agree with that) but it also helps me to solidify my the issue I have - which is that this is an informal contract which can't be enforced (how do you ensure that registry keys align between parties to the contract?). The InstallUtil method may be a horrible hack that is prone to failure, but it in my case it provides a more formal contract that can be enforced - albeit by default of the information only being defined in one location. But BTW I appreciate your comments and they help! – Peter M
Chris - point taken about the winforms app scenario. Obviously I have to invest more time in thinking more philosophically about what installation actually means. – Peter M
When we start talking about software integration, we are typically talking about contracts between software components from different groups and sometimes different vendors. I typically have participated in software integration teams with stakeholders from different domains. Framwork leads, product leads, softare engineers all working together to define these relationship and then formalize them into design documents to help make sure everyone is on the same page. I subscribe to the bullet proof install theory. It simply must never fail. Any additional considerations must be secondary. – Christopher Painter

1 Answers

3
votes

From a windows installer perspective, InstallUtil is an evil antipattern because it injects fragile out of process code into a declarative programming model. The Windows Installer has long had the ServiceInstall and ServiceControl tables and this works really well. The same applies to Regasm and Regserver. We prefer to extract the COM data and author it into the installer and have MSI take care of applying the registry value rather then loading assemblies and calling entry points in the hope that it works. When it fails, you have no idea why and you can't roll the state of the machine back.

What kind of stuff are you doing in your events? I would either eliminate and/or refactor each of them into something MSI can do for you. If it's still not enough, write a DTF custom action and schedule it between InstallServices and StartServices.