6c0f6d1f7a
* First configuration stub * Get rid of the old winsw_cert.pfx references, adjust docs * Fix the corrupted log4net reference, we use 2.0.3 * Generate stub SNK file * Signing: Try full SDK path to generate SNKs * Fix the path * Signing: Sign all assemblies being packed into WinSW * Tests: Try enabling tests * Tests and artifacts: Use absolute paths * Artifact path must be relative * The test DLL is the NUnit one * nunit-console does not require loggers * NUnit: Try picking all DLLs in the output folder * NUnit console: No wildcards * Tests: Fix the test project to make it properly working with the new project structure * Docs: Clarify the specifics of external extension usage * Add AppVeyor badge to README.md
1.7 KiB
WinSW extensions
Starting from WinSW 2.0, the wrapper provides an internal extension engine and several extensions.
These extensions allow to alter the behavior of the Windows service in order to setup the required service environment.
Available extensions
- Shared Directory Mapper - Allows mapping shared drives before starting the executable
- Runaway Process Killer - Termination of processes started by the previous runs of WinSW
Developer guide
In WinSW 2.x the extension does not support inclusion of external extension DLLs.
Adding external extensions
The only way to create an external extension is to create a new extension DLL and
then to merge this DLL into the executable using tools like ILMerge.
See the example in src/Core/ServiceWrapper/winsw.csproj.
Generic extension creation guideline:
- Extension DLL should reference the
WinSWCorelibrary. - The extension should extend the
AbstractWinSWExtensionclass. - The extension then can override event handlers offered by the upper class.
- The extension should implement the configuration parsing from the
XmlNode. - The extension should support disabling from the configuration file.
WinSW engine will automatically locate your extension using the class name in the XML Configuration File.
See configuration samples provided for the extensions in the core.
For extensions from external DLLs, the className field should also specify the assembly name.
It can be done via fully qualified class name or just by the ${CLASS_NAME}, ${ASSEMBLY_NAME} declaration.
Please note that in the current versions of WinSW 2.x the binary compatibility of extension APIs is not guaranteed.