Case study

Gatelog

Proof-of-concept Windows installer and updater for a vehicle-log server stack.

C#
.NET
MongoDB
AWS S3

Source Code

In the product

Installing: The eight-step install mid-way: progress at 57% on Creating MongoDBUser, with a timestamped log of MongoDB, mongosh and Mosquitto being set up as services. — Installing. The eight-step install mid-way: progress at 57% on Creating MongoDBUser, with a timestamped log of MongoDB, mongosh and Mosquitto being set up as services.

Notice step: The proof-of-concept notice loaded from Setups/EULA.docx; Next unlocks once the checkbox is ticked. — Notice step. The proof-of-concept notice loaded from Setups/EULA.docx; Next unlocks once the checkbox is ticked.

Install location: Choosing where to install; the app creates a Gatelog folder under C:\Program Files by default. — Install location. Choosing where to install; the app creates a Gatelog folder under C:\Program Files by default.

Update step: When all four services exist: pick a newer release from the S3 bucket, compare component versions, and update each service in turn. — Update step. When all four services exist: pick a newer release from the S3 bucket, compare component versions, and update each service in turn.

Screens are recreated from the app’s real UI with fictional demo data.

The core problem

What needed solving

Setting up a vehicle-log server on a Windows machine meant installing a database, a broker, a portal and a bot by hand, then keeping each one running and up to date.

The solution

What I built

One wizard relaunches itself as administrator, shows a notice, asks for an install location, then runs an eight-step install with a live log that stops at the first failed step. Existing installs go straight to an S3-backed update screen that stops, replaces and restarts each service.

A C# WinForms (.NET 6) setup wizard that installs the server side of a number-plate-recognition vehicle-log system on Windows: MongoDB and mongosh, an Eclipse Mosquitto MQTT broker, a web portal and a detection bot, each registered as an auto-start Windows service with NSSM. When the services already exist it switches to an update screen that pulls newer component releases from an S3 bucket. It is a proof of concept: the installer payloads are not part of the repository.

Integration

How it fits together

A single .NET 6 WinForms app drives the whole setup. It relaunches itself as administrator, then steps through a notice, an install location and an eight-step install: MongoDB and mongosh are extracted, Mosquitto installs silently as a service, mongod is registered with authentication, a mongosh script creates the database user, and the portal and bot are registered with NSSM. An update path reads installed versions from config.json and pulls newer component zips from S3.

Gatelog architecture diagram — System architecture

The flow, step by step

Run the app on Windows; it relaunches itself with administrator rights.
Accept the notice and choose an install location (a Gatelog folder under C:\Program Files by default).
Follow the eight-step install and its timestamped log as each component is extracted and registered as a service.
On a machine where all four services exist, pick a newer release to update each component from S3.

Problems along the way

What got hard, and what I did about it

Four services, one wizard

The problem

Each component installs and registers differently, and the installer reported success even when a step failed.

What I did

Ran the install as ordered steps with a timestamped log and stopped at the first failed step instead of reporting completion.

Install or update

The problem

Running the full install again on a working machine would overwrite it.

What I did

Detected the four existing Windows services and sent those machines straight to an S3-backed update screen.

Hard-coded environment values

The problem

The S3 bucket, region and publish settings were baked into the code.

What I did

Moved them to environment variables so the proof of concept can point at any deployment.

Takeaways

What I learned

Installers need to fail loudly: a green "done" after a failed step costs more than an error.
Keeping environment-specific values in configuration makes a proof of concept reusable.

Outcome

Where it stands today

Eight-step install: MongoDB 7.0.1, mongosh 2.1.1, Mosquitto 2.0.18, an auth-enabled mongod service, and the portal and bot registered with NSSM.

Install-or-update detection based on the four installed Windows services.

S3 update channel comparing installed and available component versions.

Uninstall script that removes the services and the install folder.

Milestones

Install wizard
Elevated relaunch, notice, install location and the eight-step install with a live log.
Shipped
S3 update channel
Lists newer releases and updates each service in place.
Shipped
Rebrand and startup fix
Rebranded to Gatelog and fixed the startup crash.
Shipped
End-to-end test
A full install with real payload archives has not been run since the refresh.
Planned

Next up

Run an end-to-end install with real payload archives.
Check nssm, mongod and sc exit codes so a failed service is reported.

Next case study

WebGL Academic Presentation