Consolidated ASP Classic MVC framework from best components
Nie możesz wybrać więcej, niż 25 tematów Tematy muszą się zaczynać od litery lub cyfry, mogą zawierać myślniki ('-') i mogą mieć do 35 znaków.
Clawdbot 203b7d76ff ci: isolate deployment from existing IIS sites 5 godzin temu
app Refactor project into generic starter template 5 miesięcy temu
core Refactor project into generic starter template 5 miesięcy temu
db Consolidate best ASP MVC framework components 5 miesięcy temu
docs ci: isolate deployment from existing IIS sites 5 godzin temu
public Refactor project into generic starter template 5 miesięcy temu
scripts ci: add host-side IIS release installer 8 godzin temu
tests Testing and harness are complete 6 miesięcy temu
.gitignore Docs and test Implementation 6 miesięcy temu
README.md ci: isolate deployment from existing IIS sites 5 godzin temu
TESTING.md ci: isolate deployment from existing IIS sites 5 godzin temu
applicationhost.config Refactor project into generic starter template 5 miesięcy temu
run_site.cmd Refactor project into generic starter template 5 miesięcy temu

README.md

RouteKit Classic ASP - MVC Starter

A clean starting point for building Classic ASP applications with the RouteKit MVC framework.

Quick Setup

  1. Copy this folder to your IIS server
  2. Point your IIS site root to the public/ folder
  3. Update public/web.config:
    • Set ConnectionString to your database path
    • Set ErrorLogPath if you want file logging
  4. Ensure the IIS URL Rewrite module is installed
  5. Browse to http://localhost/ — you should see the welcome page

Project Structure

MVC-Starter/
  public/              # IIS ROOT - point your IIS site here
    Default.asp        # Front controller (entry point)
    web.config         # IIS config, routes, connection strings
  core/                # Framework core (do not modify)
    autoload_core.asp  # Loads all core libraries
    router.wsc         # Route matching engine
    mvc.asp            # MVC dispatcher
    lib.*.asp          # Core libraries
  app/
    controllers/       # Your controllers go here
    views/             # Your views go here
      shared/          # Shared layout (header, footer)
    models/            # POBOs go here
    repositories/      # Repository classes go here
  db/
    migrations/        # Database migrations
    webdata.accdb      # Access database
  scripts/             # Code generators
    generateController.vbs
    generateMigration.vbs
    GenerateRepo.vbs
    runMigrations.vbs

Adding a New Feature

1. Generate a migration

cscript //nologo scripts\generateMigration.vbs create_my_table

2. Generate POBO and Repository

cscript //nologo scripts\GenerateRepo.vbs /table:my_table /pk:id

Move generated files to app/models/ and app/repositories/.

3. Generate a controller

cscript //nologo scripts\generateController.vbs MyController "Index;Show(id);Create;Store"

Move generated file to app/controllers/.

4. Wire it up

  • Register in core/lib.ControllerRegistry.asp
  • Include in app/controllers/autoload_controllers.asp
  • Add routes in public/Default.asp
  • Create views in app/views/MyController/

Included Controllers

  • HomeController - Welcome page at /
  • ErrorController - 404 handler at /404

Requirements

  • Windows Server with IIS
  • Classic ASP enabled
  • IIS URL Rewrite module
  • Microsoft Access Database Engine (for .accdb support)

Deployment

Production deployment owns an isolated IIS site and app pool; it never targets, adopts, or copies configuration from another site. Defaults are SiteName=AspClassicUnifiedFramework, AppPoolName=AspClassicUnifiedFramework, DeployRoot=D:\Deployments\AspClassicUnifiedFramework, and HTTP binding 100.97.39.23:8085 with an empty host header. Every value is explicitly overridable, while mismatched existing target state fails closed.

The complete repository is retained in immutable release directories and IIS serves only each release's public/ directory. First deployment initializes shared configuration from packaged public/web.config unless -InitialWebConfigPath is supplied. The target site/app pool is created only after the staged release validates; Classic ASP parent paths are enabled only at that site's location. Failure cleanup is limited to target resources created by the current invocation, or restoration of the prior valid target state. Migrations remain disabled by default.

Run scripts/deploy-iis-git.ps1 -LocalPreflightOnly for local source/XML/package/safety validation with no network access. When host access is permitted, run -PreflightOnly for the complete check: it streams the installer without writing remote files and validates IIS features/modules, binding and shared-pool conflicts, drive/path, names, and target state without requiring the target to exist or making IIS/deployment changes. -HostPreflightOnly and -RemotePreflightOnly remain aliases. Gitea 1.11.4 has no Gitea Actions, so use a trusted external worker or operator workstation. See docs/deployment-guide.md and docs/deployment-configuration.md.

Testing

This repo now includes a dev-only aspunit harness under tests/. It is intentionally separate from the production app rooted at public/.

  • Configure a separate IIS application rooted at tests/
  • Ensure Classic ASP parent paths are enabled for that IIS app
  • If you change tests/web.config, refresh the nested test-folder copies with cscript //nologo tests\sync-webconfigs.vbs
  • Open run-all.asp inside that IIS app to execute the test suite
  • See TESTING.md for setup, manifest registration, and extension guidance

Powered by TurnKey Linux.