Belmont Labs  /  Experiments  /  Build Utility
EXPERIMENT // 04  // BL-004
● ACTIVE / STABLE

BUILD
UTILITY

The foundry. The forge. The crackling, humming, occasionally ominous machine room from which all other Belmont Labs experiments emerge, blinking, into the world. You do not question the foundry. The foundry questions you.

DOWNLOAD BUILD UTILITY GITHUB ↗ SCREENSHOTS ↗
LAB-SERVER-04>$ // BL-004 // BUILD UTILITY // FIELD REPORT
Researcher Notes // Field Observations

If the other experiments are the what, the Build Utility is the how. Experiment 04 is a guided installation wizard — a step-by-step fabrication system that knows what needs to be built, asks the right questions, and then builds it. No command lines. No guessing at flags. No standing in the blast shadow wondering what went wrong and when.

Select your experiments. Configure your targets. The Build Utility handles the rest — compiling .NET applications from source, downloading distributable packages, dropping files into the correct directories, and conjuring desktop shortcuts where appropriate. It is not magic. It is organized. Which at Belmont Labs is often more impressive.

The utility currently governs all packaging, compilation, and deployment workflows for the laboratory's active experiments. It knows what everything needs before they know they need it. Multi-project installs. Modify flows for already-installed experiments. Build type selection. Review screens that let you verify before you commit. This is either elegant foresight or something slightly more unsettling. The team is divided on which.

⚠ Chief Science Officer standing advisory: "The Build Utility is not a tool. It is an environment. It has opinions. When it asks you to review your selections on the Review screen, it is not a formality. It is an opportunity. Take the opportunity. The lab has not always taken the opportunity. The lab has learned."
ℹ Prerequisite Note — .NET 8 SDK Required

The Build Utility compiles .NET experiments from source and therefore requires a .NET 8 SDK to be installed on the machine running it. The SDK is not the runtime — the SDK is the thing that makes the runtime. The Build Utility will remind you of this if it detects the SDK is absent. This reminder is delivered without judgment. Almost without judgment.

Designation Build Utility
Experiment No. BL-004
Status ACTIVE / STABLE
Type Fabrication System
Platform Windows Only
Runtime .NET 8.0
SDK Required .NET 8 SDK
Hazard Rating HANDLE WITH CARE
Awareness ELEVATED
Scope FULL ECOSYSTEM
Disposition METHODICAL
Observation Log
BL-004-2B Pipeline stage 3 optimized. Build time reduced 40%.
BL-004-11A Utility pre-loaded deps before request. Studying.
BL-004-19F Multi-project install tested. All three experiments. Simultaneously. It worked.
BL-004-27D Review screen skipped by researcher. Outcome discussed at debrief.
BL-004-33C Everything built correctly. No further comment.
01

What It Does
In Plain Language

The following is a simplified account for those who prefer their fabrication systems explainable and their installation wizards to complete without incident.

◈
Guided Wizard Interface
The Build Utility is a step-by-step Windows Forms wizard. It walks you through project selection, per-project configuration, a full review screen, and then execution — in that order, every time, without deviation. The wizard does not skip steps. The wizard has seen what happens when steps are skipped.
◈
Multi-Project Support
Select one experiment or all of them. The utility builds a configuration screen for each selected project in sequence — WhoDAT AddOn, SyncDAT, WhoDASH Dashboard — before proceeding to a unified review and a single installation run. One wizard. Multiple deliverables. The wizard handles the scheduling.
◈
.NET Build Pipeline
For .NET experiments, the utility invokes the full dotnet publish pipeline with your selected build configuration — Self-Contained, Framework-Dependent, or Self-Contained with ReadyToRun optimization. It knows the flags. You do not need to know the flags.
◈
Web Downloads
For experiments distributed as pre-built packages — like the WhoDAT AddOn Lua files or WhoDASH — the utility downloads the latest release directly from a configured URL, extracts it, and places it where it belongs. No manual downloads. No manual extraction. No wondering where things went.
◈
Shortcut Creation
After a successful build, the utility creates Desktop and Start Menu shortcuts for applicable applications — configurable per project, per install. If you want the shortcut, it places the shortcut. If you do not want the shortcut, it refrains. The utility does not have opinions about your desktop organization. Externally.
◈
Modify & Reinstall
Already installed an experiment? The utility detects this and presents a Modify screen instead of a fresh configuration flow. Reinstall in place, change the install directory, or update to a newer build — without needing to manually remove anything first. The utility knows the difference between new and known.
◈
Live Progress Reporting
During installation, a dedicated progress screen displays each pipeline stage in real time — Preparing, Building, Copying, Creating Shortcuts, Finalizing. Color-coded. Timestamped. The progress screen does not speculate. It reports what is happening as it happens, accurately, without embellishment.
◈
Apps Manifest System
All available experiments are defined in a centralized apps-manifest.json — including source paths, build configurations, download URLs, install defaults, and dependency declarations. Adding a new experiment to the Build Utility requires updating the manifest. The manifest is the source of truth. The manifest does not argue.
◈
Review Before Commit
Before anything is built or copied, the utility presents a full review screen summarizing every selected project, every configured path, and every chosen option. This is the moment to verify. This is the moment the Chief Science Officer has requested, in writing, that all personnel use. The screen waits patiently.
02

The Wizard
Flow

Five stages. Sequential. Each one waiting for the previous. The wizard is patient. The wizard has nowhere else to be. Complete the steps in order. The wizard strongly prefers this.

01
Stage One
Welcome & Prerequisites
The Build Utility opens to a Welcome screen that confirms prerequisites are met — specifically that a .NET 8 SDK is present and detectable on the machine. This check is performed silently, at launch, before you have touched anything. If the SDK is missing, the utility will say so. It will not proceed until the SDK is there. This is not stubbornness. This is an accurate assessment of what compilation requires.
02
Stage Two
Project Selection
Select the experiments you want to build or install. The Project Selection screen reads from the apps-manifest.json and presents all available experiments — currently the WhoDAT AddOn, SyncDAT, and WhoDASH Dashboard. Already-installed experiments are flagged as such. Select one or several. The wizard adapts to your selections before proceeding. It does not require you to do this in a particular order. It does appreciate tidiness, though.
03
Stage Three
Per-Project Configuration
For each selected experiment, the wizard presents a dedicated configuration screen. Set the install directory. Choose your build type for .NET projects — Self-Contained (no runtime install required, larger file), Framework-Dependent (smaller file, requires .NET 8 runtime on target), or Self-Contained with ReadyToRun (pre-compiled for faster cold start, platform-specific). Toggle shortcuts on or off. The wizard then moves to the next selected project's config screen. It does this for as many projects as you selected. The wizard is patient.
04
Stage Four
Review & Confirm
Before any files are touched, the Review screen displays a complete summary of everything the wizard is about to do — every project, every install path, every build type, every shortcut configuration. Read it. Verify it. Confirm when satisfied. The Install button does not activate until you arrive at this screen and press it deliberately.

The lab records indicate that the Review screen has prevented at least four significant incidents. The lab does not share details about the incidents. The incidents inform the emphasis on this step.
05
Stage Five
Build, Install & Complete
The Installation Progress screen takes over. For each project, the pipeline executes its designated stages — building from source or downloading a release package, copying files to the install directory, and creating any configured shortcuts. Progress is displayed in real time, color-coded by stage, with a running log of each completed action.

On completion, the Completion screen summarizes what was installed and where. At this point the work is done. The utility has built the things. The things exist now. The utility waits to be closed or restarted for another run.
⚙
If Already Installed
Modify Flow
When the Project Selection screen detects an already-installed experiment, it routes that project through a Modify Installed App screen rather than a fresh configuration screen. From here: reinstall in the current location, change the install path, update to a newer build, or remove desktop and Start Menu shortcuts.

The Modify flow plugs back into the standard Review and Installation stages. Everything after the configuration step behaves identically whether you are installing fresh or updating. The wizard does not distinguish between these philosophically. It only distinguishes between them procedurally.
⚠   System Requirements & Notes

The Build Utility is a Windows-only application built on the .NET 8 Windows Forms platform. This is because the experiments it builds also target Windows, the toolchain it invokes is Windows-hosted, and the shortcuts it creates are Windows shortcuts. The lab considered other platforms briefly. The consideration was brief.

Unlike the experiments it produces, the Build Utility itself is distributed as a framework-dependent build — meaning the .NET 8 Runtime must be present on the machine running it. This is a deliberate choice: the machine running a build tool almost certainly has a .NET SDK installed already, which includes the runtime. The lab found it circular to self-contain a tool that exists to invoke .NET. The lab stands by this reasoning.

To build .NET experiments from source, the .NET 8 SDK is required — not just the runtime. The SDK is available from Microsoft at no cost. The utility's Welcome screen will detect its presence and inform you if it is absent. It will not invent a workaround. There is no workaround. The SDK compiles things. Without the SDK, nothing is compiled. This has been confirmed.

Configuration and installation state is maintained in memory during the wizard session and does not persist between runs. Close the utility and reopen it, and the wizard begins fresh. This is intentional. Each installation run is a discrete, deliberate act. The Build Utility does not accumulate state. It accumulates results.

✓ Windows 10 / 11Fully supported
✓ .NET 8 SDKRequired for builds
✗ macOS / LinuxNot supported
      BL-004 BUILD UTILITY: STATUS NOMINAL  ⋮  PIPELINE: STANDING BY — AWAITING PROJECT SELECTION  ⋮  .NET 8 SDK: DETECTED. COMPILATION IS AUTHORIZED.  ⋮  SYNCDAT: LAST BUILD SUCCESSFUL. SELF-CONTAINED. 68 MB. THE LAB NOTES THE SIZE. THE LAB ACCEPTS THE SIZE.  ⋮  WHODASH: DOWNLOAD STAGE COMPLETE. FILES IN PLACE. DASHBOARD OPERATIONAL.  ⋮  REVIEW SCREEN REMINDER: IT IS THERE FOR A REASON. THE REASON IS DOCUMENTED.  ⋮  MULTI-PROJECT INSTALL: AVAILABLE. TESTED. ENDORSED. DO NOT SKIP THE REVIEW.  ⋮  READYTORUN OPTIMIZATION: ENABLED ON LAST BUILD. COLD START IMPROVED 22%. THE LAB IS PLEASED. BRIEFLY.  ⋮  BUILD UTILITY: WATCHING. WAITING. READY. THE FORGE DOES NOT SLEEP.  ⋮