VSCODE for VB6

Written by

in

Using vscode, I open a vb6 project, hand craft code then send to a complier from original vb6 kit, e,g. bypass the ide constraints on W11 and Compile to use vb6 runtime

How it works

The VB6 compiler is vb6.exe, shipped with the IDE install (typically C:\Program Files (x86)\Microsoft Visual Studio\VB98\). It’s a command-line tool that does native compilation to .exe/.dll/.ocx — no IDE window needed. The resulting binaries depend on msvbvm60.dll (the VB6 runtime), which Microsoft ships in Windows 10/11 for the OS lifetime.

One-time setup

  1. Install the VB6 IDE on a build machine (the W11 install quirks — XP SP3 compat mode, admin, skip Data Access components, then VS6 SP6). You do this once to lay down vb6.exe, the runtime, and registered controls.
  2. Add the VB98 folder to PATH, or note the full path to vb6.exe.

Editing in VS Code

Install a VB6 syntax extension for .bas/.cls/.frm/.vbp/.ctl:

Then set file associations in .vscode/settings.json:

{ "files.associations": { "*.bas": "vb6", "*.cls": "vb6", "*.frm": "vb6", "*.vbp": "vb6", "*.ctl": "vb6" } }

VS Code now gives you editing, search, git, multi-cursor, diffing — none of which the VB6 IDE offers.

Building from the command line

The core command (documented via vb6.exe /?):

SwitchPurpose
/make (or /m)Compile the .vbp to an executable using settings stored in the project file
/outdir pathOutput directory (must already exist); overrides the Path32 in the .vbp
/out filenameFile that receives error messages
/d CONST=valueConditional-compilation constants
/makedll (or /l)Build an in-process ActiveX .dll instead of .exe
/cmd args (or /c)Sets the program’s command-line arguments (must be last)

For an ActiveX DLL: vb6.exe /makedll "Project.vbp" /out build.log

Critical gotchas

  • /out captures errors, not the binary. Don’t name your /out file the same as your target .exe — a common mistake that produces a text file with a .exe extension instead of a real executable.
  • Check the log, not just exit code. VB6 logs "Build of Project.vbp succeeded." on success; scan the log for failed/missing on failure. Automate detection by grepping the log.
  • .dca files must sit next to their .dsr (Designer) files or /make fails — matters if you use WebClass or similar designers.
  • No “compile-only” mode. /make always emits the binary; there’s no syntax-check-only switch. That’s fine — the binary is your success signal.
  • WOW64 is fine. vb6.exe is 32-bit and runs correctly on 64-bit Windows; just use the Program Files (x86) path.

VS Code build task

Wire it into .vscode/tasks.json so Ctrl+Shift+B builds:

{
  "version": "2.0.0",
  "tasks": [{
    "label": "VB6 Make",
    "type": "shell",
    "command": "\"C:\\Program Files (x86)\\Microsoft Visual Studio\\VB98\\vb6.exe\" /make \"${workspaceFolder}\\Project.vbp\" /outdir \"${workspaceFolder}\\build\" /out \"${workspaceFolder}\\build\\build.log\"",
    "problemMatcher": [],
    "group": { "kind": "build", "isDefault": true }
  }]
}

What you keep vs. what you give up

  • Keep: the supported VB6 runtime, your existing binaries, your source in modern git/VS Code, repeatable scripted builds, CI/CD.
  • Lose: the visual form designer (you must edit .frm files as text, or keep one machine with the IDE just for form layout), the VB6 debugger, drag-drop control placement.
  • One foot still in the grave: you’re still on the MS-unsupported VB6 toolchain (the compiler and IDE are unsupported even though the runtime is). This buys you years of clean, scriptable builds but not a permanent solution.

Sources

This is a strong interim posture: VS Code for editing, vb6.exe /make for builds, the supported runtime for execution. When you’re ready to shed the unsupported toolchain entirely, twinBASIC uses the same .vbp import and compiles 32/64-bit without vb6.exe at all.

Comments

Leave a Reply