Install, inspect and update plugins

Understand a plugin package#

AMM loads user and third-party algorithms and chart indicators from manifest-backed .NET assemblies. The package includes a *.ammplugin.json sidecar naming its stable plugin ID and entry assembly, plus the DLL and any required private dependencies. Matching portable PDB/XML documentation can accompany it. A DLL or source file on its own is not the discovery contract.

Plugins can also supply Trading Systems guides and chart, screener or workspace templates. Those JSON assets are catalogued separately from executable code. An imported template creates ordinary user state; it does not modify the original plugin package. A guide can remain visible while a required indicator is missing, with availability explaining the missing contract.

Choose a workspace#

Open the application's plugin-workspace management controls from the plugin/algorithm selection workflow. Inspect the Default Folder, Watched Folders and Shadow Copy Folder. The default authoring root is always included among watched roots. Relative paths resolve under the server's data folder; use a deliberate folder on the machine that actually runs the plugin host.

The runtime scans watched roots recursively for *.ammplugin.json, excluding bin, obj and .git. Publish payloads into a distribution directory under a watched root. A successful build into an excluded bin folder can leave the plugin absent from AMM. The shadow-copy folder holds the loaded runtime copies so source payloads can be replaced without editing the executing DLL in place.

Saving workspace settings applies them immediately and refreshes discovery. If plugins are routed to a configured local-execution worker, management/scaffold operations target that worker; a desktop folder path is not automatically a worker folder.

Install and verify#

1. Obtain a package compatible with the AMM SDK/version you run and review its provenance.
2. Keep the manifest, entry DLL, dependencies and matching symbols together.
3. Place the complete package under a configured watched distribution root.
4. Wait for catalogue refresh, then inspect the loaded plugin and available algorithms/indicator types.
5. Open a controlled chart or small backtest to verify the expected behavior and parameters.
6. Review any package-specific guide before enabling automated orders.

Use GET /api/plugins for loaded state, errors, runtime payload hashes and debug-module details. GET /api/algorithms discovers executable algorithm metadata. /api/plugins/artifacts discovers reusable assets. A source project or a copied template can exist while its executable plugin is missing; inspect both catalogs.

Do not assume a plugin is profitable, exchange-approved or appropriate for a real account because it loads successfully. Installation, mathematical correctness, reproducible research and real execution acceptance are separate facts.

Update without confusing running instances#

Rebuilding/replacing a payload normally triggers watcher reload after a short debounce, with a polling fallback. Existing runs keep their already-created plugin instances; new code is not retroactively inserted into an active strategy. For a controlled update, stop the affected development/research run, publish the complete new payload, confirm the loaded hash/version, then start a new run.

Keep a recoverable copy of the previous package where it cannot accidentally be rediscovered as a second active manifest. Duplicate plugin IDs resolve by watched-root priority, so an older package in an earlier root can shadow the new build. Inspect the actual loaded source and shadow-copy paths instead of relying on a filename timestamp.

If load fails after an AMM update, refresh/rebuild against the matching published SDK. Old binaries referencing the superseded assembly contract need rebuilding from source. Do not fix a type-load failure by copying the host's implementation source or arbitrary assemblies into the plugin folder.

Create a new plugin#

The UI, REST scaffold and offline CLI use the same generator. Choose algorithm, indicator or both, a stable ID and an active watched target. Through REST:

POST /api/plugins/scaffold
Content-Type: application/json

{"pluginId":"MyResearchPlugin","kind":"both"}

Omitting targetFolder uses the configured default. An explicit API target must be one of the watched roots. IDs accept letters, digits, ., _ and -; a non-empty existing project directory is rejected. The scaffold creates source/project files, not a loaded plugin. Follow its generated README to build into the watched distribution directory:

dotnet build MyResearchPlugin.csproj --output '../dist/MyResearchPlugin'

Run that from the generated project folder. Confirm the emitted manifest and DLL are together under the watched root. The scaffold references the shipped binary SDK, not AMM source projects.

Troubleshoot a missing entry#

Check manifest suffix and relative entry assembly, excluded folders, dependencies, SDK compatibility and duplicate IDs. Read the plugin error before restarting anything. If an indicator template says a type is required but unloaded, inspect the exact stable type ID and owning package; a similar label is not equivalent. If a fresh external workspace has source but no runtime distribution, build it first.

For authoring, continue with Algorithm authoring or Indicator authoring. For JSON assets, use Plugin templates, and browse Plugin catalogue for current content families and their scope.