Where to deploy

Building & deploying

Where to deploy

The exact folder the host scans, the SDK's opt-in MSBuild auto-deploy target, the manual copy alternative, and the one rule that trips up almost everyone: ship the plugin DLL and nothing else.

On this page

Where the host looks

The runtime only ever looks in one place: a folder named Plugins sitting next to the running executable. There is no registry entry, no search path, and no setting that points elsewhere — the scan path is computed from the host's own base directory.

runtime scan path (host internal — shown for orientation)<app base directory>\Plugins\
// computed as: Path.Combine(AppContext.BaseDirectory, "Plugins")

Where that resolves depends on how you run the host. For an installed copy it is under the install directory; for a local developer build it is inside the build output next to TradeStrike.Desktop.exe. The two cases you will actually hit:

Scenario Drop your DLL here
Installed app <install dir>\Plugins\ (e.g. C:\Program Files\TradeStrike\Plugins\)
Running from a dev build TradeStrike.Desktop\bin\<Config>\net10.0-windows\Plugins\
The folder is created for you on first deploy. A missing Plugins folder is not an error — the scan simply finds nothing. The auto-deploy target creates the folder if it doesn't exist; for a manual copy, create it yourself.

Auto-deploy from MSBuild (opt-in)

Installing the TradeStrike.Sdk package brings in an MSBuild .targets file automatically. It defines a single opt-in target, DeployToAlgoStudioPlugins, that copies your just-built DLL (and its .pdb when present) into a Plugins folder after every build. It is inert until you opt in — authors who prefer to deploy by hand pay nothing for importing the file.

Turn it on by setting the property in your plugin .csproj:

XML — YourPlugin.csproj<PropertyGroup>
  <DeployToAlgoStudioPlugins>true</DeployToAlgoStudioPlugins>
</PropertyGroup>

The destination defaults to %AppData%\AlgoStudioPro\Plugins. Override it per project with the AlgoStudioProPluginsFolder property — point it at the Plugins folder next to the host EXE you actually run:

XML — YourPlugin.csproj<PropertyGroup>
  <DeployToAlgoStudioPlugins>true</DeployToAlgoStudioPlugins>
  <AlgoStudioProPluginsFolder>C:\Program Files\TradeStrike\Plugins</AlgoStudioProPluginsFolder>
</PropertyGroup>
The default destination is not the runtime scan path. The target's default, %AppData%\AlgoStudioPro\Plugins, is not the same as the <app base directory>\Plugins folder the host actually scans (see above). A plugin built with the default lands somewhere the host never reads, so it builds cleanly yet never appears. If your plugin compiles but is missing in the app, set AlgoStudioProPluginsFolder explicitly to the folder next to TradeStrike.Desktop.exe.
About the AlgoStudioPro spelling. The MSBuild identifiers (DeployToAlgoStudioPlugins, AlgoStudioProPluginsFolder) and the default path still carry the product's pre-rebrand name. The product is TradeStrike; these are simply the literal identifiers the shipped TradeStrike.Sdk.targets defines today, so you must type them exactly as written.

Manual copy

If you would rather not couple your build to a host path, leave DeployToAlgoStudioPlugins off (its default) and copy the DLL yourself after each build:

bash / PowerShellcopy bin\Release\net10.0\YourPlugin.dll "C:\Program Files\TradeStrike\Plugins\"

Then restart TradeStrike. This is exactly what the auto-deploy target does under the hood — it copies the single primary output assembly (and PDB), nothing more.

The golden rule: deploy the plugin DLL only

Once you have the right folder, the other half of deployment is knowing what not to put in it. Copy only your plugin's own DLL (and optionally its .pdb, so exceptions carry readable stack traces in the host log). Everything else in your build output is either already provided by the host or actively harmful to copy.

File Ship it?
YourPlugin.dll Yes — this is the plugin.
YourPlugin.pdb Optional — helpful for readable stack traces.
A genuine third-party dependency (not host-provided) Yes — see Dependencies & isolation.
TradeStrike.Pipeline.Contracts.dll & other SDK contract assemblies No — the host already provides these.
YourPlugin.deps.json / YourPlugin.runtimeconfig.json No.
The whole bin output folder No.
Why shipping a contract DLL breaks discovery. Each plugin is loaded into its own isolated AssemblyLoadContext. The contract assembly that defines IIndicator is force-resolved from the host's context so that typeof(IIndicator) is the same type on both sides. If you ship your own copy of a contract assembly, your MyIndicator : IndicatorBase implements a different IIndicator than the host knows, the assignability check fails, and your plugin is silently skipped. The fix is always the same: deploy just your DLL. The full mechanics are in the next chapter.

This is precisely what the SDK's auto-deploy target does — it copies $(TargetPath) (your single primary output) and never the dependency tree.

← BackOverview & discovery