TABLE OF CONTENTS

• Introduction
  • Platform and Technology Requirements
  • Plugin Development Guidelines
  • Interpret Version
• Interpret Plugin Development
  • Plugin Interface
    • Plugin Interface Architecture
    • Interface Definitions
  • Plugin Implementation
    • Understanding the data
    • Step by step guide
  • Example
  • Plugin Execution Workflow
  • Plugin packaging
• Installing a plugin
• Appendix

Introduction

Interpret is a desktop application built on .NET 8 and uses Windows Presentation Foundation (WPF) for its user interface. The application is designed exclusively for Windows platforms and runs on x64 architecture.

Platform and Technology Requirements

Because Interpret is a WPF-based .NET 8 application, all plugins must be built to run in the same environment. This ensures compatibility with the application’s runtime and its UI rendering model. Plugins should target:

• .NET 8 runtime
• WPF for UI components
• Windows x64 as the deployment architecture

Plugin Development Guidelines

Developers building plugins for Interpret should follow these guidelines:

• Match Core Technologies – Plugins must be compiled against .NET 8 and structured to work within a WPF environment.
• UI Integration – Any UI elements within the plugin must use WPF controls and adhere to WPF’s MVVM or similar design patterns for consistency.
• Custom Interfaces Allowed – Plugins may define their own user interfaces, provided they respect WPF conventions and integrate cleanly into the host application.
• Windows-only Deployment – Plugins should not rely on platform-agnostic or cross-platform UI frameworks, as Interpret will only run in Windows x64.

Interpret Version

External plugin implementations are available in Interpret from version 3.0.7

Interpret Plugin Development

A plugin is a self-contained assembly (usually a .dll) that extends the functionality of a host application without modifying the host’s core code. In WPF desktop apps, plugins are typically:

Loaded at runtime via reflection.

Discovered through a defined interface contract (shared between the host and the plugin).

Executed within the host process, sharing the same AppDomain (unless explicitly isolated).

Core Components

Plugin Interface

This section describes the interface your plugin must implement so Interpret can load and execute it. The interface defines a simple, typed contract for building plugins that process XML and JSON inputs and return results as XML through a callback.

Plugin Interface Architecture

The EMPluginInterface namespace defines three core interface layers:

1. IRootPlugin – Declares common metadata every plugin must provide.
2. IPluginBase<TAnnotation, TTrack, TFinishedHandler> – Declares the execution contract for plugins, using generic types for input and callback signatures.
3. A concrete specialization, IPlugin, that binds the type parameters to XmlDocument, JsonDocument, and a custom PluginFinishedHandler.

NOTE: Interpret only loads external assemblies that implement the IPlugin interface.                                                                                                                                                           

Interface Definitions

All plugins must provide:

• Name – Short identifier for the plugin.
• Description – Human-readable explanation of what the plugin does.
• Usage – Instructions or guidelines for using the plugin.
• Execute function

• Parameters:
  • XmlDocument – Annotations XML object.
  • JsonDocument – CruiseTrack Json object.
  • PluginFinishedHandler (delegate accepting an XmlDocument) – Callback invoked when processing is complete.
• Return: bool – Indicates whether the plugin accepted and started processing the input.

Plugin Implementation

Understanding the data

When executing a plugin, Interpret prepares and transmits the data payloads required for processing. This payload consists of two structured objects:

1. Annotations Data (XML) 
   • This object represents the complete annotations hierarchy, including all nodes, attributes, and associated content, serialized in XML format. 
   • Its schema and structure are identical to those defined in the *.emi file specification, ensuring compatibility between saved annotation files and runtime data. 
   • The XML encapsulates the full annotation tree, preserving relationships, metadata, and domain-specific elements.
2. Cruise Track Data (JSON)

• This object contains a chronologically ordered sequence of geographic points, where each entry includes GPS coordinates and an associated timestamp.
• The dataset is sourced directly from the Vessel Dataset and reflects the recorded navigation track for the relevant operational period.
• The JSON format provides an efficient, structured representation suitable for parsing, mapping, and spatial-temporal analysis within plugins.

Step by step guide

Prerequisites

• OS/Arch: Windows x64
• SDK: .NET 8 SDK
• UI: WPF (if your plugin has UI)
• Contract: Reference the shared EMPluginInterface assembly (the one that defines IPlugin, PluginFinishedHandler, etc.)

1. Create the Plugin Project

Create a Class Library (or WPF Class Library if you plan to ship views):

If your plugin is headless (no UI), you can omit <UseWPF>true</UseWPF>, but leaving it on is harmless.

Because your project must implement the IPlugin interface, it needs access to the EMPluginInterface definitions. You can satisfy this requirement by either referencing the EMPluginInterface project directly or by including the provided DLL in your plugin project (see Appendix).

Both options are supplied, so you may choose whichever integration method best fits your development setup.

Example:

3. Understand the Contract (what you must implement)

Review and understand the plugin interface structure, members to implement and parameters to receive.

Create a public, non-abstract class implementing IPlugin. Provide stable values for the class properties.

5. Implement Execute method

Implement the Execute method in your new non-abstract class. This method must contain all the logic from your plugin. Execute can run async operations.

Invoke the PluginFinishedHandler if you want to return a modified Annotations data XML to be loaded by Interpret.

If your plugin exposes UI (UserControl/Window), keep it WPF/MVVM:

• Create your UI controls; Window, UserControl  (e.g., Views/TrackPanel.xaml)
• Keep logic in a ViewModel
• Avoid global Application resources; use local ResourceDictionaries and predictable keys
• Trigger your UI within the Execute function.

Example

Plugin Execution Workflow

1. Interpret loads all the IPlugin implementations at start and reloads them if a new plugin is added.
2. Interpret prepares:
   • An XmlDocument containing full annotation data tree.
   • A JsonDocument containing track data
   • A PluginFinishedHandler delegate to receive results.
3. Interpret calls:

               bool started = plugin.Execute(xmlDoc, jsonDoc, handler); 

4. Plugin processes input:
   • Can operate synchronously (call handler before returning)
      or asynchronously (call handler later).
   • Returns true if execution started successfully; false otherwise.
5. Handler receives a processed XmlDocument when the plugin finishes.
6. Interpret loads the annotation data XmlDocument and replaces the current annotation tree.

Plugin packaging

1. Confirm project settings

Open your plugin .csproj and make sure it targets the same stack as the host:

• Reference the same version of EMPluginInterface the host uses.
• If you have WPF XAML/resources, leave <UseWPF>true</UseWPF>.

CLI:

Visual Studio: Build → Restore NuGet Packages (usually automatic).

This produces YourPlugin.dll and PDBs.

CLI:

VS: set Configuration=Release, Platform=x64, then Build.

Artifacts go to:

./bin/Release/net8.0-windows/

To copy your plugin and its NuGet dependency DLLs into one folder, use publish with CopyLocal:

This keeps it framework-dependent (host provides .NET). You’ll get:

      publish/win-x64/

             YourPlugin.dll

              YourPlugin.pdb

             (any *.dll dependencies)

             (resource folders for satellite assemblies, if any)

5. Do not include EMPluginInterface.dll in your plugin package

Your plugin must reference the exact EMPluginInterface.dll that ships with Interpret. To ensure this, configure your project so that EMPluginInterface.dll is not copied to the build output directory, or manually remove it from the output before packaging (zipping) your plugin.

6. (Optional) Versioning & SourceLink

Set assembly/file versions so the Interpret can diagnose issues:

Compress all files from the binary output directory (./bin/Release/net8.0-windows/) into a single ZIP archive, and name the ZIP file using your plugin’s name followed by its version number.

Installing a plugin

 Interpret offers two places to install the plugin:

1. Initial window

The Initial Selector Window offers a plugin manager window by clicking on the settings button.

The Plugin Manager allows you to:

• Add new plugins
• Delete plugins
• Enable and Disable plugins
• Refresh the plugins assembly loaded.

Clicking the Add button lets you choose a ZIP file to install. Interpret will unpack the ZIP and place your plugin’s binary files in the appropriate directory. Once installed, Interpret automatically loads your assembly so it’s available for use in the Main window.

The Plugins option in the Main window’s menu lets you view all installed plugins, run them, and add new ones.

Once installed, your plugin should be visible in the Plugins menu, like this:

Appendix

This is the list of additional materials provided with this manual:

• EMPluginInterface project. It contains the interface structure and plugin implementation examples.
• EMPluginInterface.dll
• Annotations XML example.
• Cruisetrack JSON example.