See interoperability and setup readiness for client/server status and verified offline packages.
A native Windows application for installing, updating and launching six production tools from JohnDevAc's GitHub releases.
Version 1.4.0 adds coordinated lifecycle maintenance and recovery. Stable releases are built from main; development prereleases are built from dev with a -dev version suffix.
Copyright © 2026 John Lightfoot. All rights reserved. Proprietary software, free for non-commercial use. Commercial use requires a separate written licence. Public source availability does not make this an open-source licence. See LICENSE.md.
Download Production-Toolkit-1.4.0-win-x64-Setup.exe from the latest release and run it. Setup installs Production Toolkit for your Windows account, creates desktop and Start menu shortcuts, and adds an entry to Settings → Apps → Installed apps with an uninstaller. The default location is %LOCALAPPDATA%\Programs\Production Toolkit; a custom location can be selected and will be reused by updates.
The Windows x64 application is self-contained: no separate .NET installation, browser runtime, Python or Node.js is required. Production Toolkit installs and updates without administrator elevation; installers for the managed applications may request it. Users of the earlier portable releases should run this installer once and then use the installed shortcuts. Local builds are in artifacts/release; portable executable and ZIP downloads remain available as secondary options.
On startup, and when you select Check for updates, the toolkit checks its own GitHub repository for a newer Windows installer in its current channel. Stable Toolkit builds follow stable releases; development builds follow development prereleases. Neither channel falls back to the other. If one is available, choose Update and restart or Later. Downloads can be cancelled. The installer is not started until its size, GitHub SHA-256 digest and embedded semantic product version and numeric Windows file version match the selected release. Failed checks or downloads leave the existing application usable; no periodic polling runs.
Setup asks the running installation to close gracefully once it is ready to replace its files. It retains the installation directory, settings and download/icon caches, replaces the executable, updates the same Windows app entry and shortcuts, and relaunches the installed version. A normal installer run also closes and relaunches an open copy. Active managed-app downloads and installers must finish or be cancelled before maintenance can proceed. Failed or cancelled setup attempts reopen the surviving version when Setup had closed it. Older installers are blocked from downgrading a newer app. Windows is never automatically rebooted.
Uninstall through Windows Installed apps or the installed unins000.exe. Uninstall closes the toolkit and removes its program files, registration and shortcuts. Settings, caches and user-created files are retained. The six production applications managed by the toolkit remain independently installed.
The default cards show the app name/icon, version and short status, with the relevant Install, Update or Launch action. Uninstall stays directly accessible. Details contains release channels, release information, diagnostics and less frequent maintenance actions:
- Stable / Development selection under Details, remembered separately for each application.
- The installed version and a simple Up to date or Needs updating status; the latest published version is under Details.
- Install, Update, or Switch version, according to the detected installation. When the installed version is current, the update button disappears and Launch or Open setup fills the action row. Incomplete installations still offer Complete setup.
- Launch for installed applications; Open setup for Environment Setup.
- Repair under Details and Uninstall use the application's own maintenance workflow. Recheck inspects supported products and reconciles interrupted operations. Repair/Recheck become visible outside Details when needed. Missing release channels, unsupported packages and missing verification digests have a short reason and an Open releases link.
- Matching layouts with colours derived from each application's icon.
When NDI Job Configurator is not installed locally, startup also searches connected IPv4 networks for a running instance. Each verified server gets an Open web UI · address link below Install. Links appear as servers respond; release checks and the other cards remain usable. Check for updates repeats discovery and clears stale results, and each link is checked again before opening in your default browser. The read-only search probes TCP 8091 on complete /20–/30 subnets, with bounded concurrency, short request deadlines and a four-minute overall limit. Unsupported networks and partial scans are reported. It does not need internet or save remote results between launches.
Local detection runs independently from release and remote-icon checks, so a slow or unavailable GitHub connection does not disable installed applications. After maintenance, all cards refresh their local versions and readiness without another GitHub request. Finish or reconcile one maintenance operation before starting another; downloads remain cancellable. Toolkit does not accept licences or select Environment roles on your behalf.
For an installed but unconfigured PC Agent, Complete setup opens its matching native Setup wizard to choose the adapter. Toolkit tracks that window through elevation and rechecks configuration and running state afterward; closing or cancelling the wizard does not count as completion. The explicit Repair action keeps the Agent's package-only maintenance behavior. For a partial Environment role, Complete setup requests ordinary installation so the owner can retain healthy components; explicit Repair still requests its full repair workflow.
Supported owners report a correlated durable operation result. A parent process closing, exit zero alone, or closing Toolkit does not establish success. Pending results and restart requirements survive Toolkit restart. Recheck can release an unconfirmed attempt only when the owner confirms no active operation and no unresolved recovery; the original attempt remains unconfirmed in the journal. Older installers retain their normal interactive workflow and are labelled as unable to confirm completion or health. Older products without a safe registered uninstaller open Windows Installed apps. Unknown or malformed capability metadata blocks maintenance with an explanation.
| Card | Repository | Package and launch behavior |
|---|---|---|
| Kiloview Environment Setup | Kiloview-Environment-Setup | Prefers the complete lifecycle ZIP. Detects the installed configuration app, retained ProgramData/KiloLink/Maintenance, and the legacy Launcher. Retained maintenance remains accessible after app removal. |
| NDI Job Configurator | Kiloview-Job-Configurator | Uses the full Windows ZIP with its advertised adapter, or the verified official EXE for older releases. Launch uses its installed PowerShell launcher to start the scheduled service and open the browser. |
| Resolume Arena Configurator | Resolume-Configurator | Uses the full verified ZIP for new lifecycle maintenance, with official Setup fallback for older releases. Retained maintenance supports inspection and removal. |
| NDI Configurator PC Agent | Kiloview-PC-Onboarding | Downloads the complete self-contained ZIP, extracts the entire payload and runs its Setup executable. Launch starts the installed tray agent. Recognizes legacy Kiloview branding. |
| UDP to NDI | udp-to-ndi | Uses the official Windows x64 Setup executable. Detects its per-user installation and launches UDP to NDI. Its installer handles FFmpeg and NDI Runtime prerequisites. |
| Test Card Generator | TestCardGen | Verifies and extracts the complete portable ZIP, including its worker and private .NET runtime. Install prepares the app; Launch opens TestCard. NDI Runtime and FFmpeg are separate dependencies for network outputs. |
Test Card Generator is stored in %LOCALAPPDATA%\Production Toolkit\Applications\testcard, separately from the download cache. A durable receipt under Receipts records its active copy, retained previous copies and packaged file inventory independently of UI preferences. Each update or repair stages a fresh complete folder before atomically switching that receipt; failed activation retains the previous selection. Missing or truncated packaged files show Repair required and disable Launch. Repair can use the recorded verified cached ZIP offline. TestCard's NDI Runtime and FFmpeg remain separate output prerequisites; preview uses its packaged private runtime.
Uninstall removes only validated Toolkit-owned package folders after checking that TestCard and its worker are stopped. A locked file leaves a retryable partial removal; Recheck is read-only. TestCard settings in %LOCALAPPDATA%\TestCardGen, shared runtimes and unrelated files remain. Previous package copies are retained until explicit TestCard uninstall; uninstalling Toolkit itself retains them. Toolkit never starts TestCard or an output while installing, repairing or inspecting it.
Repair checks the product's own recovery state. If an interrupted operation requires a complete package, Toolkit verifies the selected package and its version before opening repair. It preserves data and stops if the package is unavailable, older or cannot be verified. Healthy installations can still use their retained repair tools offline. Partial removal keeps recovery controls available even when application executables are missing.
PC Agent files alone do not mean setup is complete. The toolkit checks the current Windows account's saved agent configuration and the matching installed Setup utility. Missing, unreadable or invalid configuration shows Setup incomplete and offers Complete setup, even when the installed version is current. A complete matching local package can finish setup offline without another download. If Setup is missing or mismatched, the toolkit offers the complete selected release package; recovery does not downgrade a newer installed agent. Setup retains its normal licence, adapter selection and UAC flow. When it closes, the card rereads configuration before enabling Launch. A disconnected production adapter does not imply an incomplete installation.
The PC Agent card also shows Running or Not running. Launch is disabled while the detected agent is running in the current Windows session and becomes available again when it exits, provided setup is complete. A lightweight local process check refreshes every two seconds while Toolkit is open, when returning to its window, and before and after launch. It matches the installed executable's full path using Windows limited-query access; an unrelated program with the same name or an agent in another desktop session does not disable Launch when its identity can be verified. If Windows prevents verification, the card shows Running status unavailable and keeps Launch disabled until a later check confirms it has stopped. These checks do not contact GitHub or change agent configuration.
Environment separates Setup launcher version from Client/Server component readiness. The role summary and component rows show installed/configured/runtime evidence. Both Environment and the PC Agent card use the same matching-pair and saved-configuration rules; a disconnected network does not erase configured state. Retained maintenance after configuration-app removal enables maintenance without claiming the app is installed. Environment's owner selects role once; generic Uninstall opens its role-removal review with data retention enabled. App-only removal and runtime maintenance remain explicit choices in the owner workflow.
The environment check reads Setup's configuration, the managed WSL registration and KiloLink container, startup watchdog, NDI Tools registration and launcher, and NDI Discovery executable/service or task. Component rows show the container's running state and web response, the installed NDI Tools version, and whether Discovery is running and owns its listening port. Hover the status or component rows for diagnostic details and the local check time. A stopped service can still be fully installed; an unreadable or stopped WSL environment is labelled Installation not verified when its container cannot be inspected. Pending setup continuation is reported as partial.
When no environment components are detected, its card uses the simple Install view even if the setup executable has already been downloaded. Install or Complete setup can reuse that executable. Successful downloads are retained even if the elevation prompt is cancelled. The installed launcher determines its version and update status; a newer download cannot hide an unapplied update. If only a verified download exists, it remains available offline without claiming an installed version. Open Setup to update or repair the underlying server and NDI products; the toolkit does not claim their versions are current just because the setup download is current.
Environment detection is read-only, runs only at startup or Check for updates, and has a 20-second limit. It does not elevate, start Windows services or scheduled tasks, or start Docker/containers. Docker inspection runs only when the managed WSL distribution is already reported running. It never calls the upstream installer to discover state.
- Stable excludes drafts and prereleases, including legacy
-devtags incorrectly marked stable by GitHub. Development uses published prereleases; it does not build branch source or retrieve GitHub Actions artifacts. - The latest release is selected by publication date, with pagination. An unavailable development release never falls back to stable. Releases without a recognized installer show that limitation.
- Installed versions are reread from executable product metadata during each check, preserving development identifiers. Apps updated internally, replaced in place or removed outside the toolkit are detected on the next check. Registered installation folders, standard paths and locations saved by earlier toolkit versions are supported. Build metadata does not affect comparisons; Windows versions such as
1.3.2.0matchv1.3.2. Unknown versions are reported explicitly. - Channel changes are explicit. A newer locally installed version is not silently downgraded. Where stable and development publish the exact same SHA-256 package, that equivalent package counts as current in either channel.
- For the retained Environment Setup executable, a saved release tag is used only when its SHA-256 still matches that release. A newer persistent launcher takes precedence over an older saved setup; at equal versions the persistent launcher is preferred.
- Successful installer exit alone is not proof of installation. The next startup or explicit update check rereads the actual local version. Failures and restart-required exit codes remain visible.
- If GitHub is offline or rate-limited, saved release information remains available. The update-status tooltip gives its original check time and explains when the comparison uses a previous check. Previously installed applications remain launchable.
- Rapid restarts reuse successful release checks for ten minutes. Check for updates can refresh sooner, but repeated clicks within one minute reuse the last result. Installed versions and icons are still read on startup and each explicit check. The toolkit's own release check uses the same cache and request queue as the six app cards.
- GitHub API requests run one at a time. A rate limit pauses all remaining API requests until GitHub's reset or
Retry-Afterdeadline; that deadline survives restarting the toolkit. Expiry never starts an automatic retry: reopen the toolkit or click Check for updates afterward. GitHub's unauthenticated allowance is shared by applications using the same public IP, so other software can still exhaust it. See GitHub's rate-limit documentation.
Preferences, release snapshots, icon cache, the activity log and verified download cache are in:
%LOCALAPPDATA%\Production Toolkit
Installers are fetched directly from the six projects' GitHub release URLs. Package size and GitHub's SHA-256 digest must match before an installer can run. Releases without a digest require manual installation via their Releases page. Downloads write to temporary files first; failures remove incomplete cache files. ZIP extraction rejects traversal, absolute paths, alternate streams, reserved Windows names, symlinks, duplicate paths and excessive extraction sizes.
Downloaded applications are not bundled into the wrapper. Operations/<GUID> holds request, result and Toolkit journal files with a protected user/SYSTEM/Administrators write ACL. Keep pending operations and their referenced recovery files until the owner reconciles them. Cached recovery adapters are checked for changes before reuse. Verified ordinary downloads can be removed when no operation needs them; do not clear Operations, Receipts or installed application folders as a cache-cleaning step.
The executable is currently unsigned. Windows may show its standard publisher or SmartScreen prompt.
The WPF application declares Per-Monitor V2 DPI awareness, uses logical pixel layouts, native controls, layout rounding and scalable typography. At startup it measures the complete UI, including the title bar and window borders, and chooses a size that shows all six cards without scrolling when the current monitor's work area allows. It tries a wider window when that reduces wrapping. It checks the size once more after loading release details, provided the user has not resized the window in the meantime.
On desktops too small to hold the complete UI, the window stays within the work area and retains vertical scrolling so every control remains accessible. The layout uses three columns at 1,500 logical pixels and above, two below 1,500, and one below 1,000. Buttons have keyboard focus states, text labels and standard tab navigation; status is conveyed with both text and colour. The footer identifies John Lightfoot's copyright and the non-commercial licence.
Each application uses its own icon. At startup and during update checks, the toolkit extracts the current icon directly from the installed executable without launching it or relying on the Windows shell icon cache. If no installed icon is available, it retrieves the project icon at the selected release tag. HTTP ETags and an on-disk cache preserve working icons when offline; embedded upstream icons are the final fallback. Repository icon paths are listed in Catalog.cs; if a project moves an icon to a different path, the bundled fallback remains available until that mapping is updated.
Cards share consistent controls, spacing and equal column widths, with matching heights within each row. Uninstalled cards use the simpler large-icon layout. The dominant icon colour supplies tinted card backgrounds, panels and borders, plus matching buttons and progress bars. Text contrast is maintained by darkening the button colour; monochrome icons receive a neutral palette. A changed icon automatically regenerates the palette during the same check. Green/amber version-status colours retain their usual meanings. Selecting a different channel changes version comparisons immediately; its icon is reread during the next update check.
The wrapper has an original toolkit icon, supplied as an editable SVG and an ICO with 16, 20, 24, 32, 40, 48, 64, 96, 128 and 256 pixel images. Cards select the largest available icon frame for scaling.
The UI review runner renders the actual WPF view at 100%, 150%, 200% and 250%, plus narrower 720- and 640-pixel layouts. It checks startup sizes against simulated monitor work areas, the absence of scrollbars when the UI fits, equal card widths, control containment, overlapping buttons, and WPF binding errors. Review images use illustrative version states. This verifies rendering and layout; moving the app between physical monitors with different DPI still deserves a hardware acceptance check.
Build on Windows with the .NET 8 SDK:
.\scripts\Build.ps1This runs the offline regression/UI suite and builds a Windows installer, standalone Production.Toolkit.exe, distributable ZIP and checksums in artifacts/release. The installed executable and ZIP entry remain Production Toolkit.exe. scripts/Test-Release.ps1 verifies the exact upload filenames, payload hashes and ZIP entries after building and again before release publication. The build downloads a pinned, SHA-256-verified Inno Setup 6.7.3 compiler into artifacts/tools when needed. No third-party NuGet dependencies are used. CI runs the same Windows build plus the installer lifecycle test, and retains release artifacts, UI review images and installer logs.
Pushing a version tag such as v1.2.0 runs that same build and publishes a GitHub Release only after the checks pass. The tag must match the version in Directory.Build.props. Release downloads include the installer, executable, ZIP, SHA-256 checksums and licence notices. Future installers must retain AppId=JohnLightfoot.ProductionToolkit and the Production-Toolkit-VERSION-win-x64-Setup.exe filename pattern for in-place updates.
Development launch:
dotnet run --project .\src\ToolkitLauncherRun tests and create review images:
dotnet run --project .\tests\ToolkitLauncher.Tests -c Release -- --ui artifacts\ui-reviewOptional live icon check for the current stable and development releases of all six projects:
dotnet run --project .\tests\ToolkitLauncher.Tests -c Release -- --live-iconsTest a real install, shortcut targets, an upgrade of a running older copy, relaunch, downgrade protection and uninstall:
.\scripts\Test-Installer.ps1The lifecycle test builds an older-version fixture, installs it under a unique test identity and workspace directory, and removes its registration and test shortcuts afterward. All test launches, fixture shortcuts and installer relaunches use --skip-startup-checks --isolated-test-state, keeping checks offline and preferences in the fixture installation's qa-state directory. No test-copy source edit is required. The normal installer and shortcuts use standard startup checks and the normal per-user state directory. The test does not install any of the managed production applications. Logs remain in artifacts/installer-test. Physical monitor transitions and Windows policy-specific installation restrictions still require hardware acceptance testing.
Optional live integration check (downloads roughly 350 MB of current stable packages into a temporary directory, verifies and prepares them, and removes the test data; it does not execute installers):
dotnet run --project .\tests\ToolkitLauncher.Tests -c Release -- --liveRegenerate the wrapper's original raster icon from its matching vector geometry:
.\scripts\Build-Icon.ps1Upstream installer execution and changes to real services, network adapters, scheduled tasks and application data should be acceptance-tested on a disposable Windows machine. The automated suite never makes those changes.
See THIRD-PARTY-NOTICES.md for icon provenance and upstream terms.