This page provides WinSW installation guidelines for different cases.
In order to setup WinSW, you commonly need to perform the following steps:
winsw.exe from the distribution, and rename it to your taste (such as myapp.exe)myapp.xml(see XML Config File specification for more details)myapp.exe install <OPTIONS> in order to install the service wrapper.There are some details for each step available below.
You write the configuration file that defines your service. The example below is a primitive example being used in the Jenkins project:
<service>
<id>jenkins</id>
<name>Jenkins</name>
<description>This service runs Jenkins continuous integration system.</description>
<env name="JENKINS_HOME" value="%BASE%"/>
<executable>java</executable>
<arguments>-Xrs -Xmx256m -jar "%BASE%\jenkins.war" --httpPort=8080</arguments>
<logmode>rotate</logmode>
</service>
The full specification of the configuration file is available here.
You can then install the service like:
myapp.exe install <OPTIONS>
... and you can use the exit code from these processes to determine whether the operation was successful. Possible return error codes are described here. Beyond these error codes, all the non-zero exit code should be assumed as a failure.
The Installer can be also started with the /p option.
In such case it will prompt for an account name and password, which should be used as a service account.
Once the service is installed, you can start it from Windows Service Manager.
If you open Properties for the service, you can also configure how the service should be launched.
In particular, the following option can be set up:
In addition to the service manager, it is possible to make some additional configurations in the Windows Registry Editor.
Once the start button is clicked, Windows will start myapp.exe,
then myapp.exe will launch the executable specified in the configuration file (Java in this case).
If this process dies, myapp.exe will exit itself, and the service will be considered stopped.
Newer versions of Windows (confirmed on Windows Server 2012, possibly with Windows 8, too) do not ship with .NET runtime 2.0, which is what winsw.exe is built against.
This is because unlike Java, where a newer runtime can host apps developed against earlier runtime, .NET apps need version specific runtimes.
One way to deal with this is to ensure that .NET 2.0 runtime is installed through your installer, but another way is to declare that winsw.exe can be hosted on .NET 4.0 runtime by creating an app config file winsw.exe.config.
<configuration>
<startup>
<supportedRuntime version="v2.0.50727" />
<supportedRuntime version="v4.0" />
</startup>
</configuration>
The way the runtime finds this file is by naming convention, so don't forget to rename a file based on your actual executable name (e.g. myapp.exe).
See this post for more about this.
None of the other flags are needed.
To work with UAC-enabled Windows, winsw ships with a digital signature. This causes Windows to automatically verify this digital signature when the application is launched (see more discussions). This adds some delay to the launch of the service, and more importantly, it prevents winsw from running in a server that has no internet connection. This is because a part of the signature verification involves checking certificate revocation list.
To prevent this problem, create myapp.exe.config in the same directory as myapp.exe (renamed winsw.exe) and put the following in it:
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
See KB 936707 for more details.