Developing a Plugin

Developing plugins against Community is now as simple as just creating a new project. A dotnet new template generates the plugin structure and an entire pre-configured instance of a Community stack with all of its dependencies within Docker Compose to develop against.

Migrating a plugin from Community 13 or older? Review the migration guide.

Prerequisites

• Windows, macOS, or Linux
• A local container runtime such as Docker, OrbStack, Colima, or Podman.
• .NET 10 SDK
• Visual Studio Code or Visual Studio
•  How do I install Verint Community? 
•  What container images make up Verint Community? 

Install the Template

Install the template from NuGet.

dotnet new install Verint.Community.Templates --force

Scaffold a Plugin

Create a new plugin project:

dotnet new community-plugin --name HelloCommunity

This creates the HelloCommunity/HelloCommunity.csproj project.

For purposes of this example, open the HelloCommunity directory with VS Code and inspect the generated README.md which will provides guidance on using the plugin and its integrated Community stack.

The included Docker Compose setup spins up everything you need: web and job nodes, database, search, cache, message bus, telemetry, and email testing. The compose stack also also mounts plugin compilation artifacts into both web and job.

And if your plugin also includes factory default widget , embeddable, automation, or email assets, those CFS paths are also mounted into both containers allowing for easy management of both bundling of factory default assets as well as managing of their source code alongside the rest of the plugin.

Review the generated README.md for its stack-specific services and URLs.

Accept the SQL Server EULA

Before first startup, record SQL Server End User License Agreement acceptance for the project via one of a few ways:

• CLI: bash scripts/accept-mssql-eula.sh
• PowerShell: pwsh scripts/accept-mssql-eula.ps1
• VS Code: Ctrl+Shift+B: "Accept SQL Server End-User License Agreement"

This creates .devcontainer/mssql-eula.env with ACCEPT_EULA=Y which is auto-included when the stack runs. For more information about this environmental variable, refer to Microsoft's documentation.

Start the Stack

Native Workflow

Running the environment in native mode runs Community and its dependencies via Compose, but uses your native environment for building and debugging the plugin. It requires .NET 10 to be installed.

Start the stack in one of these ways:

• In VS Code: Ctrl+Shift+B → "Compose Up"
• CLI: bash scripts/compose.sh up or pwsh scripts\compose.ps1 up
• Windows: Double-click scripts\compose-up.bat

Dev Container Workflow

The template also includes a dev container to enable both running of Community as well as development against it within a pre-configured environment. This does not require .NET 10 on the host.

In VS Code:

1. Click the "><" icon in the bottom left ("Open Remote Window").
2. Select "Reopen in Container".

It may take a few minutes the first time as it pulls images and initiates.

Once ready, open the community URL as defined in README.md to access Community.

Building & Running the Plugin

Build the solution and HelloCommunity.dll will be output to artifacts/.

• In VS Code: Ctrl+Shift+B → "Build"
• CLI: dotnet build

The template writes plugin output to artifacts/build, which is already mounted into the running Community stack's mount point, /app/cfs/plugins.

Deploy the plugin by restarting the Community stack.

• In VS Code: Ctrl+Shift+B → "Compose Restart"
• CLI: bash scripts/compose.sh restart or pwsh scripts\compose.ps1 restart
• Windows: Double-click scripts\compose-restart.bat

The plugin is now ready to be enabled in Administration, most easily found via Search → "HelloCommunity Name".

Rebuild and restart as needed to deploy changes.

Debugging

Attach a Debugger

• VS Code: Go to "Run and Debug" → "Attach Debugger"
• Visual Studio: Debug → Attach to Process → Connection Type: Docker (Linux Container)

Access the Database

Use the SQL Server extension in VS Code. Note: the SQL container listens on a custom port identified in the README.md

View logs

View logs within the in administration, via the Aspire OpenTelemetry dashboard identified in the README.md, and through container logs. Refer to Aspire's documentation for how to log into its standalone dashboard.

Test Email

View outgoing mail using the debug SMTP server, MailPit, using the URL identified in README.md.

Working with Factory Default Providers

Managing factory default widgets, embeddables, and automations from external plugins used to be challenging, especially when trying to keep the defaults in the same source location as the plugin, while still supporting updates via Community’s developer mode. The plugin's Compose stack solves this while also scaffolding the required installation and uninstallation logic.

Scaffold a Factory Default Provider

Create a plugin with a default provider:

dotnet new community-plugin \
  --name HelloWidgets \
  --implementScriptable \
  --implementWidgetProvider

Other available provider types

Generate a Factory Default Widget provider (IScriptedContentFragmentFactoryDefaultProvider)

--implementWidgetProvider

Generate a Factory Default Automation provider (IAutomationFactoryDefaultProvider)

--implementAutomationProvider

Generate a Factory Default Embeddable provider (IScriptedEmbeddableFactoryDefaultProvider)

--implementEmbeddableProvider

Generate a Factory Default Email (IScriptedEmail)

--implementEmail

Generate an IScriptablePlugin implementation wired up to the default provider(s)

--implementScriptable

Edit Factory Defaults

1. Build the plugin.
2. Run the Community stack or open the development container.
3. Enable the "HelloWidgets Name" plugin under Administration.

In Administration → UI → Widget Studio:

• Filter to show only "HelloWidgets Name" widgets.
• The stub widget should appear.
• Edit and publish it—your changes will be saved back to HelloWidgets/cfs, ready to commit.

Bundling and Publishing

When you publish the plugin, the factory default files in cfs/ will be embedded in the assembly. They’ll automatically install when deployed to a new Community instance.

How does this work and why?

Using this process ensures upgrade safety.

Beyond the plugin project and its associated compose stack, projects generated from Verint.Community.Templates include references to a corresponding Verint.Community.Platform NuGet package. Verint.Community.Platform includes a single assembly, Telligent.Evolution.Extensibility. Telligent.Evolution.Extensibility contains reference versions of all upgrade-safe, supported, types in the In-Process API. These types are stub-only, but if a plugin can build against it, it will be loadable within Community. And no types that are not upgrade-safe are included.

Next Steps

• Learn how to manage data access and storage.
• Review other plugin documentation.
• Review the in-process API.
• Learn how to migrate plugins to Verint Community 14.