Development and Releases

Development and Releases

This page describes how to build and validate vSMR 2.0 source. End users should install a complete published package, not a raw source checkout. Source version metadata does not mean that a new development change is available in the release or update feed.

Build

Use Windows, Visual Studio C++ tools with MFC support, a Windows SDK and the project's required toolset/libraries. The build script defaults to v145, Release | Win32. Microsoft Edge is required for browser regressions.

From the repository root:

powershell -NoProfile -ExecutionPolicy Bypass -File .\vSMR\tools\build_project.ps1

The script checks generated Control Center assets, restores dependencies, rebuilds the solution, then runs native and browser tests.

After building, run tests independently with:

powershell -NoProfile -ExecutionPolicy Bypass -File .\vSMR\tests\run_tests.ps1

Current validation status

Release-input checks enforce consistent product versions, reviewed hashes of the bundled GeoJSON inventory (160 airport maps and the separate LFPO works variant), stable feature/group identities and an update policy that does not delete a bundled airport. Re-run the inventory/default generation and regressions whenever AVISO data changes; old fixtures do not validate new geometry.

Run the complete native, browser and packaging regressions for the exact release commit. A previous development run is not a substitute for validating the final build. Do not disable tests to conceal a failure.

EuroScope 3.2.3.2 has been reported working by the maintainer. EuroScope 3.2.9 and 3.2.13 have not been runtime-validated; the experimental compatibility changes were reverted. Successful compilation alone does not establish host-version compatibility.

Source and installed filenames

Project-owned C++/C#/resource files use PascalCase, with Owner.Feature.cpp for split units. JavaScript/CSS use kebab-case; scripts, source JSON, sounds and cursors use descriptive snake_case. ICAO identifiers, third-party files, license notices and public binary names retain their established names.

The shared DistributionAssets.props maps source names to the installed paths expected by loaders and migration code:

Source under vSMR/data/	Installed under vSMR_Data/
aircraft_types.json	ICAO_Aircraft.json
holding_points.json	airports_hp.json
profile_templates.json	vSMR_Profiles.json
aviso_update_policy.json	AVISO-UPDATE-POLICY.json
Audio/timer_alarm.wav	Audio/Alarm.wav
Audio/cpdlc_notification.wav	Audio/Ding.wav

These are source renames, not instructions to rename installed files. The legacy profile-template file is excluded from the managed per-file feed. Configuration filenames and stable profile identities are unchanged.

Keep includes, project entries, generators and tests aligned when renaming files. The regression suite includes test_file_naming.ps1 and test_distribution_assets.ps1. Source naming conventions are maintained in README.

The application repository contains README.md, CHANGELOG.md, and technical notes under docs/. This separate wiki holds the detailed user manual. Bundled license and dependency notices are under vSMR/data/Licenses/.

Release preparation

Before publishing a new version:

1. Keep product metadata, package parameters, AVISO inventory/policy and CI settings aligned with the version being released. Loader version and runtime ABI are versioned separately.
2. Run the complete required validation and inspect the generated Win32 package and its bundled license notices.
3. Build from a clean commit contained in main. Signing is optional; explicitly configured signer pins or -RequireSignature still enforce signing. Preserve the matching symbols archive for crash diagnosis.
4. Set the changelog date, create the matching tag, and publish the release with the complete Win32 ZIP and its update metadata.
5. Publish the separately generated per-file stable feed from the same source. A push to main or a GitHub release alone does not publish that feed.

The packager is fail-closed. Explicit non-publishable validation packages are not production releases and must not be used to bypass required validation or signing checks.

Per-file feed generation

vSMR/tools/build_config_defaults.ps1 generates default.json from the profile templates and official AVISO hashes. Regenerate after changing those inputs, keeping stable IDs intact.

vSMR/tools/create_update_feed.ps1 -Phase Prepare builds/tests and stages the managed payload. In a separate update-feed checkout, commit the exact payload bytes first, then use -Phase Manifest -ContentCommit <full-40-character-payload-commit> to generate the channel manifest. Keep payload/** -text in that checkout's .gitattributes to avoid byte conversion. Publish the payload before the manifest.

See the complete staging commands for required arguments. Preparation is not publication. Validation-only artifacts and their version.validation-only.json must not be promoted to a public feed.

Documentation checks

Keep wiki controls, token sources, screenshots and package instructions aligned with the source/package being described. Home records the source snapshot; the project changelog maintains version history and GitHub Releases lists published packages. Older screenshots are examples only; remove or replace any that show removed controls.

The wiki is a separate Git repository (https://github.com/IWantPizzaa/vSMR.wiki.git). A documentation push does not modify application main/dev or publish a release/feed. Update the Home page's development-versus-release status when those changes become available in a published package.