XTester Studio built on Code - OSS and XTester Engine

We have prepared the architecture plan for XTester Studio, a new version of XTester for macOS and Windows.

The editor and application shell will come from Code - OSS. This is the open-source base of Visual Studio Code, developed by Microsoft with the community and published under the MIT license. It already includes a code editor, file explorer, tabs, search, Git, a terminal, settings, themes and an extension system.

The current XTester already handles data, simulation, order execution and statistics. We plan to move that logic into a separate XTester EngineHost process.

Users will get a standalone XTester Studio application with its own branding, integrated modules, installers and updates. Visual Studio Code will not be required.

Project status: we have agreed on the overall direction and architecture concept, but development has not started. The next step is a separate architecture spike. It must confirm that Code - OSS can be packaged as an XTester product and that the existing engine can be separated from WinForms and run on macOS and Windows. We will then refine the first-milestone scope and implementation plan. We are targeting October 1, 2026 for the first public milestone.

Reusing what already works

Code - OSS already covers most of the standard parts of a modern development environment:

• Monaco Editor Core handles code editing;
• the workbench provides Explorer, tabs, menus, panels and the status bar;
• Electron is used for desktop builds;
• search, commands, keybindings, Settings, Problems and Output are already there;
• terminal, Git/Source Control and debugging infrastructure are available;
• extension modules run through the extension host in a separate process;
• themes, localization and shared UI components are included.

XTester modules will be added to the Code - OSS editor and shell. The trading logic will come from the current version: data, model time, orders, fills, fees, positions, portfolio state and statistics.

XTester Studio will be its own Code - OSS distribution. We want to keep changes to the upstream core small so future updates remain manageable. The architecture spike will show whether this works in practice.

What comes from where

Product area	What already exists	What Studio still needs
Editor and shell	Code - OSS: windows, tabs, Explorer, search, commands, settings and themes	XTester branding, product configuration, installers and updates
Code workflow	Monaco Editor Core, document models, navigation and diagnostics APIs	Strategy Project, manifest, XTester commands and engine integration
Workspace	Git, terminal, Problems, Output and state persistence	Backtest profiles, data, Evidence and run artifacts
Trading engine	Current XTester: data, simulation, execution and statistics	Separate it from WinForms and run it as EngineHost
Charts and panels	Code - OSS webviews, custom editors and other UI extension points	XTester charts, trades, positions, statistics and simulation settings
Extensions	Extension host and extension API	Integrated XTester modules, a reviewed catalog and security rules

Code - OSS will provide the editor and workspace. The trading engine will come from the current XTester after it has been separated from the Windows-specific UI.

Moving the trading engine instead of rewriting it

XTester Engine is written in C#/.NET. It already contains a substantial amount of code for data, simulation, execution and statistics. Rewriting that code in TypeScript, C++, Rust or Python would require us to validate event ordering, model time, orders, fills, fees, positions and strategy results all over again.

We plan to keep the C#/.NET engine, separate it from WinForms step by step, and run it as its own process in XTester Studio:

XTester Studio — Code - OSS / TypeScript
                    ↓ versioned local protocol
XTester EngineHost — C# / .NET
                    ↓
Data · Simulation · Execution · Research · Statistics

This is meant to prevent a heavy backtest from freezing the editor. EngineHost should be able to restart independently of the UI. Later, we will check whether EngineHost can also support Launcher, headless jobs and remote compute.

These are architecture requirements, not capabilities available today. They still need to be tested in the architecture spike and the first end-to-end backtest.

A strategy will be stored as a project

The current workflow often revolves around one selected source file. For Studio, we plan to use a multi-file Strategy Project. Studio will not have a standalone single-file strategy format: importing an individual file will create a project folder, manifest and standard structure:

MyStrategy/
├── xtester.strategy.json
├── src/
├── tests/
├── models/
├── resources/
└── README.md

The editor, Language Host and EngineHost should operate on the whole project. Git will track the source code, settings and additional files together. A backtest will fingerprint the project rather than only the open file.

Tests, models, parameters, Evidence and the Launcher Strategy Bundle can be added to the same format later. We will first validate the project model with a C# strategy.

Languages will be added in stages

We plan to support C# first because that is the simplest way to stay compatible with the existing engine and strategies.

After C#, we want to add Python for quantitative research, machine learning, NumPy and pandas. TypeScript/JavaScript comes later. We will only consider other languages after compatibility and consistent strategy behaviour have been demonstrated.

Each language will need its own Language Host and SDK. The trading engine will remain shared. Market data, time, orders, fills, fees, portfolio state, risk and statistics must behave the same regardless of the strategy language.

Preliminary first-milestone plan

At the first milestone, a user should be able to open a C# project, compile it, run a backtest and view the result in Studio.

The preliminary scope includes:

1. a standalone XTester Studio build;
2. startup on macOS Apple Silicon and Windows x64;
3. a multi-file C# Strategy Project;
4. project-wide compilation and diagnostics;
5. a separate XTester EngineHost;
6. simulation settings and the required market data;
7. an end-to-end backtest using the existing engine;
8. progress, logs and errors inside Studio;
9. a chart, trades, positions and core statistics;
10. workspace persistence and recovery;
11. installers and smoke tests on both platforms.

The exact scope will be clearer after the architecture spike. If a component takes longer than expected or calls the proposed architecture into question, we will move it to a later milestone.

The first milestone does not include AI Studio, Research Lab, MCP, strategy converters, the Python runtime, the TypeScript runtime, Paper, Controlled-Live or CopyTrader. We will focus first on stable C# strategies and backtests.

The current Windows version of XTester will continue to work. Studio will replace it gradually as features are moved and verified.

Why Code - OSS instead of the packaged Visual Studio Code product

Code - OSS and Visual Studio Code are not the same product.

Code - OSS is the open repository published under the MIT license. Visual Studio Code is Microsoft's packaged distribution with its own branding, product license and additional components.

XTester Studio will be built on Code - OSS. Microsoft branding, the Visual Studio Marketplace, proprietary services and third-party extension licenses do not automatically carry over. Extension distribution, updates and security will need to be managed separately. Extensions will only be added after a separate review of licensing, Marketplace terms, dependencies, executable code and technical compatibility with our distribution.

Target date for the first milestone

We are targeting October 1, 2026 for the first public milestone, not the complete migration of XTester.

Before release, we need to:

• build XTester Studio on macOS and Windows;
• run EngineHost separately from the UI;
• complete an end-to-end backtest of a multi-file C# strategy;
• display the chart and statistics produced by the engine;
• restore the workspace after restart;
• pass build, smoke and baseline parity checks on both platforms;
• prepare installers.

If these checks expose an architecture problem, we will change the first-milestone scope or date. We will not ship an empty shell simply to meet October 1.

The next practical step is the architecture spike. It needs to answer three questions: can Code - OSS be packaged as a standalone XTester product, can the existing engine run separately from WinForms, and can we complete the first end-to-end backtest on macOS and Windows?

Official Code - OSS references

• Microsoft/vscode — Code - OSS repository
• Source Code Organization
• VS Code Extension API
• Visual Studio Code FAQ: Code - OSS and Microsoft distribution