plugin sdk deployment

About plugin deployment

Deploying a plugin involves copying your plugin files to the deployment location and registering the plugin with Security Center so it knows where to find them.

This guide covers the registration methods available in different Security Center versions.

What is plugin registration?

For Security Center to load your custom plugin or workspace module, it needs to know:

• Where to find the DLL files
• Whether it's a server-side plugin, client-side workspace module, or both

Security Center supports two registration methods:

1. Windows Registry (5.12 and earlier, but also supported in 5.13+ for backward compatibility)
2. XML Configuration Files (5.13+ only)

Plugin vs workspace module

Before diving into registration methods, it's important to understand what you're deploying:

Plugin (Server-side):

• Custom server-side role that performs background tasks, integrations, or logic execution
• Requires a ServerModule DLL
• Optionally includes a ClientModule DLL for configuration in Config Tool

Workspace Module (Client-side):

• Purely client-side extension with no backend logic
• Runs only inside Security Desk or Config Tool
• Requires a ClientModule DLL

Combined Plugin:

• Single DLL that contains both server and client logic
• Uses the same DLL path for both ServerModule and ClientModule
• Simplifies deployment but requires the DLL to contain both types of logic

Method 1: Windows registry registration (5.12 and older versions, 5.13+ with automatic migration to XML configuration file)

The Windows Registry method is supported in all Security Center versions for backward compatibility with existing deployments.

Starting with Security Center 5.13, XML configuration files are the recommended method for new plugin deployments. See Method 2: XML Configuration Files.

Registry Locations

Plugin information is stored in the Windows Registry under:

Primary location (64-bit):

HKEY_LOCAL_MACHINE\SOFTWARE\Genetec\Security Center\Plugins\

Compatibility location (32-bit):

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Genetec\Security Center\Plugins\

Each plugin gets its own subkey under these locations.

Registry Values

Name	Type	Required	Description
Enabled	REG_SZ or REG_DWORD	Yes	"True"/"1" to enable, "False"/"0" to disable (case-insensitive)
ServerModule	REG_SZ	For plugins	Full absolute path to the server DLL
ClientModule	REG_SZ	For workspace modules	Full absolute path to the client DLL
Client	REG_SZ	For .NET plugins	Full absolute path to the .NET Framework Client assembly (allows Config Tool to list the plugin)
AddFoldersToAssemblyProbe	REG_SZ or REG_DWORD	Optional	Set to "True" if DLL has dependencies in same folder
NetCore	REG_SZ or REG_DWORD	Optional	Set to "True" for .NET plugins (5.13+)

.NET plugin registration (5.13+)

.NET plugins require two additional configuration keys: Client and NetCore.

NetCore: Set to True to indicate the ServerModule targets .NET rather than .NET Framework.

Client: Points to a .NET Framework 4.8 assembly used for plugin discovery in Config Tool.

When you add a plugin role in Config Tool, it scans registered assemblies to find classes with the [PluginProperty] attribute. Because Config Tool runs on .NET Framework 4.8, it cannot load .NET assemblies. The Client assembly provides a .NET Framework-compatible stub that Config Tool can load to discover your plugin, while the actual plugin logic runs in the .NET ServerModule.

For the complete architecture explanation, see Plugin components in the .NET plugin guide.

Registry Examples

Basic Plugin Example:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Genetec\Security Center\Plugins\MyPlugin

Values:
Enabled = True
ServerModule = C:\Program Files\Genetec\Plugins\MyPlugin\MyPlugin.dll
AddFoldersToAssemblyProbe = True

Workspace Module Example:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Genetec\Security Center\Plugins\MyWorkspaceModule

Values:
Enabled = True
ClientModule = C:\Program Files\Genetec\Plugins\MyModule\MyModule.dll
AddFoldersToAssemblyProbe = True

Combined Plugin (Single DLL):

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Genetec\Security Center\Plugins\MyUnifiedPlugin

Values:
Enabled = True
ServerModule = C:\Program Files\Genetec\Plugins\MyPlugin\MyPlugin.dll
ClientModule = C:\Program Files\Genetec\Plugins\MyPlugin\MyPlugin.dll
AddFoldersToAssemblyProbe = True

.NET Plugin: (5.13+ only)

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Genetec\Security Center\Plugins\MyModernPlugin

Values:
Enabled = True
ServerModule = C:\Program Files\Genetec\Plugins\MyPlugin\MyPlugin.Server.dll
Client = C:\Program Files\Genetec\Plugins\MyPlugin\MyPlugin.Client.dll
NetCore = True
AddFoldersToAssemblyProbe = True

Method 2: XML configuration files (Security Center 5.13+)

Starting with Security Center 5.13, you can register plugins using XML configuration files instead of the Windows Registry. This method offers several advantages:

• No administrative access required for registry modification
• Cross-platform compatibility - works on Linux systems
• File monitoring - Security Center automatically detects changes

XML file locations

The directory location depends on your Security Center version:

Version	Directory
5.13.0 to 5.13.2	C:\ProgramData\Genetec Security Center\PluginInstallations\Plugins\
5.13.3 and later	C:\Program Files (x86)\Common Files\Genetec System\PluginInstallations\Plugins\

XML file naming

• Each file must end with .Plugin.xml
• The prefix is arbitrary and doesn't affect plugin identity
• Examples: MyPlugin.Plugin.xml, CustomReport.Plugin.xml

XML configuration format

All plugins and workspace modules use the same XML structure:

<PluginInstallation>
  <Version>1</Version>
  <Configuration>
    <Item Key="Enabled" Value="True" />
    <Item Key="ServerModule" Value="C:\Path\To\Server.dll" />
    <Item Key="ClientModule" Value="C:\Path\To\Client.dll" />
    <Item Key="Client" Value="C:\Path\To\ClientAssembly.dll" />
    <Item Key="AddFoldersToAssemblyProbe" Value="True" />
    <Item Key="NetCore" Value="True" />
  </Configuration>
</PluginInstallation>

XML configuration examples

Basic Plugin:

<PluginInstallation>
  <Version>1</Version>
  <Configuration>
    <Item Key="Enabled" Value="True" />
    <Item Key="ServerModule" Value="C:\Program Files\Genetec\Plugins\MyPlugin\MyPlugin.dll" />
    <Item Key="AddFoldersToAssemblyProbe" Value="True" />
  </Configuration>
</PluginInstallation>

Workspace Module:

<PluginInstallation>
  <Version>1</Version>
  <Configuration>
    <Item Key="Enabled" Value="True" />
    <Item Key="ClientModule" Value="C:\Program Files\Genetec\Plugins\MyModule\MyModule.dll" />
    <Item Key="AddFoldersToAssemblyProbe" Value="True" />
  </Configuration>
</PluginInstallation>

Combined Plugin (Single DLL):

<PluginInstallation>
  <Version>1</Version>
  <Configuration>
    <Item Key="Enabled" Value="True" />
    <Item Key="ServerModule" Value="C:\Program Files\Genetec\Plugins\MyPlugin\MyPlugin.dll" />
    <Item Key="ClientModule" Value="C:\Program Files\Genetec\Plugins\MyPlugin\MyPlugin.dll" />
    <Item Key="AddFoldersToAssemblyProbe" Value="True" />
  </Configuration>
</PluginInstallation>

.NET plugin deployment (Security Center 5.13+)

Starting with Security Center 5.13, plugins can target .NET 8 or later. Because Config Tool runs on .NET Framework 4.8 and cannot load .NET assemblies, these plugins require a separate Client assembly for Config Tool to list the plugin.

For details on building .NET plugins, see Building .NET plugins.

.NET Configuration

XML Configuration:

<PluginInstallation>
  <Version>1</Version>
  <Configuration>
    <Item Key="Enabled" Value="True" />
    <Item Key="ServerModule" Value="C:\Program Files\Genetec\Plugins\MyPlugin\MyPlugin.Server.dll" />
    <Item Key="Client" Value="C:\Program Files\Genetec\Plugins\MyPlugin\MyPlugin.Client.dll" />
    <Item Key="NetCore" Value="True" />
    <Item Key="AddFoldersToAssemblyProbe" Value="True" />
  </Configuration>
</PluginInstallation>

The NetCore key with value True tells Security Center that only the server module is built for .NET 8 or later and should be loaded in the .NET runtime environment. The client assembly must still be built for .NET Framework 4.8 so Config Tool can list the plugin when adding a new plugin role.

Registry Configuration:

Key: HKEY_LOCAL_MACHINE\SOFTWARE\Genetec\Security Center\Plugins\MyNetCorePlugin

Values:
Enabled = True
ServerModule = C:\Program Files\Genetec\Plugins\MyPlugin\MyPlugin.Server.dll
Client = C:\Program Files\Genetec\Plugins\MyPlugin\MyPlugin.Client.dll
NetCore = True
AddFoldersToAssemblyProbe = True

Configuration Key Clarification:

• ServerModule: Points to the .NET plugin DLL that runs in GenetecPlugin.exe
• Client: Points to the .NET Framework 4.8 assembly used for discovery by Config Tool (not a traditional client module)

Registry to XML migration (5.13+ automatic behavior)

If you're using Security Center 5.13 or later, you don't need to worry about choosing between registry and XML methods. Here's how the automatic migration works:

Automatic migration process

1. On Startup: Security Center scans both registry locations and creates XML files for any registry entries that don't already have corresponding XML files

2. Runtime Monitoring: The registry is monitored during runtime - new registry entries automatically trigger XML file creation

3. XML Takes Precedence: Once an XML file exists, it becomes the authoritative source and registry changes are ignored

4. Bidirectional Sync: Deleting an XML file also deletes the corresponding registry entry to prevent automatic recreation

What this means for you

• Existing deployments continue working - your registry entries are automatically migrated
• You can use either method - registry entries will become XML files automatically
• XML files are the source of truth - once created, they take precedence over registry
• Deployment scripts can use both methods for maximum compatibility

Deployment Recommendations

For new projects (5.13+)

Recommended approach: Use XML files directly

• Create XML files in the appropriate directory for your Security Center version
• No registry access required
• Better security and maintainability

For cross-version compatibility

Recommended approach: Deploy both methods simultaneously

1. Create registry entries (works on all versions)
2. Create XML files (for 5.13+ optimization)
3. Let Security Center handle the migration automatically

Benefits:

• Works on all Security Center versions
• Registry provides backup if XML files are accidentally deleted
• No version detection logic needed in deployment scripts
• Automatic migration handles the transition

For legacy systems (pre-5.13)

Required approach: Registry only

• Only the Windows Registry method is supported
• Administrative access required for registry modification

Deployment workflow for .NET plugins

Follow these steps to deploy a .NET plugin:

1. Build the solution in Release configuration
2. Create a deployment folder (for example, C:\Program Files\Genetec\Plugins\MyPlugin\)
3. Copy the ServerModule output:
   • All files from MyPlugin.ServerModule\bin\Release\net8.0-windows\
   • Include your plugin assemblies and third-party dependencies
4. Copy the Client assembly:
   • MyPlugin.Client.dll from MyPlugin.Client\bin\Release\net481\
   • Place in the same folder or a subfolder
5. Copy the ClientModule (if applicable):
   • MyPlugin.ClientModule.dll from MyPlugin.ClientModule\bin\Release\net481\
6. Register the plugin using XML or registry (see examples above)
7. Restart Genetec Server to load the new plugin

Warning

Never include Genetec SDK assemblies (Genetec.Sdk.dll, Genetec.Sdk.Plugin.dll, etc.) in your deployment folder. Security Center provides these assemblies at runtime. Including copies causes version conflicts and unpredictable behavior. Ensure your project references use <Private>False</Private> to prevent SDK assemblies from being copied to the output folder.

Example deployment folder structure:

C:\Program Files\Genetec\Plugins\MyPlugin\
├── MyPlugin.ServerModule.dll         # .NET server module
├── MyPlugin.Client.dll               # .NET Framework client stub
├── MyPlugin.ClientModule.dll         # .NET Framework workspace module (optional)
└── [third-party dependencies only]

Configuration Options

AddFoldersToAssemblyProbe

Set AddFoldersToAssemblyProbe to True if your plugin depends on additional DLLs located in the same folder as your main plugin DLL.

When needed:

• Your plugin uses third-party libraries
• Your plugin has custom dependencies not in the GAC
• Your DLLs are not in the standard application directories

What it does:

• Instructs .NET to search the plugin's directory for dependencies
• All dependency DLLs must be in the same directory as the plugin DLL (not in subfolders)
• Only searches the immediate folder (not recursive)
• Required for most plugins with external dependencies

If omitted:

• Dependencies will only be resolved from application base directory and GAC
• Plugin will fail to load if dependencies can't be found
• Failure is silent - no error messages in the UI

NetCore flag (.NET plugins)

The NetCore flag is only needed for .NET plugins (Security Center 5.13+):

What it does:

• Tells Security Center that only the server module is built for .NET 8 or later
• Server module runs in .NET runtime environment
• Client assembly still runs in .NET Framework 4.8 environment so Config Tool can list it

When to use:

• Your server module targets .NET 8 or later
• Your client assembly targets .NET Framework 4.8 (required for Config Tool discovery)
• You want .NET performance and features server-side

Architecture Impact:

• Server module (.NET): Contains actual plugin logic and runs in GenetecPlugin.exe
• Client assembly (.NET Framework 4.8): Contains only plugin descriptors for Config Tool discovery

Verification and Troubleshooting

How to verify plugin registration

For Plugins:

1. Open Config Tool
2. Navigate to the Plugins task
3. Click Add an entity > Plugin
4. Your plugin should appear in the available types list

For Workspace Modules:

1. Open Config Tool or Security Desk
2. Go to Help > About > Installed Components
3. Your client module DLL should be listed

Common issues and solutions

Plugin not appearing in Config Tool:

• Check that ServerModule path points to a valid DLL
• Verify plugin class has [PluginProperty] attribute
• Ensure plugin class has a public parameterless constructor
• Check that Enabled is set to "True"

Workspace module not loading:

• Verify ClientModule path points to a valid DLL
• Check Installed Components list in About dialog

Dependencies not loading:

• Set AddFoldersToAssemblyProbe to True
• Verify all dependency DLLs are in the same folder as the main DLL
• Consider using a custom assembly resolver for complex scenarios

Silent failures:

• Enable logging for troubleshooting:
  • Genetec.Platform.Common.Core.PluginInstaller
  • Genetec.Platform.Common.PluginInstaller
  • Genetec.Plugin.Role.Services.PluginLoaderService
  • Genetec.Reflection.PluginsProvider

Plugin Removal

Complete removal process

To completely uninstall a plugin or workspace module:

1. Delete XML file (if exists):

   • 5.13.0-5.13.2: C:\ProgramData\Genetec Security Center\PluginInstallations\Plugins\
   • 5.13.3+: C:\Program Files (x86)\Common Files\Genetec System\PluginInstallations\Plugins\

2. Delete registry entries from both locations:

   • HKEY_LOCAL_MACHINE\SOFTWARE\Genetec\Security Center\Plugins
   • HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Genetec\Security Center\Plugins

3. Remove plugin DLLs from all referenced locations

Important removal notes

For 5.13+ systems:

• XML files take precedence - plugin will continue loading if only the registry is deleted
• Deleting XML files also deletes corresponding registry entries automatically
• If you delete only the XML file while Security Center is offline, but leave the registry entry, the XML file will be recreated on startup

For pre-5.13 systems:

• Only need to delete registry entries and DLLs
• No automatic recreation behavior

Common questions

Do I need to restart Security Center after modifying an XML file? No. Security Center continuously monitors the XML folder and automatically detects changes within seconds. Only restart if you need to overwrite a DLL that's currently in use.

Can I use relative paths in configuration? No. Always use full absolute paths for both ServerModule and ClientModule. Relative paths will not be resolved. However, environment variable paths like %ProgramFiles%\Genetec\Plugins\MyPlugin.dll are supported.

What happens if a DLL path is invalid? The system silently skips loading that component. Server and client components load independently; if one fails, the other can still succeed.

Can one DLL be used for both server and client? Yes, for .NET Framework plugins. Use the same DLL path for both ServerModule and ClientModule. For .NET plugins, you must use separate assemblies. See Building .NET plugins for details.

How does registry migration work in 5.13+? When Security Center starts, it automatically scans registry locations and creates XML files for any entries that don't have corresponding XML files. The registry is also monitored during runtime for new entries.

What's the difference between .NET and .NET Framework plugins? .NET plugins (targeting .NET 8 or later) require a Client assembly built for .NET Framework 4.8 so Config Tool can list the plugin. See Building .NET plugins for architecture details.

See also

• Plugin SDK overview: Plugin architecture, lifecycle, and components.
• About plugin certificates: SDK certificate file naming and discovery for plugins.
• About plugin assembly resolution: Resolving non-SDK assemblies that the plugin depends on.
• Plugin SDK lifecycle: Plugin initialization, startup, and disposal phases.