Skip to content

Compiling yourself

Jump to bottom
Dennis edited this page Aug 26, 2026 · 5 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 itself is identical everywhere — the only thing that really differs between operating systems is how you install the .NET 10 SDK.

Contents

Before you start

You need:

  • .NET 10 SDK — install it from your package manager, or download it from dotnet.microsoft.com. A newer SDK is fine too; the project sets RollForward=LatestMajor.
  • Git
  • Roughly 2 GB of free disk space for a plain build, more if you publish self-contained builds for several platforms.

Then fork the CRT repository and clone your fork:

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

Verify the SDK is found:

dotnet --list-sdks

You should see 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/:

Platform Executable
Windows bin\Release\net10.0\Classic-Repair-Toolbox.exe
Linux / macOS bin/Release/net10.0/Classic-Repair-Toolbox

You can also run it straight from the source tree:

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

Note the two different targets. dotnet build and dotnet test are pointed at the solution (Classic-Repair-Toolbox.slnx) so the unit tests are built and run too. dotnet publish and dotnet run are pointed at the project (Classic-Repair-Toolbox.csproj) — publishing the solution would drag the test project along with it.

Always build RELEASE

Build Release unless you are actively debugging. Debug builds deliberately fake two things so the UI can be worked on without a server round-trip, and they will confuse you if you forget:

Debug behaviour Controlled by (in Main/App.axaml.cs)
Never checks for a real update online; always shows a dummy update banner for version 99.0.0 AppConfig.DebugSimulateUpdate
Simulates the online data sync instead of performing the real one AppConfig.DebugSimulateSync

Flip those constants if you need different behaviour locally.

One more difference worth knowing: Release treats compiler warnings as errors (Debug does not, so a half-finished edit does not break your F5 loop). If your build is green in Debug and red in Release, a warning is the likely reason.

Windows

Visual Studio

  • Open Classic-Repair-Toolbox.slnx. You need a Visual Studio version new enough to open an .slnx solution and to target .NET 10 — if yours cannot, use the CLI or VS Code route instead, which always works.
  • Switch the configuration drop-down from Debug to Release
  • Build > Build Solution
  • The executable is bin\Release\net10.0\Classic-Repair-Toolbox.exe

VS Code

The repository ships with .vscode/tasks.json and .vscode/launch.json, so with the C# Dev Kit extension installed you get:

  • build task — dotnet build on the solution
  • watch task — dotnet watch run, rebuilding and restarting on every save
  • F5 — builds and launches the Debug build under the debugger

Command line

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

Linux

Installing the .NET 10 SDK

This is the only distro-specific part. Everything after it is the same everywhere.

Fedora

sudo dnf install dotnet-sdk-10.0

Debian / Ubuntu

sudo apt install dotnet-sdk-10.0

If your release does not carry a .NET 10 package yet, use Microsoft's install script (below).

Arch

sudo pacman -S dotnet-sdk

Check with dotnet --list-sdks that you actually got 10.x and not an older SDK.

Gentoo

Gentoo can have several SDKs installed side by side, so you have to select the right one:

eselect dotnet list          # show all available .NET SDK versions
eselect dotnet set 1         # pick the .NET 10 profile - (1) in this example
. /etc/profile               # reload the system environment variables
dotnet --list-sdks           # verify the active SDK is 10.x

Any distro — Microsoft's install script

Works everywhere and needs no root; it installs into ~/.dotnet:

curl -sSL https://dot.net/v1/dotnet-install.sh | bash -s -- --channel 10.0
export PATH="$HOME/.dotnet:$PATH"

Add that export to your shell profile to make it stick.

Building and running

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

If the application builds but will not start, see Troubleshooting — on a minimal system you are usually missing fontconfig or ICU.

macOS

The build is the same as everywhere else; only the SDK install and the run step have a couple of macOS quirks.

  • Install the .NET 10 SDK — either the .pkg installer from dotnet.microsoft.com, or Homebrew: 
    brew install --cask dotnet-sdk
    Confirm you got 10.x with dotnet --list-sdks.
  • Build: 
    dotnet build Classic-Repair-Toolbox.slnx -c Release
  • Run it from Terminal: 
    ./bin/Release/net10.0/Classic-Repair-Toolbox

Two things to be aware of:

  • A plain dotnet build or dotnet publish gives you a bare executable, not a .app bundle. The .app in the official releases is produced by Velopack during packaging, not by the build. Launching the bare executable from Terminal works fine.
  • Locally built binaries are not signed or notarised. Running from Terminal is normally untroubled, but if macOS refuses to start it, clear the quarantine flag: 
    xattr -dr com.apple.quarantine ./bin/Release/net10.0/Classic-Repair-Toolbox

Pick the matching architecture if you go on to publish a self-contained build: osx-arm64 for Apple Silicon, osx-x64 for Intel.

Self-contained builds

A self-contained build bundles the .NET runtime, so it runs on a machine with no .NET installed. This is what the official releases are built from. Note that it is dotnet publish on the project file, and that --self-contained requires a runtime identifier (-r):

dotnet publish Classic-Repair-Toolbox.csproj -c Release -f net10.0 -r <rid> --self-contained
Target <rid> Output folder
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/

Use -o <folder> if you would rather choose the output folder yourself.

Passing -r also turns on ReadyToRun, which ahead-of-time compiles the app and the bundled runtime. It makes the build bigger and slower to produce, but noticeably quicker to launch — the right trade for an app that already ships around 1 GB of hardware data. A publish without -r skips it.

Cross-compiling works: you can publish linux-x64 from Windows, and so on. Only the macOS packaging step in CI genuinely needs a Mac.

Running the test suite

There is an xUnit suite covering the non-UI logic in Handlers/. It needs no oscilloscope, no MiniPro programmer, no network and no display, and finishes in a couple of seconds:

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

Every push runs the same suite on GitHub, and a red suite blocks releases — so if you intend to send a pull request, run it locally first. If you add or change logic, add or update the tests in the same change.

Where the hardware data comes from

The ~1 GB of schematics, component data and images in Assets/Data is not copied into the build output. The official installers bundle it; a build from source does not. So on first launch CRT will create its data folder and download everything from classic-repair-toolbox.dk.

The data folder lives outside the build folder, next to the log file:

Platform Location
Windows %LOCALAPPDATA%\Classic-Repair-Toolbox\Data
Linux / macOS ~/.local/share/Classic-Repair-Toolbox/Data

Three things follow from that:

  • If you already have CRT installed, your build reuses the same data folder and downloads nothing. Only a folder that does not yet exist triggers the first-run download.
  • You can seed it instead of downloading, exactly the way the release pipeline does, by copying Assets/Data next to the built executable before the first run — it is then copied into the data folder on startup.
  • You can point a build at its own data folder, and leave your installed copy alone, with the command-line switch: 
    Classic-Repair-Toolbox --data-root=/path/to/some/other/Data

The log file sits alongside, at Classic-Repair-Toolbox/Classic-Repair-Toolbox.log. It records the resolved data root on every start (Data root is [...]), which is the quickest way to confirm which folder a given build is actually using.

The MiniPro IC programmer

Only the win-x64 build bundles a minipro binary — it is committed at Assets/MiniPro/win-x64/ and copied next to the executable automatically on a Windows build.

On Linux and macOS nothing is bundled. CRT looks for minipro on PATH and in the common install locations, so install it yourself (for example from the minipro project). You can also point CRT at a specific binary with the MiniPro path override in the Configuration tab.

Troubleshooting

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

The build is green in Debug and red in Release Release treats warnings as errors. Read the first error in the log — it will be a warning.

Visual Studio will not open Classic-Repair-Toolbox.slnx The solution uses the newer XML solution format. Either upgrade Visual Studio, or build from the command line — the CLI does not care.

The app builds on Linux but exits immediately or crashes on startup Avalonia needs fonts and ICU present. On a minimal or container install, add fontconfig (and the libicu package for your distro), then try again. Check the log file for the real error.

The app starts but there is no hardware data That is expected on a first run from source — it is downloading. Watch the splash screen, and check the log if it seems stuck. See Where the hardware data comes from.

It keeps telling me version 99.0.0 is available You built Debug. Build Release. See Always build RELEASE.

Go to Wiki Home.

Clone this wiki locally