tags:

views:

453

answers:

3

Even after a reboot, the service is still there, even though the executable file is gone. I'm using WIX version 3.0.5419.0

<Component Id="IdiomServer.exe" Guid="7a751e1e-5e9e-41d2-be60-dc905ab1ccad">
  <File Id="IdiomServer.exe" Source="$(var.IdiomServer.TargetDir)IdiomServer.exe" KeyPath="yes" />
  <ServiceInstall Id="IdiomServer_Service" Name="IdiomServer 4.0" Account="LocalSystem" Description="Idiom Repository Server" ErrorControl="normal" Start="auto" Type="ownProcess" Vital="yes" />
  <ServiceControl Id="IdiomServer_Service" Name="IdiomServer 4.0" Remove="uninstall" Stop="uninstall" Wait="yes" />
</Component>

Installing the Windows Service works fine. Uninstalling it appears to do nothing. Section of the log file from the uninstall:

MSI (s) (D8:5C) [09:43:58:033]: Doing action: StopServices
MSI (s) (D8:5C) [09:43:58:033]: Note: 1: 2205 2:  3: ActionText 
Action start 9:43:58: StopServices.
Action ended 9:43:58: StopServices. Return value 1.
MSI (s) (D8:5C) [09:43:58:033]: Doing action: DeleteServices
MSI (s) (D8:5C) [09:43:58:033]: Note: 1: 2205 2:  3: ActionText 
Action start 9:43:58: DeleteServices.
Action ended 9:43:58: DeleteServices. Return value 1.

Any help would be much appreciated.

+2  A: 

I have an almost identical installer that works fine. The only differences are that my ServiceControl element has a different Id to the ServiceInstall element, and a 'Start="install"' property too.

I suspect your problem is either the Id of the ServiceControl element, or you have a stray service hanging around.

Try the following:

  • Change the ServiceControl Id to "IdiomServer_ServiceControl"
  • Change the Name in both Service elements to "Foobar" and check if the Foobar service is both installed and uninstalled. If that works, you may just need to manually delete the stray IdiomServer entry with the "sc" command.
Martin
Close. The problem was not the IDs but the Component/@Guid. Once I changed that, uninstall works fine.The Guid for the service component apparently needs to be changed along with Product/@Id when creating a new version of the product.
Rupert Morrish
That is not true. Changing the Component/@Guid means all the resources contained in the Component must change as well. This is an MSI restriction commonly referred to as "Component Rules". You will see very bizarre upgrade and uninstall behavior when changing Component/@Guids.A verbose log file of the original uninstall should show why the ServiceControl did not delete your service.
Rob Mensching
See Rob's blog entry, http://robmensching.com/blog/posts/2003/10/18/Component-Rules-101, for a description of why changing the Component Id without changing the resources is a bad thing.
Martin
A: 

If changing the component guid worked, I'd suspect that the issue might relate to an erronous SharedDLL ref counter in the registry at : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDlls

These are legacy style reference counters that MSI can increment (if asked to) - and they will override the MSI's own reference counting. For some dumb reason Installshield increments the legacy ref count for all files (whether they are versioned or not), and this frequently makes for mysterious "stray files on uninstall" occurring on development pcs. The same can occur in Wix if you enable the shared dll ref count and in rare cases the ref count can get corrupted during major upgrades.

Glytzhkof