Troubleshooting
Building & deploying
Troubleshooting
The build and deploy problems you will actually hit when a plugin won't load, each mapped to its real cause and the one-line fix.
Read the install report first
Every startup writes a plugin install report to the Control Center Log tab: one summary line per scan (how many plugins loaded, how many indicators and strategies were found) plus a line for every load or registration error, naming the offending DLL or type. If a plugin is missing, that report almost always names the exact reason before you start guessing — check it before anything else.
Silent skips don't appear as errors. A type that fails a discovery rule (not public, no zero-arg
ctor, wrong contract) is skipped silently — the DLL loads, but the type simply isn't
cataloged, so you'll see the plugin counted as loaded with fewer types than you expected. A
load error (bad DLL, missing dependency) is what shows up as an error line.
Common symptoms & fixes
| Symptom | Likely cause & fix |
|---|---|
| Plugin doesn't appear anywhere, no error in the log | The type failed a discovery rule. It must be public, concrete (not
abstract / interface / open generic), zero-arg constructable, and implement a recognised
contract. See Discovery rules. |
| Plugin builds but is missing in the app | The DLL landed in the wrong folder. The auto-deploy default is
%AppData%\AlgoStudioPro\Plugins, which is not the runtime scan path. Set
AlgoStudioProPluginsFolder to the Plugins folder next to
TradeStrike.Desktop.exe. See Where to deploy. |
| Type appears but won't instantiate | Its constructor needs a required argument. Give it a parameterless ctor (or make every ctor
parameter optional) and move tunables to [IndicatorParameter] properties. |
| Log shows a load error for your DLL | You deployed a contract assembly, a .deps.json, or the whole bin folder.
Remove everything except your DLL (and optional PDB). |
TypeLoadException / cast or assignability failure |
Type-identity clash from a shipped contract DLL — your IIndicator is a
different type than the host's. Same fix: deploy your DLL only. See
Why contracts must come from the host. |
| "Could not load file or assembly <X>" | A genuine third-party dependency is missing. Copy that one sidecar DLL into the
Plugins folder next to your plugin. See
Third-party dependencies. |
| Plugin fails to load on a framework error | Wrong target framework. Build for net10.0 (or higher within the same major), the
host's baseline. |
| Changes don't take effect after a rebuild | Plugins are scanned once at startup and there is no hot reload. Fully restart TradeStrike after each build. |
Quick checklist
When a plugin won't show up, run through this in order — it resolves the vast majority of cases:
- Is the type
public, concrete, and zero-arg constructable, implementing a real contract? - Is exactly one file — your DLL (plus optional PDB and any genuine sidecar dep) — in the
Pluginsfolder? - Is that folder the one next to the running EXE, not the auto-deploy default?
- Did you fully restart TradeStrike after the build?
- Does the Control Center Log tab name an error? If so, it names the fix.
Still stuck? The cross-cutting Troubleshooting & FAQ page
covers runtime symptoms beyond loading — an indicator that loads but renders nothing, a strategy
that gets no callbacks, a provider that doesn't list, and more.