plugin sdk assembly resolution

Plugins and workspace modules often rely on additional assemblies beyond the official Genetec SDK libraries. These include third-party libraries or custom-built dependencies that are not part of the Security Center installation.

However, when Security Center loads a plugin or workspace module, it does not automatically scan the module’s directory for these non-SDK assemblies. The .NET runtime will fail to load them unless explicit resolution logic is in place. This is because Security Center does not configure private probing paths for each plugin or module and does not load assemblies unless they are found in predefined locations or manually resolved.

To solve this, you must register an assembly resolver that intercepts load failures and locates the required DLLs manually. The resolver looks for the missing assemblies in the same directory as the plugin or workspace module and loads them dynamically.

If your module depends on such libraries, you must ensure that the resolver is registered early in the module or plugin lifecycle, before any of the dependent types are referenced. A static constructor is typically used to register the resolver class when the plugin or module is first loaded.

Genetec provides a sample implementation of an assembly resolver here:

https://github.com/Genetec/DAP/blob/main/Samples/Shared/AssemblyResolver.cs

Important Note for Workspace Modules

Security Desk and Config Tool load all workspace modules into the same process. This means all modules share the same AppDomain, and only one version of a given assembly can be loaded. If multiple modules depend on the same DLL but use different versions, this can result in type mismatches or runtime failures. Plugins, on the other hand, each run in a dedicated process and do not share dependencies.

Workspace developers must therefore align versions of shared libraries across all deployed modules to avoid conflicts. There is no isolation at the module level for external dependencies.

Certainly. Here is a concise and professional FAQ section tailored for senior developers working with Genetec Security Center plugins and workspace modules that need to resolve non-SDK assemblies dynamically:

---

Frequently Asked Questions (FAQ)

Why is an assembly resolver required for plugins or workspace modules? By default, the .NET runtime resolves assemblies using the application base directory and the Global Assembly Cache (GAC). Genetec plugins and workspace modules are loaded dynamically by Security Center, and their dependencies are not located in standard probing paths. If your integration relies on third-party or custom assemblies, you must register a custom resolver to guide the runtime to the correct location. Without it, the assembly load will fail at runtime.

Does this apply to Genetec SDK assemblies as well? No. The Genetec.Sdk.*.dll assemblies are provided and loaded automatically by Security Center. You must not attempt to load or override them manually. This guidance applies only to additional assemblies your module depends on.

Where should I place my third-party or custom assemblies? You should place all non-SDK dependencies in the same directory as your plugin DLL (for Role integrations) or workspace module DLL (for UI integrations). Your assembly resolver should probe this location when resolving missing assemblies.

Where should I call the assembly resolver from? Call AssemblyResolver.Initialize() in a static constructor within your plugin class or workspace module class. This ensures the resolver is registered before any dependent assemblies are loaded by the runtime.

Can I just copy my assemblies into the Security Center installation folder? No. That directory is managed by the Genetec installer and must never be modified. Files placed there may be deleted or replaced during upgrades, and doing so may result in an unsupported configuration.

What happens if multiple workspace modules depend on different versions of the same assembly? All workspace modules are loaded into the same process and AppDomain (Security Desk or Config Tool). The .NET runtime allows only a single version of a given assembly to be loaded per AppDomain. If multiple modules reference different versions, the first one loaded wins. This may lead to runtime exceptions in others. You must coordinate versioning to prevent conflicts.

Is there a way to isolate workspace modules from each other? No. Workspace modules run in a shared process with a shared AppDomain. There is no mechanism for isolation. Avoiding conflicts requires coordination at build and versioning time.