Getting started

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.
Pure contracts, no engine. The SDK ships only interfaces, abstract base classes, attributes, enums and data records — there is zero runtime engine code in it. The host provides the engine at load time. This is the technical reason your deployed plugin must not carry copies of these assemblies; the full explanation lives in Dependencies & isolation.

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 (or net10.0-windows when you need WPF, which only a few drawing/rendering plugins do). The meta-package itself targets net10.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>
About the property names. The opt-in property is 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.
Pin the version. The three contract assemblies are versioned in lockstep, so any given SDK version is a stable, frozen surface. Pin the version you build against (0.1.0 today) and upgrade deliberately — never float it — so a new SDK never changes your plugin's behaviour without you choosing it.