Build & run from source

Development prerequisites#

Install the .NET 10 SDK and PowerShell if needed. Plan for substantial free disk space: self-contained x64/ARM64 builds include native dependencies and the Copilot runtime.

The repository's global.json selects .NET SDK 10.0.303, permits newer servicing patches within that feature band, rejects prerelease SDKs, and selects Microsoft Testing Platform. CI installs the same SDK baseline. dotnet-tools.json pins the vpk packaging tool. A Copilot account is needed only for optional live AI checks, not ordinary builds or local image tests.

Get the source and build#

If you do not have repository write access, fork it first and clone your fork instead of the upstream URL below.

git clone https://github.com/sebastienlevert/hotshot.git
Set-Location hotshot
dotnet build src\Hotshot.App\Hotshot.App.csproj -p:Platform=x64

The build restores its NuGet dependencies. There is no separate frontend package install.

Build the other architecture or a release configuration with:

dotnet build src\Hotshot.App\Hotshot.App.csproj -p:Platform=ARM64
dotnet build src\Hotshot.App\Hotshot.App.csproj -c Release -p:Platform=x64

ARM64 can be cross-built on x64. A successful cross-build does not establish runtime behavior on physical ARM64 hardware.

To build every .NET project, including the integration harnesses:

dotnet build Hotshot.slnx -c Release -p:Platform=x64 -m:1

The solution explicitly maps native platforms. The Product UI acceptance harness supports x64/ARM64; the remaining architecture-fixed interactive harnesses stay excluded from ARM64 solution builds. Cross-build the native app and MCP companion separately when checking ARM64 delivery. Serial solution builds avoid competing WinUI/XAML intermediate-file writers.

Enforced .NET quality bar#

Directory.Build.props and .editorconfig enforce C# 14, nullable reference types, .NET 10 Recommended analyzers, cancellation-token forwarding, correct ValueTask consumption, and warnings as errors. Managed compilation is deterministic; CI also normalizes compiler/source-path metadata. This does not claim byte-for-byte reproducible installer archives. A clean build is required, not a growing warning baseline.

Do not fix a failing gate by globally disabling a diagnostic. Correct the underlying ownership, cancellation, culture, allocation, visibility, or error-handling problem. The two window-level CA1001 annotations explain a genuine framework boundary: WinUI owns window lifetime, and Closed/operation finally blocks release resources. They are not blanket project suppressions.

Core and MCP disallow unsafe blocks. Native GDI ownership uses SafeHandle; COM/D3D/media buffers use deterministic ownership and exception-safe construction. Keep caller-owned objects distinct from owned resources, unwind workers before disposing their dependencies, and make repeated disposal safe.

UI work may resume on the dispatcher; reusable asynchronous IO must not require a UI synchronization context. Native event handlers may be async void, but launched operations must be observed and errors logged/reported at an explicit boundary rather than discovered later by garbage collection. Never block the dispatcher on .Result, .Wait() or synchronous task completion.

File publication must use a private, same-directory staging file, close it before replacement, honor cancellation before commit, preserve the previous destination on failure, and retain the original exception if cleanup also fails. Tests cover competing writes, cancellation, journal recovery, shared preference isolation, resource lifetimes, and encoder/decoder failures.

The app assembly owns Windows App SDK initialization for the Product/Agents integration hosts. Their own duplicate initializers are disabled and their entry points explicitly initialize the referenced app module; do not mask generated type conflicts with NoWarn.

Run a development copy safely#

Warning A normal development launch uses the real %AppData%\Hotshot profile. Debug mode is not an isolated sandbox. Back up settings/history and private originals before experimenting with persistence, migration, cleanup, or recovery.

Finish any recording or unsaved edits, then exit the installed tray app before launching a development copy. Otherwise, Hotshot's single-instance handling can forward your command to the already-running version.

To keep development preference changes out of your real OneDrive folder, set the process-local override before launching:

$env:HOTSHOT_SETTINGS_SYNC_MODE = 'local'
dotnet run --project src\Hotshot.App\Hotshot.App.csproj -p:Platform=x64

This disables OneDrive settings roaming for that launch; it does not isolate the local profile. The harnesses described below provide isolation where noted. Debug builds do not modify the Windows startup registration, and unmanaged development builds cannot auto-update themselves.

After exiting the development app, remove the override from that terminal before starting your normal installed copy:

Remove-Item Env:\HOTSHOT_SETTINGS_SYNC_MODE