Folder Structure

General Information

Each plugin is installed in its own folder within the Plugins folder (V4+). One folder — one plugin. Inside the folder, there must be at least two files — the plugin’s dll file and its manifest Manifest.xml (V6+, see note on V4/V5). In addition to these, the plugin folder and its subfolders may contain additional libraries, configuration files, resources, and so on.

The SyrveFront application retrieves all plugin information from the Manifest.xml file.

The SyrveFront API contract files (Resto.Front.Api.Vx.dll, Resto.Front.Api.Vx.xml) are only needed during the development and compilation of the plugin and should not be distributed or installed with the plugin; at runtime, contracts from the SyrveFront application folder will be used. When referencing contracts in the project via a direct link to the dll file, Copy Local = False should be specified. When connecting a NuGet package via PackageReference for versions prior to V7Preview2, centering must be disabled using <PrivateAssets>all</PrivateAssets> (description), starting from V7Preview2, centering is disabled automatically.

Structure of the Manifest.xml File

Required Parameters

• FileName — string, the name of the dll file with the plugin (without the path, just the file name with the extension). A file with this name must be located next to Manifest.xml. Case may or may not matter depending on the file system used, so it should be assumed that in general case, case is important and the file name in the manifest should be specified with case sensitivity.
• TypeName — string, the name of the plugin class inside the dll file FileName (full name, including namespace). Case sensitive.
• ApiVersion — string, the version of the API used by the plugin (V4/V5/V6Preview4/V6/…). Case sensitive. The specified version must match the version of the implemented interface IFrontPlugin.
• LicenseModuleId — 32-bit signed integer, the identifier of the license module. This number must match the value specified in the attribute PluginLicenseModuleId.

Additional Parameters

• IsSingleInstance — true/false, whether to run the plugin as a single instance within the terminal group. By default, false, meaning the plugin will run on each terminal where it is installed. This flag can be used to restrict the plugin to run only on one terminal, which can be convenient if multiple instances of the plugin should not process the same data. For example, if the plugin monitors order changes and sends them to an external server, one instance of the plugin is sufficient. Considering the synchronization of orders between terminals within the group, instances of such a plugin running in parallel on different terminals would see the same orders and duplicate calls to the external server, sending the same data. Corresponds to the attribute SingleInstancePlugin from versions prior to V5.
• RestartOnCrash — true/false, whether to restart the plugin after a crash. By default, true, meaning the crashed plugin will be restarted. A plugin is considered crashed if its host process exits with a non-zero return code. The following restrictions are set:
  • If this setting is absent in the manifest, the plugin will be restarted only if it crashed after running for at least 10 seconds. This is necessary to avoid restarting plugins that perform a series of checks upon startup and shut down through intentional crashes when conditions for operation are not met. To properly shut down the plugin, the method PluginContext.Shutdown() should be called, but in fact, many plugins are implemented incorrectly. The default behavior may change in the future. If the manifest explicitly states that a restart is required, the minimum runtime restriction before crashing will not apply.
  • In case of hopelessly broken plugins, there is a limit — no more than four crashes per hour. If the plugin crashes for the fifth time within an hour, it will be deemed hopeless and will no longer be restarted in this session of the SyrveFront application.

Legacy Version for V4/V5

When releasing API versions up to and including V5, an old variant was used — several dll files (the plugin itself and its dependencies) ended up in the plugin folder, and the SyrveFront application scanned all these dll files for a class implementing the marker interface IFrontPlugin and read additional parameters from the attributes of the found class. This approach had several drawbacks, and starting from V6, it was replaced by the manifest variant. If for V6 the manifest is mandatory, then for previously released API versions (V4/V5), both variants will be supported: in the absence of a manifest, dll files will be scanned in the old way, and if the Manifest.xml file is present, the data will be read from it. The manifest variant is more reliable and faster than scanning dll files, so it is recommended to add this optional file even for plugins on V4/V5.

However, plugins on V4/V5 must continue to adhere to the contract and still specify attributes for scanning even when using a manifest. Since support for manifests was added to the SyrveFront application starting from version 6.4, previously released versions of the application will always scan dll files regardless of the presence of a manifest.

Examples

<?xml version="1.0" encoding="utf-8" ?>
<Manifest xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3.org/2001/XMLSchema ../Binaries/Syrve/Manifest.xsd">
  <FileName>Resto.Front.Api.SamplePlugin.dll</FileName>
  <TypeName>Resto.Front.Api.SamplePlugin.SamplePlugin</TypeName>
  <ApiVersion>V6</ApiVersion>
  <LicenseModuleId>21005108</LicenseModuleId>
</Manifest>

This example, as well as the xml file schema Manifest.xsd, can be viewed in the SyrveFront API SDK.