Installer package build and install

Before building

Installer work should start from validated source and explicit release inputs. Treat the package as a reproducible delivery artifact: know what commit it came from, what environment it targets, and which files are intentionally included.

• Run packaging and install commands from an elevated Windows Administrator session.
• Use the local source repository at C:\dev\Buffaly.Development.
• Confirm PowerShell execution policy allows local scripts.
• Have required packaging and deployment secrets available through the approved secret path, not copied into package content.
• Confirm the branch, version, package root, and target install root before copying files.
• Exclude local secrets, logs, temporary files, and development-only overrides from package inputs.

Expected package shape

Validate the package root before install. A release package can be a folder or zip, but the extracted root should contain the release binaries, template configuration, manifest, and install/provision scripts.

$pkg = "C:\drop\Buffaly\MyLatestPackage"
$required = @(
  "bin",
  "config-template\appsettings.template.json",
  "manifest\release-manifest.json",
  "scripts\install_files.ps1",
  "scripts\provision_semanticdb.ps1",
  "scripts\provision_buffaly_instance.ps1"
)
$required | ForEach-Object {
  $path = Join-Path $pkg $_
  "{0} => {1}" -f $_, (Test-Path $path)
}

Install and verify commands

Run install commands from elevated PowerShell. The wiki workflow separates file placement from database and instance provisioning so operators can validate each phase.

Set-Location C:\dev\Buffaly.Development\Scripts
.\install_files.ps1 `
  -PackageRoot "C:\drop\Buffaly\MyLatestPackage" `
  -InstanceName "BuffalyStagingLocal" `
  -SiteName "Buffaly.BuffalyStagingLocal" `
  -AppPoolName "Buffaly.BuffalyStagingLocal" `
  -Port 58210 `
  -HostName "buffaly-staging.local" `
  -SqlServer "localhost" `
  -SemanticDatabaseName "buffaly_semanticdb_buffalystaginglocal" `
  -SessionsDatabaseName "buffaly_sessions_buffalystaginglocal" `
  -ForceReinstall

Import-Module WebAdministration
Get-Website "Buffaly.BuffalyStagingLocal" | Select Name,State,PhysicalPath,ApplicationPool
(Get-Item "IIS:\AppPools\Buffaly.BuffalyStagingLocal").state
(Invoke-WebRequest "http://buffaly-staging.local:58210/" -UseBasicParsing).StatusCode

Restart-WebAppPool -Name "Buffaly.BuffalyStagingLocal"
(Get-Item "IIS:\AppPools\Buffaly.BuffalyStagingLocal").state

Supported script flags

Use the scripts as the source of truth for final syntax. These summaries keep the public guide readable while preserving the operational flag coverage from the package reference.

Database provisioning is a second phase

After install-only completes, run instance provisioning explicitly. Use CreateNew for a new local instance and UseExisting when both databases already exist and should be verified without overwrite.

.\provision_buffaly_instance.ps1 `
  -InstanceName "BuffalyStagingLocal" `
  -InstallRoot "C:\inetpub\BuffalyInstances\BuffalyStagingLocal" `
  -SqlServer "localhost\SQLEXPRESS2025" `
  -EntitiesDatabaseName "buffaly_semanticdb_buffalystaginglocal" `
  -SessionsDatabaseName "buffaly_sessions_buffalystaginglocal" `
  -Mode CreateNew `
  -UseWindowsAuth

ProtoScript content after deployment

By default, an installed site reads ProtoScript from deployed release content. If package content is stale, ProtoScript behavior will be stale too unless settings intentionally override the project paths.

Release evidence

Keep evidence for later troubleshooting. The package should be traceable back to the commit, build command, package path, install target, provisioning mode, app pool state, and route checks that proved it worked.

A useful request is: ask Buffaly to build the installer, name the package path, install or inspect it in the target layout, provision or verify databases, and report the route or service check that proves the installed result works.

• Record package path, version, manifest, and install target.
• Record build, install, provisioning, app pool, and launch results.
• Capture any manual steps that should become automated later.

Troubleshooting checks

• Confirm PackageRoot contains the expected files and scripts before install.
• Confirm the installed file layout points to the intended install root and release marker.
• Confirm app settings ProtoScript paths are set as expected for deployed content, fast sync, or development override.
• If SQL errors appear, validate connection strings, database names, Windows authentication, and database user mappings.