# Releasing TeamsISO

The release workflow at `.forgejo/workflows/release.yml` runs on **annotated tag pushes
matching `v*.*.*`**. It builds, tests, publishes, packages an MSI, and uploads the
MSI as a release asset.

## Prerequisites

- A **Windows runner** registered to this Forgejo instance. WiX MSI builds require
  Windows; the existing CI runs on Linux for unit tests, but releases need a
  separate Windows runner. Register one with `forgejo-runner register` against a
  Windows host that has the .NET 8 SDK + WiX SDK access (the WiX SDK pulls itself
  via NuGet at build time, so no separate install).
- The repository's **Create release on tag push** setting on (default), or skip it —
  the workflow will create the release if one doesn't exist.

## Cutting a release

```sh
# Bump the version in Directory.Build.props if you haven't already.
git tag -a v1.0.0 -m "TeamsISO 1.0.0"
git push origin v1.0.0
```

The workflow will:

1. Restore + build `TeamsISO.Windows.slnf` in Release with the tag's version.
2. Run unit tests (the `requires=ndi` integration tier is skipped — it needs a
   real NDI runtime which a CI runner won't have).
3. Publish `TeamsISO.App` and `TeamsISO.Console` for `win-x64`,
   framework-dependent (.NET 8 Desktop runtime is the user's responsibility).
4. Build `installer/TeamsISO.Installer.wixproj`, producing
   `TeamsISO-Setup-<version>.msi`.
5. Upload the MSI as a workflow artifact (downloadable from the run page).
6. Attach the MSI to the GitHub-style Release for the tag, creating the release
   first if it doesn't exist. Pre-release flag is set automatically when the
   tag contains `-alpha`, `-beta`, or `-rc`.

## Code signing (TODO)

The `wixproj` has a `SignOutput` property hook but no actual cert wiring. For a
v1.0 release, sign the MSI with an EV cert before publishing:

1. Add a `SIGNING_CERT_BASE64` and `SIGNING_CERT_PASSWORD` to repo Secrets.
2. Decode the cert into the runner's cert store at the start of the workflow.
3. Set `/p:SignOutput=true` on the `dotnet build` of the wixproj and configure
   `signtool` invocation (the installer project will need a custom target).

Until that lands, downstream users will see the standard Windows SmartScreen
warning on first launch — annoying but not blocking for early adopters.