Skip to content

Compiling yourself from source

Jump to bottom
Dennis edited this page Aug 27, 2026 · 3 revisions

Go to Wiki Home.

CRT is a .NET 10 / Avalonia desktop application and builds with the plain dotnet CLI on all three platforms. The build is identical everywhere — only how you install the .NET 10 SDK differs.

Contents

Before you start

You need the .NET 10 SDK (download or your package manager), Git, and about 2 GB free disk space. A newer SDK is fine — the project sets RollForward=LatestMajor.

Fork the CRT repository, then:

git clone https://github.com/<your-username>/Classic-Repair-Toolbox.git
cd Classic-Repair-Toolbox
dotnet --list-sdks

The last command must list a 10.x.x entry.

Quick start (any platform)

dotnet restore Classic-Repair-Toolbox.slnx
dotnet build   Classic-Repair-Toolbox.slnx -c Release
dotnet test    Classic-Repair-Toolbox.slnx -c Release

The application lands in bin/Release/net10.0/ — Classic-Repair-Toolbox.exe on Windows, Classic-Repair-Toolbox on Linux and macOS. To run from the source tree:

dotnet run --project Classic-Repair-Toolbox.csproj -c Release

build and test target the solution (.slnx) so the tests come along. run and publish target the project (.csproj), or you would publish the test project too.

Debug vs Release

Both configurations behave identically — same update check, same data sync, same diagnostics. Build Release for anything you intend to use or measure; Debug is JIT-only and starts slower.

The one build difference: Release treats compiler warnings as errors. Green in Debug and red in Release means a warning.

(Older versions faked an update banner and skipped the data sync in Debug builds. That is gone — use --simulate-update below instead.)

Command-line switches

Switch What it does
--data-root=<path> Use a different data folder instead of the default
--simulate-update[=<version>] Offer a fake update (default 99.0.0) so the update banner can be tested. The download is faked and the app does not restart.

Both work in Debug and Release.

--simulate-update requires "Check for new version at application launch" to be ticked in the Configuration tab — otherwise no update check runs at all and no banner appears. The log says so when this happens.

VS Code's F5 and the watch task already pass --simulate-update. Remove it from .vscode/launch.json and .vscode/tasks.json if you want the real update check.

Windows

Visual Studio — open Classic-Repair-Toolbox.slnx (needs a version new enough for .slnx and .NET 10), set the configuration to Release, then Build > Build Solution.

VS Code — with the C# Dev Kit extension you get the build task, the watch task (rebuild-and-restart on save), and F5 to debug. Both watch and F5 pass --simulate-update.

Command line

dotnet build Classic-Repair-Toolbox.slnx -c Release
bin\Release\net10.0\Classic-Repair-Toolbox.exe

Linux

Install the SDK — this is the only distro-specific part:

Distro Command
Fedora sudo dnf install dotnet-sdk-10.0
Debian / Ubuntu sudo apt install dotnet-sdk-10.0
Arch sudo pacman -S dotnet-sdk
Any distro curl -sSL https://dot.net/v1/dotnet-install.sh | bash -s -- --channel 10.0

The install script needs no root and puts the SDK in ~/.dotnet — add export PATH="$HOME/.dotnet:$PATH" to your shell profile.

Gentoo keeps several SDKs side by side, so select one:

eselect dotnet list          # show available versions
eselect dotnet set 1         # pick the .NET 10 profile
. /etc/profile               # reload environment

Verify with dotnet --list-sdks that you got 10.x, then:

dotnet build Classic-Repair-Toolbox.slnx -c Release
./bin/Release/net10.0/Classic-Repair-Toolbox

macOS

Install the SDK with the .pkg from dotnet.microsoft.com or brew install --cask dotnet-sdk, then:

dotnet build Classic-Repair-Toolbox.slnx -c Release
./bin/Release/net10.0/Classic-Repair-Toolbox

Two quirks:

  • You get a bare executable, not a .app bundle — the .app in official releases is made by Velopack during packaging. Running from Terminal works fine.
  • Local builds are not signed or notarised. If macOS refuses to start it: xattr -dr com.apple.quarantine ./bin/Release/net10.0/Classic-Repair-Toolbox

Use osx-arm64 for Apple Silicon and osx-x64 for Intel when publishing.

Self-contained builds

Bundles the .NET runtime so it runs without .NET installed. Note this is publish on the project file, and --self-contained requires -r:

dotnet publish Classic-Repair-Toolbox.csproj -c Release -f net10.0 -r <rid> --self-contained
Target <rid> Output
Windows x64 win-x64 bin/Release/net10.0/win-x64/publish/
Linux x64 linux-x64 bin/Release/net10.0/linux-x64/publish/
macOS Apple Silicon osx-arm64 bin/Release/net10.0/osx-arm64/publish/
macOS Intel osx-x64 bin/Release/net10.0/osx-x64/publish/

Add -o <folder> to choose the output folder. Passing -r also enables ReadyToRun — bigger and slower to build, noticeably quicker to launch. Cross-compiling works; only the macOS packaging step in CI needs a Mac.

Running the test suite

An xUnit suite covers the non-UI logic in Handlers/. No hardware, no network, no display, a few seconds:

dotnet test Classic-Repair-Toolbox.slnx -c Release

Every push runs the same suite on GitHub and a red suite blocks releases, so run it before sending a pull request. If you add or change logic, add or update the tests in the same change.

Where the hardware data comes from

The ~1 GB in Assets/Data is not copied into the build output — official installers bundle it, a source build does not. On first launch CRT creates its data folder and downloads from classic-repair-toolbox.dk.

Platform Data folder
Windows %LOCALAPPDATA%\Classic-Repair-Toolbox\Data
Linux / macOS ~/.local/share/Classic-Repair-Toolbox/Data
  • Already have CRT installed? Your build reuses the same folder and downloads nothing.
  • To seed it instead of downloading, copy Assets/Data next to the built executable before the first run.
  • To keep a build separate from your installed copy, use Classic-Repair-Toolbox --data-root=/path/to/other/Data.

The log sits alongside at Classic-Repair-Toolbox/Classic-Repair-Toolbox.log and records Data root is [...] on every start — the quickest way to see which folder a build is using.

The MiniPro IC programmer

Only the win-x64 build bundles a minipro binary (committed at Assets/MiniPro/win-x64/, copied next to the executable automatically).

On Linux and macOS, install minipro yourself (e.g. from the minipro project). CRT looks on PATH and in common install locations, or you can set an explicit path in the Configuration tab.

Troubleshooting

dotnet cannot find a .NET 10 SDK Run dotnet --list-sdks. No 10.x entry means it is not installed or not on PATH. On Gentoo, check you ran eselect dotnet set and re-sourced /etc/profile.

Green in Debug, red in Release Release treats warnings as errors. The first error in the log is a warning.

It keeps telling me version 99.0.0 is available You are running with --simulate-update. VS Code's F5 and watch task pass it by default — remove it from .vscode/launch.json and .vscode/tasks.json.

--simulate-update shows no banner Tick "Check for new version at application launch" in the Configuration tab. Without it no update check runs, so there is nothing for the simulation to answer. The log states this at startup.

Visual Studio will not open Classic-Repair-Toolbox.slnx The .slnx format needs a newer Visual Studio. Upgrade, or build from the command line.

Builds on Linux but exits immediately Avalonia needs fonts and ICU. On a minimal or container install add fontconfig and your distro's libicu package. Check the log for the real error.

Starts but there is no hardware data Expected on a first run from source — it is downloading. See Where the hardware data comes from.

Go to Wiki Home.

Clone this wiki locally