Getting started
Install the SDK
Set up your toolchain and add the one NuGet package every plugin compiles against. Once this is done you never touch the host's source — you build against contracts.
What the SDK is
TradeStrike.Sdk is a single meta-package. It ships no code of its own; it exists to
pull in the contract assemblies a plugin author compiles against, and to add one MSBuild target that
can auto-deploy your build. Installing this one package is all it takes to start writing any plugin
kind — an indicator, a strategy, a bar type, a data or trading provider, and the rest.
It brings in three contract assemblies as transitive dependencies:
| Assembly it brings in | What you get from it |
|---|---|
TradeStrike.Pipeline.Contracts |
Indicators, plots, series, bars, ticks, market depth, drawing tools and data providers. |
TradeStrike.Pipeline.Trading.Contracts |
Orders, positions, accounts, risk and ATM bracket types. |
TradeStrike.Pipeline.Strategies.Contracts |
The Strategy base class and its runtime context. |
The brokerage and trade-history contracts (TradeStrike.Pipeline.Brokerage.Contracts and
TradeStrike.Pipeline.TradeHistory.Contracts) cover lower-level integration points. If you are
building one of those, reference that contract package directly alongside TradeStrike.Sdk; the
Brokerage and Trade history chapters
say which.
Why a single package
Bundling the contracts behind one meta-package means you reference one thing and get a stable,
versioned surface. The contract assemblies move in lockstep with the host they target, so pinning a
single SDK version pins the entire API you build against — no risk of mixing a new
Trading.Contracts against an old Pipeline.Contracts.
When to set it up
Before you write a line of plugin code. A plugin is an ordinary .NET class library, and the SDK
reference is what makes the contract types — IndicatorBase, Strategy,
IDataProviderFactory and friends — visible to your project.
Prerequisites
The toolchain is the standard .NET one. There are only three things to have in place.
-
The .NET 10 SDK. Plugins target
net10.0(ornet10.0-windowswhen you need WPF, which only a few drawing/rendering plugins do). The meta-package itself targetsnet10.0, and a plugin can never target a framework higher than the host that loads it — so net10.0 is the ceiling as well as the floor. - An IDE or editor. Visual Studio 2022+, JetBrains Rider, or VS Code with the C# Dev Kit all work. Nothing TradeStrike-specific needs to be installed into the IDE.
- TradeStrike installed. You need a running host to load your plugin into, and its install folder is where the built DLL ultimately lands. If you are developing against a source build instead of an installed copy, that works too — the deploy target is just a different folder, covered in Where to deploy.
Installing the NuGet
The SDK is distributed as a .nupkg file rather than published to nuget.org, so you tell
NuGet where to find it. There are two common ways, depending on whether you want a reusable local
feed or a one-off reference.
Option A — a local package feed (recommended)
Point NuGet at the folder that contains TradeStrike.Sdk.0.1.0.nupkg by adding a
nuget.config next to your solution. This makes the package available to every project in
the solution and survives clean checkouts, which is why it is the better choice for anything you will
maintain.
nuget.config<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="tradex-local"
value="C:\path\to\TradeStrike.Sdk\bin\Release" />
</packageSources>
</configuration>
Then add the package from the command line (or through your IDE's NuGet UI):
shelldotnet add package TradeStrike.Sdk --version 0.1.0
Option B — a direct reference
If the package is already present in your machine's global NuGet cache or in a feed your IDE is
configured against, you can skip the nuget.config and simply declare the
<PackageReference> in your project file. That is shown on the next page.
The auto-deploy MSBuild target
The SDK package also ships an MSBuild .targets file that NuGet imports into your project
automatically. It adds one opt-in target that copies your freshly-built plugin DLL (and its PDB, when
present) into the host's Plugins folder after every build — so you never copy files
by hand while developing. It is inert until you opt in; importing it costs nothing
until you set the property.
Turn it on with one property in your plugin's .csproj:
MyPlugin.csproj (PropertyGroup)<DeployToAlgoStudioPlugins>true</DeployToAlgoStudioPlugins>
The destination defaults to %AppData%\AlgoStudioPro\Plugins on Windows. To deploy to a
different host install (for example a source build), override the folder:
MyPlugin.csproj (PropertyGroup)<AlgoStudioProPluginsFolder>D:\dev\tradex-bin\Plugins</AlgoStudioProPluginsFolder>
DeployToAlgoStudioPlugins and the
override is AlgoStudioProPluginsFolder — the names are historical and unchanged for
compatibility, so use them exactly as written even though the product is TradeStrike. The next page shows
the full .csproj in context, and Where to deploy
covers picking the right destination folder.
0.1.0 today) and
upgrade deliberately — never float it — so a new SDK never changes your plugin's behaviour
without you choosing it.