Give the platform its own window and its own main-menu entry. An add-on is the plugin kind for tooling that is not tied to a single chart.

What an add-on is

An indicator lives on a chart. An add-on lives in the Control Center: it is the plugin kind for tooling that is not tied to one chart, one instrument or one timeframe. A scanner across your whole watchlist, a risk dashboard, a journal, a position calculator, a bridge to something you run in-house. It gets its own window, its own entry in the main menu, and read or write access to accounts, orders, live ticks and historical bars.

It is one DLL, discovered exactly like every other plugin. There is no manifest file to write and no host setting to change: implement IAddOn, drop the DLL in your plugins folder, and your window is in the menu.

The shape of one

Three members, one of which is optional. You say who you are, you get handed the platform, and you return what you contribute.

VolumeScannerAddOn.csusing SabrTrader.Pipeline.AddOns;

public sealed class VolumeScannerAddOn : IAddOn
{
    public AddOnManifest Manifest { get; } =
        new("acme.volume-scanner", "Volume Scanner", "Acme", "1.0.0")
        {
            Description = "Flags unusual volume across your watchlist.",
        };

    public AddOnContributions Initialize(IAddOnHost host) => new(
        windows: new[]
        {
            new AddOnWindowKind("main", () => new ScannerWindow(host))
            {
                MenuTitle   = "Volume Scanner",
                MenuSection = AddOnMenuSection.New,
            },
        });

    public void Shutdown() { }          // optional; default does nothing
}

Initialize takes the host and returns the contributions in one call, so there is no ordering to get wrong. A window factory or a command you build in there can simply capture host.

The manifest

AddOnManifest is a pure value, read at discovery before anything is initialised. Its Id is your identity for the life of the installation: it roots your settings folder on disk and keys your windows in a saved workspace. Pick a stable, vendor-scoped id like acme.volume-scanner and never change it, or a later release orphans both.

What you can contribute

AddOnContributions carries two lists, both optional.

Return AddOnContributions.None and you have a background add-on: no window, no menu entry, just work between Initialize and Shutdown. That is a legitimate shape, and it is how you would write a bridge that pushes fills into your own system.

Where your entries land

Set MenuSection and the host puts your entry in an Add-ons sub-menu at the bottom of that menu:

Grouping your entries under Add-ons rather than mixing them into the platform's own items keeps two promises: users can always see which entries came from outside, and no add-on can shadow or reorder a platform item. Your entry's tooltip carries your add-on name, so an unfamiliar item always says who put it there.

Lifecycle

1. Discovery. The loader finds every public, concrete, parameterless-constructor IAddOn in your DLL and reads its Manifest.
2. Initialize. Called once, on the Control Center's UI thread, after the platform services are up. Wire yourself up and return your contributions. Do not block here: start network or disk work on your own thread and let the window show a status until it lands.
3. Running. Everything else happens through what you contributed. The host calls nothing else on the add-on object itself.
4. Shutdown. Called on app exit, and again whenever a rebuilt DLL replaces you. Release threads, subscriptions and files. Your windows are already closed by then.

Isolation

An add-on is third-party code and the platform treats it that way. If your Initialize throws, your add-on is dropped and the reason goes to the activity log, while every other add-on keeps running. If a button handler throws, it is caught, logged against your add-on name, and the window carries on. Failures are always surfaced, never swallowed, so a broken add-on tells the user what happened instead of quietly doing nothing.

On the Windows desktop host, each add-on window also gets its own UI thread. Slow work in a handler costs your own window a frame, not the Control Center.

A tour of the chapter

• Windows & views is the one to read next: what a window is, and how you describe its contents without touching a UI framework.
• Platform services covers IAddOnHost: accounts and orders, historical bars, the live tape, instruments, logging.
• Settings & workspace state covers the two kinds of state an add-on keeps, and which one you want.
• A complete add-on is every file of a working one.
• Reference › Add-ons lists every type and member.