Skills

How do Skills work?

A Skill is a versioned, named group of API functions and notifications. Skills serve two purposes:

• Declaration of intent: When a Module connects to an AOP App, the connection handshake includes the list of Skills the Module declares to use or provide. WinGuard uses this to verify compatibility and assign the appropriate access rights.
• Version contract: Each Skill carries a version number. This allows WinGuard to check whether the connecting Module’s expected Skill version is compatible with the installed WinGuard version.

WinGuard publishes a set of Skills that Modules can consume (e.g., ext.adapter, ext.common, wg, wg.app). In turn, WinGuard expects certain Modules to provide specific Skills (e.g., adapter for device adapters).

→ See Skills Reference for the full list.

Which Skills must my Module implement and support?

It depends on the Module type:

For device adapters the adapter Skill is mandatory. It covers the EXT Object and Activity API that WinGuard uses to query and operate connected devices.

Optional Module-provided Skills (implement if the functionality applies):

WinGuard-provided Skills your Module can consume:

This overview is intentionally not exhaustive. The exact and complete Skill list depends on your Module type and WinGuard version.

→ See Skills Reference and Extension Services for complete details.

What is the difference between <Compatibility>/<Skill> and <Skills>/<Skill> in the Manifest?

These two sections serve opposite directions:

<Compatibility> declares which Skills (and minimum versions) the host system (WinGuard) must provide for this Module to work. Use it to list every WinGuard-provided Skill your Module consumes, together with the minimum version you require:

<Compatibility>
  <X5 version="8.5.1.0"/>
  <Skill name="ext.adapter" version="0.1.10"/>
  <Skill name="ext.common" version="0.0.0"/>
</Compatibility>

The consumable WinGuard Skills are listed at WinGuard Skills.

When multiple versions of a Skill are listed, WinGuard picks the highest version it is itself compatible with. If WinGuard cannot satisfy the declared requirement, it will refuse to start the Module.

<Skills> declares which Skills this Module itself implements and exposes to other consumers. For a device adapter this is typically the adapter Skill:

<Skills>
  <Skill name="adapter" version="0.1.1"/>
</Skills>

The implementable Module Skills are listed at Module Skills.

A Skill version is not only an API contract for functions. It can also govern which XML elements and attributes are valid in the Module’s XML definitions. For example, the Activity type call was introduced with adapter version 0.1.1 and ext.adapter version 0.1.1. Using call activities therefore requires both Skills to be declared at >= 0.1.1.

What happens if the declared version is wrong?

If you declare a Skill version that WinGuard does not support, WinGuard will refuse to start the Module.

If you declare a version lower than what you actually use (e.g., you use a feature that only exists in version 2 but declare version 1), the Module is buggy. WinGuard may refuse to start it (e.g., due to XML validation errors), or it may start but behave incorrectly: throwing exceptions on API calls, misbehaving with certain WinGuard versions, or failing intermittently.

How does a Module implement a Skill?

For device adapters using the .NET SST SDK, the SDK implements the required AOP functions automatically. You declare the Skill in the Manifest, and the SDK takes care of the rest. No additional method implementations are required.

For Modules using the general .NET AOP SDK, Skills are implemented via the ServiceProvider mechanism.

What is the <X5> entry in <Compatibility>, and when should I use it instead of <Skill>?

<X5 version="..."/> in the <Compatibility> section declares the minimum WinGuard X5 version the Module requires. WinGuard will refuse to start the Module if its own version is lower than the declared value.

Advancis recommends using <Skill> entries instead of <X5> for most compatibility declarations, because Skill-based compatibility is semantically precise and portable across WinGuard releases. The <X5> element is useful mainly when you need to depend on a specific WinGuard platform version for a reason not yet captured by any Skill (e.g., a platform-level bugfix).

<!-- Prefer (Skill-based): -->
<Compatibility>
  <Skill name="ext.adapter" version="0.1.10"/>
</Compatibility>

<!-- Use X5 only when a specific platform version is required: -->
<Compatibility>
  <X5 version="8.5.1.0"/>
</Compatibility>

→ See Manifest: Compatibility for the full reference.