These scripts are developer, operator, and release helpers for local source runs, repository maintenance, and CSharpDB daemon release packaging.

The local start scripts launch dotnet run processes from the repo and update the admin app config so the web UI starts in the expected transport mode. Daemon service install scripts live under deploy/daemon and are included in daemon release archives.

The release and local workflow notes are grouped by audience:

• Release maintainers use scripts/Publish-CSharpDbDaemonRelease.ps1 directly for local packaging checks. The GitHub Release workflow also uses this script when a v* tag is pushed.
• Store release maintainers use scripts/Publish-CSharpDbAdminStorePackage.ps1 on Windows to produce the CSharpDB Studio MSIX and .msixupload artifacts for Partner Center.
• Mac/Linux Studio direct-download packaging remains planned future work. It uses a native launcher plus the user's default browser instead of an embedded WebView shell.
• Operators use the service scripts after a release is published. These scripts are included inside each daemon archive under service/.
• Developers use Start-CSharpDbAdminAndDaemon.ps1 and Start-CSharpDbAdminDirect.ps1 for local source runs. Developers can also use Start-CSharpDbAdminFormsWeb.ps1 when they only need the runtime form host. These are not release packaging scripts.

Use this path before tagging or when validating release packaging locally.

1. Build and test the repo as usual.

dotnet build CSharpDB.slnx -c Release
dotnet test tests\CSharpDB.Daemon.Tests\CSharpDB.Daemon.Tests.csproj -c Release

2. Publish one local archive for a fast packaging check.

.\scripts\Publish-CSharpDbDaemonRelease.ps1 `
  -Version 3.4.0 `
  -Runtime win-x64 `
  -OutputRoot artifacts\daemon-release-local

3. Confirm the archive and checksum exist.

Get-ChildItem artifacts\daemon-release-local\archives
Get-Content artifacts\daemon-release-local\archives\SHA256SUMS.txt

4. For the real release, push a v* tag. The GitHub Release workflow publishes the daemon archives for win-x64, linux-x64, and osx-arm64, smoke-starts each extracted binary, calls the daemon REST /api/info endpoint, verifies a gRPC GetInfoAsync client call, combines checksums, and attaches everything to the GitHub Release.

git tag v3.4.0
git push origin v3.4.0

Use this path after a GitHub Release is published.

1. Download the daemon archive for the target OS: csharpdb-daemon-v{version}-win-x64.zip, csharpdb-daemon-v{version}-linux-x64.tar.gz, or csharpdb-daemon-v{version}-osx-arm64.tar.gz.
2. Verify the archive with the published SHA256SUMS.txt.
3. Extract the archive on the target machine.
4. Run the matching service installer from inside the extracted archive.
5. Connect REST clients to http://127.0.0.1:5820/api/... or gRPC clients to the same base URL. The installed daemon exposes both transports by default.

Windows, from an elevated PowerShell session:

.\service\windows\install-csharpdb-daemon.ps1 -Start

Linux:

sudo ./service/linux/install-csharpdb-daemon.sh --start

macOS:

sudo ./service/macos/install-csharpdb-daemon.sh --start

To upgrade, extract the newer archive and rerun the same installer with the same data directory plus -Force on Windows or --force on Linux/macOS. The installers replace daemon files but do not delete the database directory.

To disable the daemon REST surface while keeping gRPC enabled, set CSharpDB__Daemon__EnableRestApi=false in the service environment or generated appsettings.Production.json, then restart the service.

Use this when the GitHub Actions run history has become noisy and you want to delete older completed runs.

What it does:

• resolves the GitHub repository from the local origin remote by default
• enumerates workflow runs through the GitHub CLI
• deletes only completed runs older than the configured cutoff
• supports -WhatIf and -Confirm for safe dry runs

Example:

& .\scripts\Clear-GitHubWorkflowRuns.ps1 -OlderThanDays 7
& .\scripts\Clear-GitHubWorkflowRuns.ps1 -OlderThanDays 30 -WhatIf

Use this when the admin site should talk to the gRPC daemon.

What it does:

• reads the daemon launch URL from src/CSharpDB.Daemon/Properties/launchSettings.json
• reads the daemon database connection string from src/CSharpDB.Daemon/appsettings.json
• updates src/CSharpDB.Admin/appsettings.json to:
  • set CSharpDB.Transport = "grpc"
  • set CSharpDB.Endpoint to the daemon base URL
  • copy the daemon connection string into ConnectionStrings:CSharpDB
• starts CSharpDB.Daemon
• waits for the daemon port to come up
• starts CSharpDB.Admin

The daemon started by this script also serves the REST /api surface on the same base URL unless CSharpDB:Daemon:EnableRestApi is disabled.

Use this when the admin site should open a local database directly without the daemon.

What it does:

• updates src/CSharpDB.Admin/appsettings.json to:
  • set CSharpDB.Transport = "direct"
  • remove CSharpDB.Endpoint
  • keep or set ConnectionStrings:CSharpDB
• starts only CSharpDB.Admin

The default Admin direct configuration uses CSharpDB:HostDatabase:OpenMode = "HybridIncrementalDurable", so direct mode opens through the hybrid incremental-durable local host path. The Admin host warms one in-process database instance at startup and keeps it alive until the Admin app shuts down or the user switches databases. Set CSharpDB:HostDatabase:OpenMode = "Direct" if you need the older plain direct open path for a local run.

Use this when you want to run stored forms through the forms-only runtime host without opening the full Admin studio.

What it does:

• reads the default target database path from src/CSharpDB.Admin.Forms.Web/appsettings.json unless you pass -DataSource
• starts src/CSharpDB.Admin.Forms.Web
• passes the resolved CSharpDB:DataSource and --urls values through command-line configuration overrides
• waits for the forms host port to accept TCP connections
• optionally opens the root runtime page in the default browser

Use a sample database that already contains seeded forms, such as the Fulfillment Hub sample database, when you want the runtime root page to list real forms immediately.

Use this when preparing self-contained daemon release archives.

What it does:

• publishes src/CSharpDB.Daemon for one or more runtime identifiers
• uses Release, self-contained, single-file, non-trimmed publish settings
• stages the daemon with service assets from deploy/daemon
• creates csharpdb-daemon-v{version}-{rid}.zip for Windows
• creates csharpdb-daemon-v{version}-{rid}.tar.gz for Linux/macOS
• writes SHA256SUMS.txt

Examples:

.\scripts\Publish-CSharpDbDaemonRelease.ps1 -Version 3.4.0 -Runtime win-x64
.\scripts\Publish-CSharpDbDaemonRelease.ps1 -Version 3.4.0 -Runtime linux-x64,osx-arm64

Default runtimes:

• win-x64
• linux-x64
• osx-arm64

Outputs are written under artifacts\daemon-release unless -OutputRoot is provided.

Use this on Windows when preparing the Microsoft Store package for CSharpDB Studio.

What it does:

• publishes src/CSharpDB.Admin self-contained for win-x64
• publishes the WPF/WebView2 desktop shell from src/CSharpDB.Admin.Desktop
• copies the Admin host into artifacts\admin-store\publish\desktop\admin so CSharpDB.Admin.Desktop.exe can be smoke-tested before packaging
• stages the Admin host under the desktop shell's private admin folder
• creates app visual assets from the existing Admin icon
• signs the MSIX with a local test certificate by default and exports the public .cer beside the package
• emits a local .msix and Store .msixupload under artifacts\admin-store

Example:

.\scripts\Publish-CSharpDbAdminStorePackage.ps1 -Version 3.4.0

For local App Installer testing, import the exported test certificate from an elevated PowerShell session before double-clicking the .msix:

Import-Certificate `
  -FilePath artifacts\admin-store\packages\csharpdb-studio-v3.4.0-win-x64-local-test.cer `
  -CertStoreLocation Cert:\LocalMachine\TrustedPeople

You can also run the packaging script from an elevated PowerShell session with -TrustLocalTestCertificate to perform that import automatically. Use -SkipSigning only for packaging diagnostics; unsigned MSIX files cannot be installed directly with App Installer.

The package identity starts as MaxAkbar.CSharpDBStudio with publisher CN=MaxAkbar; associate the package with Partner Center before submission so the final Store identity and publisher are applied.

Release archives include OS service assets under service/:

• Windows: service/windows/install-csharpdb-daemon.ps1
• Windows: service/windows/uninstall-csharpdb-daemon.ps1
• Linux: service/linux/csharpdb-daemon.service
• Linux: service/linux/install-csharpdb-daemon.sh
• Linux: service/linux/uninstall-csharpdb-daemon.sh
• macOS: service/macos/com.csharpdb.daemon.plist
• macOS: service/macos/install-csharpdb-daemon.sh
• macOS: service/macos/uninstall-csharpdb-daemon.sh

Default service settings:

Installers accept service name, install directory, data directory, bind URL, and force/overwrite options. Windows scripts support -WhatIf; Linux and macOS scripts require sudo and fail early when not run as root.

The generated production config enables REST by default through CSharpDB:Daemon:EnableRestApi=true. Service-level environment variables can override this with CSharpDB__Daemon__EnableRestApi=false.

From the repo root in PowerShell:

& .\scripts\Start-CSharpDbAdminAndDaemon.ps1

Start the admin in direct mode:

& .\scripts\Start-CSharpDbAdminDirect.ps1

Start the forms-only runtime host against the Fulfillment Hub sample database:

& .\scripts\Start-CSharpDbAdminFormsWeb.ps1 `
  -DataSource samples\fulfillment-hub\bin\Debug\net10.0\fulfillment-hub-demo.db `
  -OpenBrowser

Open the admin site automatically after startup:

& .\scripts\Start-CSharpDbAdminAndDaemon.ps1 -OpenAdmin

Use a specific direct-mode database:

& .\scripts\Start-CSharpDbAdminDirect.ps1 -ConnectionString "Data Source=C:\data\demo.db"

Both scripts rewrite src/CSharpDB.Admin/appsettings.json.

That means:

• the current admin transport mode persists after the script exits
• if you switch between gRPC mode and direct mode, the last script you ran wins
• if you have local edits in src/CSharpDB.Admin/appsettings.json, the script may overwrite those transport-related settings

The daemon script does not modify src/CSharpDB.Daemon/appsettings.json. It only reads from it.

Use -PassThru so PowerShell returns the host PIDs:

$session = & .\scripts\Start-CSharpDbAdminAndDaemon.ps1 -PassThru
$session

Example output object:

DaemonEndpoint : https://localhost:49995
AdminUrl       : https://localhost:61816
DaemonPid      : 12345
AdminPid       : 23456

Stop both hosts:

Stop-Process -Id $session.AdminPid, $session.DaemonPid

For direct mode:

$session = & .\scripts\Start-CSharpDbAdminDirect.ps1 -PassThru
Stop-Process -Id $session.AdminPid

Find the running host processes by command line:

Get-CimInstance Win32_Process |
  Where-Object {
    $_.Name -eq 'dotnet.exe' -and
    $_.CommandLine -match 'CSharpDB.Admin|CSharpDB.Daemon'
  } |
  Select-Object ProcessId, CommandLine

Stop them:

Get-CimInstance Win32_Process |
  Where-Object {
    $_.Name -eq 'dotnet.exe' -and
    $_.CommandLine -match 'CSharpDB.Admin|CSharpDB.Daemon'
  } |
  ForEach-Object { Stop-Process -Id $_.ProcessId }

Update config only without starting any process:

& .\scripts\Start-CSharpDbAdminAndDaemon.ps1 -NoLaunch
& .\scripts\Start-CSharpDbAdminDirect.ps1 -NoLaunch

This is useful when you want to inspect the config change first.

Open the admin URL in the default browser after startup succeeds:

& .\scripts\Start-CSharpDbAdminAndDaemon.ps1 -OpenAdmin

Return the resolved URLs and PIDs:

& .\scripts\Start-CSharpDbAdminAndDaemon.ps1 -PassThru
& .\scripts\Start-CSharpDbAdminDirect.ps1 -PassThru

If your machine is slow or the first build is cold, increase the wait time:

& .\scripts\Start-CSharpDbAdminAndDaemon.ps1 `
  -DaemonStartupTimeoutSeconds 60 `
  -AdminStartupTimeoutSeconds 60

The admin-and-daemon startup script resolves values from the repo files below:

• daemon URL: src/CSharpDB.Daemon/Properties/launchSettings.json
• daemon database connection string: src/CSharpDB.Daemon/appsettings.json
• admin URL: src/CSharpDB.Admin/Properties/launchSettings.json

The direct-mode script resolves values from:

• admin URL: src/CSharpDB.Admin/Properties/launchSettings.json
• admin database connection string: src/CSharpDB.Admin/appsettings.json, unless you pass -ConnectionString

The forms-runtime script resolves values from:

• forms host database path: src/CSharpDB.Admin.Forms.Web/appsettings.json, unless you pass -DataSource
• forms host URL: the script -Url parameter, defaulting to http://127.0.0.1:5095

Both scripts now include comment-based help:

Get-Help .\scripts\Start-CSharpDbAdminAndDaemon.ps1 -Detailed
Get-Help .\scripts\Start-CSharpDbAdminDirect.ps1 -Detailed
Get-Help .\scripts\Start-CSharpDbAdminFormsWeb.ps1 -Detailed

Check the current values in src/CSharpDB.Admin/appsettings.json:

• CSharpDB.Transport
• CSharpDB.Endpoint
• ConnectionStrings:CSharpDB

Run the appropriate script again with -NoLaunch if you want to confirm the config update without starting the hosts.

Check:

• the daemon launch URL in src/CSharpDB.Daemon/Properties/launchSettings.json
• whether another process is already using that port
• whether HTTPS development certificates or local firewall rules are blocking the host startup

That is expected. The scripts use Start-Process, so the launched dotnet processes keep running until you stop them explicitly.