TuringTrader: a C# backtesting engine with a simulator behind the same interface

What the project is, and where the two halves sit

TuringTrader is an open-source backtesting engine and trading simulator, licensed under AGPL 3.0 and published by Bertram Enterprises, with the project website at turingtrader.org carrying the news, the updates and the download.

The name is the interesting part of the positioning, and it comes from Alan Turing's paper on computable numbers, in which he describes a machine that reads a description of a tape and a machine description and simulates it. That is exactly what a backtester is, a machine that reads a description of a market and a description of a strategy and steps the market forward. The framing is not decoration in a project like this, because it sets expectations: the engine is a simulator, and a simulation is only as good as its fidelity to the thing being simulated.

The repository tree shows how the project is organised, and the two directories that matter are TuringTrader.Simulator and TuringTrader.Setup. The simulator is the part that runs strategies against data, and the setup project is the part that generates the distribution, so the same strategy code is what you research and what you ship. Algorithms/ holds the strategies themselves, Data/ the data layer, Templates/ the strategy templates, and TuringTrader.Tests/ the test project, with TuringTrader/ as the core library, DocFX/ for the documentation build, More/ for supporting utilities, and BooksAndPubs/ and BooksAndPubsV2/ for the companion material, which is a separate project linked against the binary distribution rather than against the source tree.

The primary language is C#, and the topic list gives a good picture of the scope: algorithmic trading, backtesting, options, portfolio management, portfolio optimization, stock indicators, technical analysis, quantitative finance and trading strategies, which is a wider set than a pure equity backtester would cover.

Installing the binary, and the documentation that lives elsewhere

The installation route for users is a setup file, downloaded from the download page on the project website, and the documentation is a separate site again at the documentation path under the same domain.

Both of those facts are worth pausing on, because they describe a project where the repository is the source and the website is the product. There is no package on NuGet, no container image and no cross-platform installer mentioned, so a user who wants to try the engine downloads a Windows setup file, and a developer who wants to read how the algorithm interface works reads a DocFX-generated site rather than the repository.

That is a coherent choice for a project with a documentation site as its front door, and it is also why the repository tree contains a DocFX/ directory and a documentation build step. The API documentation is generated from the source, so the two are meant to move together.

The project also publishes a documentation site that carries the news and the updates, which is the mechanism by which a user finds out that a data source changed, that a new indicator was added or that a simulation model was revised. For a backtesting tool that is a genuinely important channel, because the correctness of a result depends on the fidelity of the simulation, and a change in that fidelity invalidates results that were produced before it.

The licensing is the AGPL, and the repository carries the AGPL badge and a COPYING.txt file. The significance of that choice for an engine like this is worth understanding rather than accepting, and the conclusion section returns to it.

Building from source, and what the toolchain implies

The build-from-source section is written for Windows, and the prerequisites are listed precisely.

They are Microsoft Visual Studio Community 2022, with an installation that must include the workloads for .NET desktop development and Universal Windows Platform development, the .NET 6.0 SDK, the DocFX toolset at version 2.62.2, and the WiX Toolset v4, in the FireGiant HeatWave Community Edition.

The build steps then read as a sequence rather than a single command:

- Install TuringTrader from binary distribution
- Open TuringTrader solution in Visual Studio
- Build release version of TuringTrader project
- Publish TuringTrader application
- Build BooksAndPubs project (linked against the binary version installed)
- Build setup project
- Build documentation

Two things in that list are unusual and both are consequences of the setup step. The BooksAndPubs project is linked against the binary version that was installed in the first step, not against the freshly built source, which means the companion material is built against a known binary rather than against whatever the working tree happens to contain. And the setup project is built after the application, so the installer packages the published application rather than a development build.

The project also contains a script for a single-click build of the installer, SINGLE_CLICK_BUILD.bat at the repository root. The link points at the develop branch while the default branch of the repository is master, which is a small detail and a useful one, because it tells you that develop is where the build script is kept up to date.

The Visual Studio requirement is the real constraint here. A team that builds on Linux or macOS has no path described in the documentation, and a team that wants to run the engine in a container has to solve the Windows dependency itself. That is a legitimate design decision for a project that targets the Windows desktop, and it is the single biggest thing to know before evaluating the tool.

The repository layout, and what the directories tell you

The top-level entries describe a project with more moving parts than a typical library, which is expected for something that builds a Windows installer, generates documentation and ships data.

TuringTrader.sln is the solution, and the project directories are the domain structure. Algorithms/ is the strategy library, Data/ is the data handling, Templates/ holds the strategy templates, and More/ holds supporting pieces. TuringTrader/ is the core library that the rest depends on, TuringTrader.Setup/ is the installer project, and TuringTrader.Tests/ is the test suite.

The two BooksAndPubs directories are the least obvious. BooksAndPubsV2/ sits alongside the older BooksAndPubs/, and the build instructions make the older one a separate compilation unit linked against the installed binary, which is the arrangement a companion e-book or publication project would need.

Two more entries deserve a mention. There is a default-files.lnk, a Windows shortcut file, which is the kind of thing that appears when a project ships a desktop shortcut for the installed application, and there is a packages/ directory, which is the NuGet packages restored for the solution, checked in or restored into the tree depending on the configuration.

Data/ is the directory that a backtesting tool lives or dies by, and its presence at the top level, rather than inside a library, is a statement that the data layer is a first-class part of the product rather than an implementation detail. The topic list backs that up with stock indicators, technical analysis and quantitative finance alongside the backtesting and portfolio terms.

The repository carries the usual housekeeping, with .gitattributes and .gitignore at the root, a COPYING.txt carrying the licence text, and a README that is deliberately short, because the documentation lives on the website and the readme's job is to point at it, the download and the build steps.

Where TuringTrader is the wrong tool

The first limit is the platform, and it is a hard one. The installation is a Windows setup file, the build needs Visual Studio with the .NET desktop and Universal Windows Platform workloads, and the installer itself is produced with the WiX Toolset. A team that runs its research stack on Linux has no documented path, and a team that wants the engine inside a service it deploys to a cloud environment has to solve the Windows dependency itself.

The second is the licence, and for a backtesting engine it is worth thinking about rather than accepting at a glance. AGPL 3.0 is a strong copyleft licence, and its network clause is the part that matters for a tool like this. A team that modifies the engine and offers the modified version to users over a network owes them the corresponding source. That is a meaningful obligation for a commercial product built on top of it, and it is different from the MIT or Apache terms that a comparable research tool would more likely carry. A team that wants to embed the engine in a hosted research platform has to read the licence rather than skim it.

The third is that the project has no packaged distribution for developers. There is no NuGet package listed, no container image and no cross-platform build, so adopting the engine means either using the installer or vendoring the source and building it yourself on Windows. For a tool whose value is a long-lived research environment, that is friction at the start of every project.

The fourth is the version and release picture. The repository has no GitHub releases, and the last push to the repository was on 2026-05-19, so the source is being worked on without a tagged artefact, and a user who wants a specific version is relying on the website's distribution rather than on the repository's tags.

And the fifth is the scope of what a backtester can promise. A simulator reproduces a market model, and the fidelity of that model is the assumption underneath every result it produces. The engine's own documentation is where the simulation assumptions are stated, and for a project whose headline is a backtesting engine, a user who does not read the documentation of the data and simulation model is taking the results on faith. That is a property of the category rather than of this implementation, and it is the reason the news and updates page on the website matters more here than it would for a general purpose library.

Editorial conclusion

TuringTrader is worth evaluating if you write quantitative strategies in C# and want to move between researching on historical data and running against a live feed, because the repository is split into a simulator project and a setup project that share the same algorithm code, so the same strategy assembly is what you backtest and what you deploy. It is the wrong tool if you are not on Windows, and it is the wrong tool if you want a library to embed in an existing service. Before you try it, check three things: that the licence fits, because AGPL 3.0 is a strong copyleft licence with a network clause, and a team that modifies the engine and offers it as a service has obligations that the permissive licences you might expect for a backtesting tool would not impose; that you accept the toolchain, because building from source needs Visual Studio Community 2022 with the .NET desktop and Universal Windows Platform workloads, the .NET 6.0 SDK, the DocFX toolset at version 2.62.2 and the WiX Toolset v4 for the installer; and that the documentation is external, because the project documentation is a DocFX site rather than something in the repository, so the parts you will need most, the algorithm interface and the simulator model, are where you have to look first.

Frequently asked questions

Official sources

1. fbertram/TuringTrader on GitHub
2. Issues
3. License: AGPL-3.0
4. Project website
5. README