WSC-MVC

A small, WSC-first MVC framework for Classic ASP on IIS: VBScript Windows Script Components registered as COM, dispatched by a single thin Default.asp bootstrap. See SPEC.md for the full contract, IMPLEMENTATION_PLAN.md for milestone status, and docs/ for architecture, decisions, and test evidence — those are the authoritative, kept-current docs; this file is just an orientation map.

Layout

Two separate IIS sites sharing only the framework components:

• public/ — the production site's IIS physical path. GET / and GET /hello both reach the hello route.
• test-app/public/ — a separate site where GET / and GET /self-test return the JSON test harness, so diagnostics aren't reachable on the production site/port. See docs/ARCHITECTURE.md.
• Framework/ — shared WSC components, registered once via COM and used by both sites.
• Controllers/ — production-owned controllers; test-app/Controllers/ — test-app-owned controllers. Neither app can activate the other's routes, including through direct Default.asp?route=... requests. None of these source folders is served over HTTP.
• logs/, test-app/logs/ — each site's own runtime log, written by the app, never served over HTTP.
• tests/, tools/, docs/ — test scripts, deployment/registration tooling, and documentation. Never served over HTTP.

Deploy

Remote transactional deployment

Run the controller from a Windows checkout with Git, OpenSSH ssh/scp, and existing key or agent authentication for the target. It never accepts or stores credentials. The remote account must be elevated and the target must have Windows PowerShell 5.1, IIS, Classic ASP, URL Rewrite, and the WebAdministration module.

powershell -File tools\Deploy-Remote.ps1 `
  -RemoteHost Administrator@win2025test `
  -RemoteProjectPath C:\Projects\wsc-mvc `
  -ProductionSiteName WscMvc -ProductionPoolName WscMvc -ProductionPort 8090 `
  -ProductionBaseUrl http://localhost:8090 `
  -TestSiteName WscMvcTests -TestPoolName WscMvcTests -TestPort 8091 `
  -TestBaseUrl http://localhost:8091 `
  -RunTests

The controller packages only paths reported by git ls-files, so new deployment files must be tracked before using it. -PullOriginMaster optionally runs git pull --ff-only origin master and refuses a dirty worktree; it is never implicit. The controller reports a SHA-256 digest and the remote installer verifies it before changing the target. The remote preflight also validates the archive, target path, IIS site ownership, app-pool ownership, binding conflicts, and global COM registration ownership. It refuses partial or foreign ProgID/CLSID state rather than overwriting it. It stops only the two project-owned sites/pools, mirrors the current tree to a timestamped rollback directory, mirrors the verified release into the stable live path, registers every WSC (including WscMvc.ViewRenderer), and reconciles both IIS sites through Setup-Site.ps1.

When replacing an existing project tree, the prior tree is retained as <RemoteProjectPath>.rollback.<UTC timestamp>-<id>. If registration, IIS reconciliation, or optional tests fail, the installer restores that tree, re-registers its components, restores pre-existing site run states, and removes only sites/app pools created by that invocation. It refuses to adopt mismatched IIS resources and does not alter unrelated sites, pools, or bindings.

With -RunTests, deployment succeeds only after the WSH component suite, IIS HTTP suite, and JSON self-test client all pass. Omit it to deploy without those post-cutover checks. Base URLs are used by the optional tests and may differ from the binding ports when local DNS or host headers require it.

Direct setup on the target host

powershell -File tools\Register-Components.ps1
powershell -File tools\Setup-Site.ps1
powershell -File tools\Setup-Site.ps1 -SiteName WscMvcTests -PoolName WscMvcTests -PhysicalPath <repo>\test-app\public -Port 8091

Both Setup-Site.ps1 invocations are idempotent for project-owned resources.

Test

cscript //nologo tests\Test-Components.vbs          # WSH smoke test, no IIS needed
powershell -File tests\Test-Http.ps1 -BaseUrl http://localhost:8090 -TestBaseUrl http://localhost:8091
powershell -File tests\Invoke-SelfTest.ps1 -BaseUrl http://localhost:8091

Invoke-SelfTest.ps1 calls /self-test, parses its JSON, prints every reported check as PASS or FAIL, confirms the test-site root also returns a passing self-test, and confirms direct Default.asp?route=/hello access returns 404. It exits nonzero for any request, contract, check, root-mapping, or route-isolation failure.

./tests/run-self-test.sh http://<host>:8091          # test-app site, plain curl+JSON, any CLI

Status

M0–M4 gated PASS with real test evidence on Windows/IIS; see docs/TEST-RESULTS.md. M5 (data) is the next framework milestone; the deployment tooling contributes to the later M6/M7 operational gates but is not live-host verified by this README alone.