views:

54

answers:

1

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).

A: 

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.

Christopher Painter
I understand what you are saying but I don't have the background to vilify InstallUtil in that manner. However what I have not come to grips with is the effect of your proposed solution. If I create a custom method, now Wix *and* my Service have to know the name of my dedicated event log - and I can't picture how to export a name from my server code into a Wix expression so I would need to define the name in 2 places .. bad code .. bad code! This is a generic issue I have with Wix (and I suppose msi) projects. In the short term I could write to a standard event log name like application.
Peter M
I've been doing installs for 14 years- 7 of those years were MSI. Google my name and you'll see my body of work - I am an expert and I InstallUtil sucks.Trust me, MSI is a huge step forward from script based instalers and MSI's pattern was around before DevDiv went off and reinvented the wheel. MSI also has to support unmanaged services which existed long before the CLR.If the only thing your doing in your code is creating eventlogs, that's easy to do in WiX. http://stackoverflow.com/questions/58538/how-do-you-create-an-event-log-source-using-wix
Christopher Painter
If you build your installer and look at the MSI in ORCA you'll see this is just some syntactic sugar the registry keys/values used to define the event log and source.BTW I don't see having WiX and your service knowing the eventlog name as a SoC concern. It's the installers job to install your application and it's your applications job to run not install your application.
Christopher Painter
Whether we are talking registry xeys, odbc names, environment variables whatever integration work has long meant brining the two domains together. If anything having your application install the eventlog is an SoC problem as it gets difficult to troubleshoot which actor is causing an installation problem.
Christopher Painter