plugin sdk deployment

This guide describes how to deploy plugins (custom roles) and workspace modules (client-side extensions) in Genetec Security Center.

Understanding Plugin Registration

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 has been the standard approach since the beginning and continues to work in all Security Center versions, including 5.13+.

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	Yes	Must be "True" to enable loading
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 8 plugins	Full absolute path to the .NET Framework Client assembly for plugin discovery
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 8 plugins (5.12.2+)

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

Modern .NET 8 Plugin: (5.12.2+ 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 8 Plugin Deployment (Security Center 5.12.2+)

Starting with Security Center SDK 5.12.2, plugins can be built targeting .NET 8 for improved performance and modern framework features. .NET 8 plugins use a multi-project architecture to maintain compatibility with existing client applications.

.NET 8 Plugin Architecture

.NET 8 plugins require a split architecture because client applications do not support .NET 8:

• Server Module: Built for .NET 8 and runs in the GenetecPlugin.exe process
• Client Module: Must be built for .NET Framework 4.8.1 and run inside Config Tool and Security Desk applications
• Common Assembly: Multi-targets both frameworks for shared code and interfaces

Important: Config Tool continue to run on .NET Framework 4.8.1 and cannot load .NET 8 assemblies. This is why .NET 8 plugins require separate Client assemblies built for .NET Framework, even when using .NET 8.

Understanding the "Client" Assembly Concept

The term Client in .NET 8 plugin architecture refers to the Config Tool being the client application that lists server-side plugins. This assembly:

• Purpose: Enables plugin discovery of plugins built for .NET 8
• Contains: Plugin (with "empty" implementation) and PluginDescriptor class
• Framework: Must target .NET Framework 4.8.1
• Not a ClientModule: Despite the name, this assembly should not contain a custom Workspace Module class
• Discovery Only: Security Center uses this assembly to enumerate available plugin types without instantiating them

Key Point: The "Client" assembly exists solely for discovering .NET 8 server plugins.

Client Assembly Implementation Requirements

For .NET 8 plugins, the Client assembly must contain:

1. Plugin Descriptor Class: The class with [PluginProperty] attribute for plugin discovery
2. Database Support Interface: If your plugin supports database operations, the Client assembly must implement IPluginDatabaseSupport (even with empty methods) for Security Center to recognize database capabilities

.NET 8 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 and should be loaded in the .NET 8 runtime environment. The client assembly must still be built for .NET Framework 4.8.1 and is used exclusively for plugin discovery by Config Tool.

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 8 plugin DLL that runs in GenetecPlugin.exe
• Client: Points to the .NET Framework 4.8.1 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

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
• 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 8 Plugins)

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

What it does:

• Tells Security Center that only the server module is built for .NET 8
• Server module runs in .NET 8 runtime environment
• Client assembly still runs in .NET Framework 4.8.1 environment for plugin discovery

When to use:

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

Architecture Impact:

• Server module (.NET 8): Contains actual plugin logic and runs in GenetecPlugin.exe
• Client assembly (.NET Framework 4.8.1): 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

Frequently Asked 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.

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.

What's the difference between ClientModule and Client assembly in .NET 8 plugins? For .NET 8 plugins, ClientModule in configuration points to the Client assembly (not a traditional workspace module). This assembly is built for .NET Framework 4.8.1 and contains only plugin descriptors for Config Tool discovery. It doesn't run client-side functionality like workspace modules do.

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. The DLL must contain both plugin logic (inherits from Genetec.Sdk.Plugin.Plugin) and workspace logic (inherits from Genetec.Sdk.Workspace.Modules.Module). However, for .NET 8 plugins, you must use separate assemblies due to framework compatibility requirements.

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 8 and .NET Framework plugins? .NET 8 plugins offer better performance and modern language features but require a split architecture (server in .NET 8, client assembly in .NET Framework 4.8.1) because Config Tool and Security Desk can't load .NET 8 assemblies. The client assembly is used solely for plugin discovery by Config Tool.

Why is the .NET 8 client assembly called "Client"? The term "Client" refers to Config Tool being the client application that discovers server-side plugins. This assembly enables Config Tool to safely enumerate .NET 8 plugin types without loading .NET 8 runtime dependencies. It's not a traditional client-side workspace module.