Skip to content

platform sdk compatibility

Jump to bottom
Andre Lafleur edited this page Feb 3, 2026 · 3 revisions

About SDK compatibility

Understanding backward compatibility is essential for developing, deploying, and maintaining reliable integrations with Genetec Security Center. This guide clarifies foundational concepts, explains how versioning and compatibility interact in practice, and sets expectations for developers creating either external applications or internal integrations with the SDK.

Compiled version, runtime version, and Security Center version

There are three distinct versioning concepts that every developer must understand when working with the Security Center SDK.

The compiled version is the version of the SDK referenced by your integration at development time. This determines which APIs your code can use and what signatures are enforced at compile time.

The runtime version is the actual version of the SDK assemblies that are present and loaded when the integration is executed. This is the version installed on the server or workstation where your integration runs.

The Security Center version is the installed version of the Security Center platform, which ultimately determines the available SDK runtime and the set of supported features.

Application types and deployment scenarios

Integrations using the Security Center SDK fall into two categories: external integrations and internal integrations.

External applications are standalone programs, such as console applications, Windows Services, desktop clients (WPF or Windows Forms), or web applications (ASP.NET), that connect to Security Center as external clients.

These require the Security Center SDK to be installed on the server running the integration. The runtime SDK version used by these integrations is determined by the installed SDK assemblies, not by the version used at compile time.

Internal integrations refer to plugins (custom Roles) and workspace modules (Security Desk and Config Tool) that are deployed directly onto the Security Center server. These run within the same process as Security Center itself, using the exact SDK assemblies bundled with the installed Security Center version. There is no requirement to install a separate SDK for these integrations. Instead, internal integrations simply load against the runtime SDK provided by the Security Center environment.

Backward compatibility definition and scope

In the context of the Security Center SDK, backward compatibility refers strictly to the ability of a Security Center server to accept client connections from external applications using earlier runtime SDK versions. This feature only applies to the scenario where an external application is connecting to Security Center as a client. It is not relevant to plugins or workspace modules. Security Center typically allows backward compatibility for up to three major SDK runtime versions prior to the current system version, but this feature must be explicitly enabled in the Security Center Admin Console. If backward compatibility is not enabled, only clients using the exact same SDK version as the server will be allowed to connect.

External application example

Consider an external application that was compiled using SDK 5.8. The compatibility with a Security Center 5.13 server does not depend on the version used at compile time, but entirely on the SDK version available at runtime when the application is executed.

If the application is run with the 5.8 runtime SDK assemblies, Security Center 5.13 will recognize the application as a 5.8 client. Security Center 5.13 only supports client connections from runtime SDK versions up to three major releases prior, for example, 5.10 and later, if backward compatibility is enabled.

A client using the 5.8 runtime SDK will be refused. If you update the application’s environment so that it runs with SDK 5.13 assemblies, then the application, even though originally compiled with SDK 5.8, will connect as a 5.13 client.

As long as there are no breaking changes affecting the APIs used, the application will function correctly with Security Center 5.13. For external applications, it is always the runtime SDK version that determines compatibility, not the compile-time version.

Workspace module or plugin example

If a workspace module or plugin is compiled with version 5.8 and then deployed to a Security Center 5.13 system, it is loaded with the SDK assemblies provided by Security Center 5.13. As long as the APIs relied upon by the plugin or module remain present and unchanged in the newer SDK, the integration will run successfully. If there are breaking changes in the SDK, such as removed or modified methods or classes, the plugin or module may fail to load or produce runtime errors. This behavior is governed entirely by the .NET assembly binding model and is not subject to Security Center’s backward compatibility window, which applies only to external client connections.

Common questions

Do I need to recompile my external application every time Security Center is upgraded?
Not necessarily. If there are no breaking changes in the APIs your application uses and if the application is executed with a compatible runtime SDK version (within the backward compatibility window), it can continue to work. However, thorough testing after each Security Center upgrade is always recommended.

What determines if my external application can connect to Security Center?
Compatibility is determined by the runtime SDK version used when the application runs, not by the version of the SDK used to compile the application. Security Center checks the SDK version of the connecting client at runtime.

How do I check which runtime SDK version my application is using?
The runtime SDK version is determined by the SDK assemblies present on the machine where your application runs. You can inspect the file version of Genetec SDK DLLs in your application's bin directory or use reflection in your code to log the loaded assembly versions.

Does backward compatibility apply to plugins or workspace modules?
No. The backward compatibility feature in Security Center applies only to external applications that connect as clients. Plugins and workspace modules are loaded using the SDK assemblies provided by the Security Center installation and must be compatible with the version installed on the system.

What happens if there are breaking changes between SDK versions?
If your code relies on SDK methods, properties, or behaviors that have been removed or changed, your application or plugin may fail to load, throw runtime errors, or behave unexpectedly. Review SDK release notes and test your integrations thoroughly when upgrading.

How do I enable backward compatibility in Security Center?
Backward compatibility must be explicitly enabled by an administrator using the Security Center Admin Console. Only then will the server accept client connections from runtime SDKs up to three major versions behind the current system version.

Can I use the same plugin or workspace binary across different Security Center versions?
You can, as long as there are no breaking changes in the SDK APIs your code relies on. There is no enforced backward compatibility window for plugins or workspace modules, so testing on each target version is essential.

Can I copy the SDK DLLs with my application or integration?
No. Copying SDK DLLs with your application is not supported and may not work. You must install the official Security Center SDK on each target machine, use the provided environment variables and registry keys for resolution, and load the assemblies dynamically at runtime as described above.

What should I do after a Security Center upgrade to ensure my integrations still work? Confirm the runtime SDK versions, review the Security Center release notes for breaking changes, test all integration features, and, for external applications, ensure backward compatibility is enabled if you are using a supported older runtime SDK.

See also

Security Center SDK

  • Security Center SDK Developer Guide Overview of the SDK framework and how to build integrations with Security Center.

    • Platform SDK

      • Overview Introduction to the Platform SDK and core concepts.
      • Connecting to Security Center Step-by-step guide for connecting and authenticating with the SDK.
      • SDK Certificates Details certificates, licensing, and connection validation.
      • Referencing SDK Assemblies Best practices for referencing assemblies and resolving them at runtime.
      • SDK Compatibility Guide Understanding backward compatibility and versioning in the SDK.
      • Entity Guide Explains the core entity model, inheritance, and how to work with entities.
      • Entity Cache Guide Describes the engine's local entity cache and synchronization.
      • Transactions Covers batching operations for performance and consistency.
      • Events Subscribing to real-time system events.
      • Actions Sending actions to Security Center.
      • Security Desk Displaying content on monitors, reading tiles, sending tasks, and messaging operators.
      • Custom Events Defining, raising, and subscribing to custom events.
      • ReportManager Querying entities and activity data from Security Center.
      • ReportManager Query Reference Complete reference of query types, parameters, and response formats.
      • Privileges Checking, querying, and setting user privileges.
      • Partitions Entity organization and access control through partitions.
      • Logging How to configure logging, diagnostics, and debug methods.

    • Plugin SDK

    • Workspace SDK

    • Macro SDK

      • Overview How macros work, creating and configuring macro entities, automation, and monitoring.
      • Developer Guide Developing macro code with the UserMacro class and Security Center SDK.

Web SDK Developer Guide

  • Getting Started Setup, authentication, and basic configuration for the Web SDK.
  • Referencing Entities Entity discovery, search capabilities, and parameter formats.
  • Entity Operations CRUD operations, multi-value fields, and method execution.
  • About access control in the Web SDK Concepts, relationships, and common access-control operations.
  • About video in the Web SDK Concepts, relationships, configuration, and common video operations.
  • Users and user groups Creating users, managing group membership, and assigning privileges.
  • Partitions Managing partitions, entity membership, and user access control.
  • Custom Fields Creating, reading, writing, and filtering custom entity fields.
  • Custom Card Formats Managing custom credential card format definitions.
  • Actions Control operations for doors, cameras, macros, and notifications.
  • Events and Alarms Real-time event monitoring, alarm monitoring, and custom events.
  • Incidents Incident management, creation, and attachment handling.
  • Reports Activity reports, entity queries, and historical data retrieval.
  • Tasks Listing and executing saved report tasks.
  • Macros Monitoring currently running macros.
  • Custom Entity Types Listing, retrieving, and deleting custom entity type descriptors.
  • System Endpoints License usage, web tokens, and exception handling.
  • Performance Guide Optimization tips and best practices for efficient API usage.
  • Reference Entity GUIDs, EntityType enumeration, and EventType enumeration.
  • Under the Hood Technical architecture, query reflection, and SDK internals.
  • Troubleshooting Common error resolution and debugging techniques.

Media Gateway Developer Guide

Web Player Developer Guide

  • Developer Guide Complete guide to integrating GWP for live and playback video streaming.
  • API Reference Full API documentation with interfaces, methods, properties, and events.
  • Sample Application Comprehensive demo showcasing all GWP features with timeline and PTZ controls.
  • Multiplexing Sample Multi-camera grid demo using a shared WebSocket connection.

Clone this wiki locally