Skip to content

SmrtHub Runtime Footprint

Status: Draft (2025-11-24) Owner: Platform Engineering / Build Governance

Purpose

Describe how binaries are built, staged, and launched across the SmrtHub desktop estate so every component follows a single deterministic layout. This is the canonical reference for tooling, CI, and documentation pages that talk about "where apps live" or "which Runtime Identifier is supported".

Supported architectures and RIDs

  • CPU: x64 only. All project files set <Platforms>x64</Platforms> and emit x64 binaries.
  • RuntimeIdentifier: win-x64 for every packaged output (Debug and Release). Passing any other RID is unsupported and should fail CI.
  • Configuration mapping: Solution configurations (Debug|Any CPU, Release|Any CPU) map to Debug|x64 and Release|x64 within each project. No project declares AnyCPU.

If another RID is required, update SmrtHub-Architecture_Platform_Policy.README.md first, then propagate to the build scripts.

Staging layout

All developer builds and CI outputs land inside Apps/<Configuration>/<RuntimeIdentifier>/ using the build scripts under Tools/Clean-Build/:

Apps/
└─ Debug/win-x64/
   ├─ ClipboardMonitor/ClipboardMonitor.exe
   ├─ HubWindow/HubWindow.exe
   ├─ TriggerManager/TriggerManager.exe
   ├─ SmrtHubSupervisor/SmrtHubSupervisor.exe
   └─ ...
  • BuildApps.ps1 -Scope <target> compiles the requested projects and copies artifacts (plus content files) into the tree above.
  • CleanApps.ps1 -TargetScope <scope> removes staged output so the next build starts clean.
  • Python packaging (SmrtApps/PythonApp/BuildPythonApp.ps1) drops its dist folder under Apps/<Configuration>/<RID>/PythonApp/ so the supervisor can locate the entry point alongside C# binaries.

Launch & discovery

  • HubWindow.exe and other UI apps are launched directly from the staged path when debugging.
  • SmrtHubSupervisor reads manifest tokens (see Apps/hostmanifest.json) to find each component relative to ${AppsRoot}.
  • Automation/diagnostic tooling must never infer install paths manually—always resolve via the manifest or Smrt.Config helpers so future path changes stay centralized.

Build tooling rules

  1. Always invoke builds via Tools/Clean-Build/BuildApps.ps1 (or the VS Code tasks that wrap it). MSBuild/dotnet build should only be used for quick IDE analysis, not official artifacts.
  2. Tests that depend on binaries reference ${AppsRoot} instead of writing to bin/ or obj/.
  3. Release packaging (MSIX, installers, PyInstaller bundles) originates from the staged outputs; no ad-hoc copy chains.
  4. Scripts that zip or publish results must preserve the <Configuration>/<RID>/<AppName>/ hierarchy so the supervisor and support bundle logic keep working.

When to update this document

  • A new executable or Python distribution needs to be staged differently.
  • We add support for another RID or CPU architecture.
  • Build scripts change their command surface or staging semantics.
  • Supervisor discovery manifests gain new requirements that affect directory layout.

Whenever this file changes, update the Architecture & Platform docs so they keep referencing the latest guidance.