简体   繁体   中英

WIX service installer overrides service Installer settings

i am working on a service that is later deployed by a WIX installer. this is service installer class

this.ServiceInstaller.DisplayName = "My Service";
            this.ServiceInstaller.ServiceName = "MyService";
            this.ServiceInstaller.ServicesDependedOn = new string[] {
        "ServiceA",
        "ServiceB",
        "ServiceC"};

and this is the WIX installer code

    <Component Id="MyService.exe" Guid="{1234}">
        <File Id="MyService.exe" KeyPath="yes" Source="$system\$(sys.BUILDARCH)\MyService.exe">
          <netfx:NativeImage Id="MyService.exe" Platform="all" Priority="1" />
        </File>
        <ServiceInstall Id="MyService.exe" DisplayName="My OTHER Service" Name="MyService" ErrorControl="normal" Start="auto" Type="ownProcess">
          <ServiceDependency Id="ServiceD" />
          <ServiceDependency Id="ServiceE" />
          <ServiceDependency Id="ServiceF" />
          <util:ServiceConfig FirstFailureActionType="restart" SecondFailureActionType="restart" ThirdFailureActionType="restart" RestartServiceDelayInSeconds="10" />
        </ServiceInstall>
        <ServiceControl Id="MyService.exe" Name="MyService" Stop="install" Remove="uninstall" />
    </Component>

as far as i can tell, the configuration in the WIX completely overrides the settings in the project installer. (specifically name and dependencies) is this a default behavior? whats the point of having a serviceInstaller class if WIX is going to completely ignore it?

Cross Linking : A couple of supporting answers: 1) Chris Painter on service credential preservation and / or handling , 2) Service debugging .


ServiceInstaller classes : This feature is generally meant to be used during development for testing purposes . You use the InstallUtil.exe .NET tool for installation and / or Visual Studio.


Prefer MSI : There are many ways to install services, but you should use the MSI tables ServiceInstall and ServiceControl if you can. Below are some further details on various more or less crazy options.


Service Registration Options : An old, classic document from Phil Wilson ( MSI MVP and author of "The Definitive Guide to Windows Installer" ) listed a number of ways to install services by means of:

  • 1) MSI - ServiceInstall , ServiceControl tables - and a few others.
  • 2) Win32 - CreateService APIs.
  • 3) Registry - manually update, generally an undesirable "under-the-hood" option.
  • 4) WMI Classes - Win32_Service . Major benefit: Scriptable . Wraps CreateService (Win32).
  • 5) InstallUtil.exe - .NET tool & installer classes.
  • 6) MSI & Installer Class Custom Actions - calls InstallUtil.exe via the shim dll InstallUtilLib.Dll in Visual Studio Setup Projects - not a favorite option of mine. A lot of complexity for no gain basically. Just use the service tables in the MSI. Automagic.

InstallUtil.exe : When .NET arrived, a tool called InstallUtil.exe was introduced together with a set of installer classes in the .NET framework. The ServiceInstaller framework class contains code to install Services, and the developer can override the class methods to provide extra install-time code. This provides a useful way for developers to easily install Services for testing purposes.


Many years later one could add to Phil's list:

More exotic: Srvany (run app as service, very outdated - don't use).


Windows Services Frequently Asked Questions (FAQ): https://www.coretechnologies.com/WindowsServices/FAQ.html

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM