问题
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?
回答1:
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.- WiX service installation sample 1
- WiX service installation sample 2
2)
Win32 -CreateService
APIs.3)
Registry - manually update, generally an undesirable "under-the-hood" option.4)
WMI Classes -Win32_Service
. Major benefit: Scriptable. WrapsCreateService
(Win32).5)
InstallUtil.exe - .NET tool & installer classes.6)
MSI & Installer Class Custom Actions - callsInstallUtil.exe
via the shim dllInstallUtilLib.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:
- SC.exe - https://ss64.com/nt/sc.html
- Regsvcs.exe
- Powershell - New-Service, Set-Service, etc...
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
来源:https://stackoverflow.com/questions/61893174/wix-service-installer-overrides-service-installer-settings