# 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
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 then swaps the complete project tree into place, 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
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

```powershell
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.

```bash
./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.