Stop-WebAppPool only requests a stop - the w3wp.exe worker process can
keep running for a few seconds afterwards, still holding the site's
files open, so the previous fix (stopping both sites before the wipe)
wasn't sufficient on its own.
- Wait-AppPoolFullyStopped: polls app pool state until Stopped (30s
timeout), then force-kills any lingering w3wp.exe for that pool
- Remove-DirectoryContentsWithRetry: retries the wipe a few times with
a short delay, since file handles can take a moment to release even
after the worker process is confirmed gone
The admin site's physical path lives inside RemoteDir (RemoteDir\public-admin).
On a redeploy it was still running while RemoteDir was wiped, so IIS held its
files open and Remove-Item failed with Access is denied. Now both the public
and admin site/app pool are stopped up front, before the wipe.
- New AdminOrdersController + view: table of Orders with search by
email/jurisdiction #, pagination (20/page), and per-row mailto link
to resend the order-continue URL
- OrdersRepository: add GetAll() and SearchPaged() (LIKE search,
PagedQuery-based pagination)
- MailtoEncode helper added to core/helpers.asp (mailto-safe URL
encoding: %20 not +)
- Controller registered in autoload + ControllerRegistry
- public-admin/ folder: dedicated Default.asp routes, web.config with
192.168.1.0/24 ipSecurity, production template with same restriction
- applicationhost.config: second IIS Express site (Admin Web Site,
port 8081)
- run_site.cmd: launches both sites (public in separate window,
admin in foreground)
- build-release.ps1: public-admin in allow-list, swaps its
web.config from production template
- deploy-iis-remote-apply.ps1: optional admin site/app-pool config
+ restart
- deploy-iis.ps1: -AdminSiteName/-AdminAppPool/-AdminBaseUrl params,
admin smoke test
- scp/ssh now force a fallback to password auth so a missing/rejected
key fails with a real prompt instead of an opaque "Permission denied
(publickey)".
- Smoke test now checks each path against its expected status (/404 is
expected to 404) instead of treating any non-throwing response as a
pass, and surfaces the actual failure reason.
- The remote IIS server has the 64-bit Access Database Engine, unlike
the local dev machine, so its app pool stays 64-bit and migrations
run through the plain (64-bit) cscript.exe instead of SysWOW64.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
- .gitattributes + an explicit allow-list in build-release.ps1 assemble a
clean release tree (app/, core/, public/, scripts/, db/migrations only) -
anything not on the allow-list is deleted from the deploy, so a stray
file added later can't ship to production by accident.
- public/web.config.production.template holds the production appSettings
(DB path outside the deploy dir, Environment=Production, error logging on).
- deploy-iis.ps1 builds, zips, and scp's a release to the IIS host, then
runs deploy-iis-remote-apply.ps1 there over ssh to swap in the new files,
run migrations, and restart the site/app pool - the DB and error log live
outside the deploy directory so a redeploy never touches them.
- Removed deploy-iis-git.ps1 and migrate_isbusiness_to_households.vbs,
leftovers from a different template project that didn't apply here.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Daniel Covington