plugin sdk assembly resolution

About plugin 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.

By default, when Security Center loads a plugin or workspace module, it does not probe the module's directory for these non-SDK assemblies, so the .NET runtime fails to load them.

For dependencies located in the same folder as your plugin or workspace module DLL, no code is required: set AddFoldersToAssemblyProbe to True in the module's registration. Security Center probes that folder and resolves a missing dependency only when a DLL there matches the exact assembly identity requested: its name, version, culture, and public key token. This covers most integrations, where each dependency is copied next to the module and its version matches what the module was built against. Because the match is exact, it does not resolve a dependency whose on-disk version differs from the one requested.

Register a custom assembly resolver when that exact-match probing does not fit, for example when a dependency's version differs from what the module references, when a dependency lives outside the module folder, or when certain assemblies must be excluded from probing. A custom resolver is your own code, so you control how it matches assemblies and where it looks for them. The AssemblyResolver sample probes the folder of the module that includes it and loads <name>.dll by name alone, without checking the version, and skips generated *.XmlSerializers assemblies. Register the resolver early in the plugin or module lifecycle, before any dependent types are referenced; a static constructor is the typical place, and calling the sample's Initialize() method there ensures the static constructor runs.

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.

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.

Common questions

Use these answers to resolve the most common assembly-resolution questions.

How do plugins and workspace modules load third-party or custom assemblies?

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 on those standard probing paths, so a dependency fails to load unless the module's folder is probed. The code-free way to enable that probing is to set AddFoldersToAssemblyProbe to True in the module's registration. Register a custom resolver only when its exact-version, same-folder matching does not fit, as described above.

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?

Place all non-SDK dependencies in the same directory as your plugin DLL (for role integrations) or workspace module DLL (for UI integrations). Both AddFoldersToAssemblyProbe and a custom resolver probe this location when resolving missing assemblies.

Where should I call a custom assembly resolver from?

When you use a custom resolver such as the AssemblyResolver sample, call its Initialize() method in a static constructor within your plugin class or workspace module class. This registers the resolver 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.

See also

• Plugin SDK overview: Plugin architecture, lifecycle, and components.
• Deploying plugins: Plugin packaging, registration, and deployment.
• Referencing SDK assemblies: Referencing SDK assemblies and runtime resolution.