Skip to content
| Marketplace
Sign in
Visual Studio Code>Programming Languages>ASP Classic Support V3New to Visual Studio Code? Get it now.
ASP Classic Support V3

ASP Classic Support V3

SUREbusiness

|
47 installs
| (2) | Free
Cross-file IntelliSense, navigation, references, and symbols for Classic ASP and VBScript includes.
Installation
Launch VS Code Quick Open (Ctrl+P), paste the following command, and press enter.
Copied to clipboard
More Info

Classic ASP IntelliSense

Language support and cross-file navigation for Classic ASP projects using VBScript.

Features

  • Completion for classes, functions, subs, properties, constants, parameters, and variables.
  • Go to Definition and Peek Definition across <!-- #include ... --> files.
  • Go to Definition on both file and virtual include paths.
  • Find All References and Rename Symbol across the connected include graph.
  • Document Outline and workspace symbol search.
  • Hover information showing declarations and source files.
  • Declaration comments shown as hover and completion documentation.
  • Implicit variables inferred from their first assignment when Dim is omitted.
  • Scoped loop variables inferred from For Each item In ... and For index = ... To ... statements.
  • Implicit variables inferred from direct, Set, and Let assignments inside single-line If ... Then ... Else ... branches.
  • Multiline VBScript expressions using the trailing _ continuation marker.
  • Basic member completion for variables assigned with Set value = New ClassName.
  • Case-insensitive symbol resolution, matching VBScript semantics.
  • Classic ASP syntax highlighting for .asp, .asa, and .inc files.
  • IntelliSense is limited to <% ... %> and <%= ... %> regions; matching names in HTML, JavaScript, and CSS are ignored.
  • Word-based suggestions are disabled for Classic ASP documents so indexed ASP names are not suggested outside code tags.
  • Configurable default includes whose symbols are available to every ASP file.
  • Configurable Classic ASP application root for sites stored below the workspace folder.
  • Per-file includer mappings for analyzing include fragments with their parent-file symbols.
  • Bundled IntelliSense for common Classic ASP intrinsic objects, VBScript functions, constants, Err, and RegExp.
  • Function signature help with active parameter highlighting.
  • Live syntax and block diagnostics in the editor and VS Code Problems panel.

Both relative includes such as <!-- #include file="../lib/helpers.asp" --> and site-root includes such as <!--#include virtual="/lib/helpers.asp"--> are supported. A virtual path starts at the configured Classic ASP application root. This defaults to the workspace-folder root. For a source outside all workspace folders, the first workspace folder is used.

Usage

Open the root of a Classic ASP site as a VS Code workspace. The extension lazily indexes the bundled declarations, configured default includes, ASP files opened by the user, and their recursive include graphs. It does not scan every ASP file in the workspace. Changes in loaded files are reflected immediately.

When the Classic ASP site is below the workspace folder, configure classicAsp.applicationRoot with its workspace-relative directory:

{
  "classicAsp.applicationRoot": "src"
}

With this setting, <!-- #include virtual="/includes/helpers.asp" --> resolves to <workspace>/src/includes/helpers.asp. Both src and /src/ are accepted. ${workspaceFolder}, Windows absolute paths, and file:// URIs are also supported. The setting affects virtual includes only; file includes remain relative to the file containing the directive. Loaded include graphs and diagnostics refresh when the setting changes.

Include fragments sometimes depend on declarations in the parent file that includes them. Use the classicAsp.fileIncludes mapping to load those parent files when a fragment is analyzed directly:

{
  "classicAsp.applicationRoot": "src",
  "classicAsp.fileIncludes": {
    "includes/B.asp": [
      "pages/A.asp"
    ]
  }
}

Here, analyzing <workspace>/src/includes/B.asp loads symbols and references from <workspace>/src/pages/A.asp. If A.asp normally includes B.asp, the resulting cycle is handled automatically. When the configured parent contains the matching #include directive, the fragment inherits the class and routine scope at that exact include site, including through nested includes. Multiple parent files are supported and retain their configured order. Only the parents configured directly for the file being analyzed are applied; a loaded parent is not recursively treated as another directly opened target. Normal #include directives inside each parent are still followed recursively. Keys and values use the same application-root-relative path rules as default includes, while ${workspaceFolder}, Windows absolute paths, and file:// URIs can explicitly bypass the application root. Built-in and classicAsp.defaultIncludes symbols remain available. Parent files are loaded lazily, and the resolved mapping is cached until relevant configuration or files change. The same mapping is used by classic-asp-check.

The classicAsp.exclude setting controls which files are omitted from indexing. Its default excludes dependency, source-control, and build-output directories.

Use classicAsp.defaultIncludes for framework, application, or server-level ASP files that are implicitly available without an include directive:

{
  "classicAsp.defaultIncludes": [
    "includes/framework.asp",
    "${workspaceFolder}/includes/application.asp",
    "/shared/classic-asp/runtime.asp"
  ]
}

Relative and leading-slash paths are resolved from classicAsp.applicationRoot. For example, with an application root of src, /content/includes/settings.asp resolves to <workspace>/src/content/includes/settings.asp. ${workspaceFolder}, Windows absolute paths, and file:// URIs bypass the application root and are also accepted; use a file:// URI for an absolute POSIX path outside the workspace. Default includes are followed recursively, so symbols from files they explicitly include are available as well. The index refreshes when either setting changes.

Consecutive VBScript comments directly above a declaration become its documentation. Both apostrophe and Rem comments are supported:

<%
' Formats an amount using the site's currency rules.
' Returns a display-ready string.
Function FormatCurrencyValue(amount)
    ' ...
End Function
%>

Built-in declarations

The extension uses a deterministic symbol order: resources/classic-asp-builtins.asp first, configured default includes second in settings order, and the active ASP file followed by its explicit includes in source order. Include graphs are traversed recursively and cycles are ignored after their first occurrence. It provides documented declarations for Request, Response, Server, Session, Application, ObjectContext, ASPError, Err, RegExp, common VBScript functions including Unicode and byte-string variants, VarType/date/format constants, and a compatibility Debug tracing object used by some Classic ASP hosts. The bundled file is declaration metadata and is never executed or included in the application at runtime.

Hover, completion, Go to Definition, and signature help use these declarations. Built-in declarations are read-only and cannot be renamed.

Diagnostics

The extension validates Classic ASP code as files change and reports problems through VS Code's Problems panel. It detects unmatched ASP tags, unterminated strings, unsupported characters, repeated +/- operators, malformed #date# literals, unmatched parentheses, semicolons, malformed class/function/sub/property declarations, missing Then, invalid Select and For statements, mismatched or missing block terminators, misplaced Else/Case/Exit statements, invalid procedure-call parentheses, unknown members on statically known classes, unresolved calls, undeclared variable reads, and implicit assignments when Option Explicit is enabled. Character validation applies throughout VBScript code while leaving strings, comments, and valid #date# literals untouched.

VBScript procedure-call syntax depends on whether the return value is used. Use Call Procedure(arg1, arg2) or Procedure arg1, arg2 for a statement call; use result = FunctionName(arg1, arg2) or another expression when consuming a function result. The checker reports missing parentheses after Call, parentheses around multiple arguments in a statement call, functions with bare arguments in expressions, and subs used as expressions. Empty parentheses and a single parenthesized argument remain accepted because VBScript accepts those syntactic forms; argument-count validation is not performed.

Diagnostics only analyze code inside <% ... %> and <%= ... %> tags. Member validation applies when the receiver type is known from New ClassName, an intrinsic ASP object, or Me. Runtime-dependent behavior such as Execute, dynamic COM members, database result fields, and generated code cannot be validated statically.

Members accessed through an indexed or invoked dynamic result are not type-checked. For example, dictionary(id).property = value and recordset.Fields(id).Value are accepted because the returned object type is not statically knowable.

To suppress every diagnostic on the immediately following line, add classic-asp-disable-next-line in a VBScript comment:

<%
' classic-asp-disable-next-line
valueFromDynamicRuntime

Rem classic-asp-disable-next-line
Call DynamicallyRegisteredMethod()
%>

The directive only applies inside ASP code tags and suppresses exactly one physical line. It behaves identically in VS Code and classic-asp-check.

To disable all Classic ASP diagnostics for a workspace or folder in both VS Code and classic-asp-check, use:

{
  "classicAsp.enableDiagnostics": false
}

Individual diagnostic categories can remain enabled or disabled independently. All default to true:

{
  "classicAsp.diagnostics.checkBlockClosing": true,
  "classicAsp.diagnostics.checkSymbols": true,
  "classicAsp.diagnostics.checkParentheses": true,
  "classicAsp.diagnostics.checkSet": true
}

checkBlockClosing controls missing and unexpected terminators such as End If, End Function, Next, and Loop. checkSymbols controls unknown variables, functions, calls, class members, and undeclared assignments under Option Explicit. checkParentheses controls the missing or invalid procedure-call parentheses checks described above; the separate Sub-as-expression check remains part of symbol diagnostics. Other syntax diagnostics remain enabled when a category is disabled. classicAsp.enableDiagnostics remains the master switch. These settings behave identically in VS Code and classic-asp-check. checkSet controls checks for missing Set on statically known object variable assignments and redundant Set on scalar or array values. Dynamic expressions whose result type cannot be determined are left unreported. Property assignments are not included because they may target either a Property Let or Property Set procedure. All categories default to true and behave identically in VS Code and classic-asp-check.

To exclude known host-provided, generated, or external names from unknown-symbol checks, configure a case-insensitive list:

{
  "classicAsp.ignoredSymbols": [
    "adVarChar",
    "Parameters",
    "generated*",
    "&*"
  ]
}

This suppresses unknown variable, function, class, call, and member diagnostics while leaving syntax and all other type checks enabled. Matching is case-insensitive, and * matches zero or more characters. Entries without * retain exact-name behavior. &* matches source identifiers immediately preceded by &.

CI command-line checker

The package includes classic-asp-check, a headless checker that runs the same parser, include index, built-in declarations, symbol resolver, and diagnostic analyzer as the VS Code extension. Unlike the editor's lazy index, the CI command deliberately scans every ASP file under the requested workspace:

npx classic-asp-check .

It reads all extension settings from .vscode/settings.json: classicAsp.applicationRoot, classicAsp.exclude, classicAsp.defaultIncludes, classicAsp.fileIncludes, classicAsp.enableDiagnostics, classicAsp.diagnostics.checkBlockClosing, classicAsp.diagnostics.checkSymbols, classicAsp.diagnostics.checkParentheses, classicAsp.diagnostics.checkSet, and classicAsp.ignoredSymbols. Additional default includes can be supplied on the command line:

npx classic-asp-check . --default-include includes/ci-runtime.asp

To use a VS Code settings file from another location, pass its path with --config. The file supports the same JSON-with-comments structure and the same CLI-supported classicAsp.* keys as .vscode/settings.json. Relative configuration paths are resolved from the current working directory, while configured include and application-root paths continue to be resolved against the workspace:

npx classic-asp-check . --config config/classic-asp.settings.json

Additional ignored symbols can be supplied repeatedly with --ignore-symbol:

classic-asp-check . \
  --ignore-symbol adVarChar \
  --ignore-symbol 'generated*'

Text output is intended for build logs. JSON output is available for CI integrations:

npx classic-asp-check . --format json

When Azure Pipelines runs the text checker, TF_BUILD=True is detected automatically. Each diagnostic is then emitted as an Azure Pipelines error or warning with source path, line, column, and diagnostic code metadata. No additional command-line option is required.

The command exits with 0 when no errors are found, 1 when Classic ASP problems are reported, and 2 for command or environment failures.

Current scope

The language service targets VBScript inside Classic ASP code tags. Untagged content and server-side <script> blocks are intentionally excluded. Static members created dynamically with Execute, ExecuteGlobal, or runtime-only object factories cannot always be inferred.

  • Contact us
  • Jobs
  • Privacy
  • Manage cookies
  • Terms of use
  • Trademarks
© 2026 Microsoft