VBA Tools 0.1.6

This is the first public VBA Tools pre-release candidate. Versions 0.1.0,
0.1.1, 0.1.2, 0.1.3, 0.1.4, and 0.1.5 were tagged but were not published to the VS Code Marketplace or as a
GitHub Release. This section carries forward their unreleased capabilities.

Added

• Windows x64 VBA language assistance for exported .bas, .cls, and .frm
  files, including diagnostics, formatting, completion, navigation, symbols,
  and semantic Rename.
• Workbook build, test, publish, import/export, CommonModules, and reference
  workflows through bundled vba-dev, with Test Explorer integration.
• Native VBE debugging for supported public parameterless procedures, Doctor
  diagnostics, and an environment-scoped UserForm Event catalog.
• Self-contained companion executables and a standalone vba-dev 0.1.0 ZIP;
  no separately installed .NET runtime is required.

Changed

• Ordinary Build imports saved source into the exact manifest-selected source
  workbook and saves it in place, including other unsaved workbook edits after
  required consent. An already-open workbook retains its Excel process/window;
  a closed workbook opens hidden and closes after processing.
• Test runs in that same source workbook without initiating Save. An already-open
  workbook remains open; a closed workbook opens hidden and closes without saving
  remaining import/test changes. Dirty-workbook consent still applies to Build
  and Test, including execution-only no-build Test.
• Debug F5 and Restart reuse the exact source workbook and Excel process/window
  without dirty-workbook confirmation or automatic workbook/editor saving.
  Debug alone omits the independent pre-launch source-analysis gate; immutable
  capture, encoding, target/breakpoint safety, recovery, and native VBE checks
  remain. Stop resets execution without closing or saving the workbook.
• Project Export reads the selected source workbook, including live VBE changes
  when it is already open, without saving or closing that session.

Breaking Changes

• Ordinary Build no longer creates a disposable workbook-bin output. Review the
  saved exported source before building: templatePath, conventionally
  src/<document>/<document>.xlsm, now identifies the workbook changed and saved.
• Debug replaces unsaved VBE-direct code with captured source without an extra
  confirmation. Cell edits remain, but neither Test nor Debug is a sandbox or
  whole-workbook rollback: VBA itself can explicitly save or cause other effects.
• Legacy binPath is optional, deprecated, and scheduled for removal. Supported
  existing values emit a warning; remove only the property to retire the setting.
  New projects omit it, and commands do not automatically delete or move old
  workbook-bin files or the configured source workbook.
• Update the extension and companion tools together. Source-workbook features
  and no-confirmation Debug preparation must pass capability admission; the same
  tool release version or unchanged result schema does not prove compatibility.

Publish and standalone Import remain unchanged. Explicit snapshot-output Build
and explicit-workbook Export retain their separate output and lifetime contracts.

Fixed

• Artifact assembly preserves a failed prerequisite's stdout and stderr, waits
  for both streams to drain, and decodes split UTF-8 diagnostics correctly.
  Build failures remain failures; existing outputs are not used as substitutes.
• Release builds pin SDK 10.0.402 exactly and pair it with reviewed CLI ILLink
  10.0.13 locks. A later SDK patch cannot silently change the locked restore
  dependency graph. Locked restore remains enabled.
• Release automation reads Marketplace JSON from stdout alone and retains
  stderr separately. Initial lookup, visibility polling, and final verification
  use the same direct pinned-vsce invocation; npm notices cannot become JSON.
  Failed commands, malformed or incomplete responses, and identity mismatches
  remain errors rather than permission to publish. Only the pinned vsce's exact
  missing-extension token is treated as definitive absence.
• Release automation resolves unpublished drafts through paginated exact-tag
  listings and Release ID lookup instead of the published-release tag endpoint.
  Initial staging, resume and pre-finalization retain fail-closed identity,
  checksum and provenance checks; missing, ambiguous or published drafts stop.
• CommonModules Add and Update no longer treat a completed result as untrusted
  when the selected project and CLI receipt use equivalent Windows short and
  long paths. Side-effecting operations are not retried.
• Redirected CLI output uses UTF-8, allowing the debug adapter to read Japanese
  warnings without a decoding failure.
• Hosted CommonModules integration verification compares the receipt with the
  filesystem-canonical project path rather than its original 8.3 alias. No
  product operation, response-time requirement, or test gate is skipped.
• Separate real-workbook Extension Host checks from the Excel-free hosted
  release gate. The explicit Windows Excel gate still executes native Build,
  Publish, snapshot Build and Test diagnostics; missing Excel fails that profile.

Requirements

• Windows 10 or 11 on x64 hardware and VS Code 1.137.0 or later. Workbook
  automation and native VBE debugging require desktop Excel with trusted VBA
  project access; editor-only language features do not require Excel.

Known Limitations

• The extension targets Windows x64. Worksheet and ThisWorkbook code-behind
  and control-instance Event intelligence are not supported.
• Intermittent source-analysis and companion-process failures observed on an
  affected Windows host remain under investigation ([#409], [#415]). The
  capability-probe retry does not fix their underlying cause.
• One initial VM Test on the preceding candidate terminated abnormally in
  VbaLexer.Tokenize; its cause is unconfirmed. Ten subsequent targeted Test
  invocations passed with virtual CPU 0 excluded, but this is not proof of a fix,
  unconditional stability, or equivalence to a host CPU exclusion. The maintainer
  accepted the original failure as a known release risk
  (verification and acceptance).

Release Metadata

• Target commit: 3a5a86bea9b7ce6eed08aed067ce294ac6286f60
• Marketplace channel: pre-release
• VS Code extension: 0.1.6 for win32-x64
• Windows verification evidence is recorded in the annotated tag.

Bundled Tools

• vba-dev: 0.1.0
• vba-dev contract: 1.0
• vba-debug-adapter: 0.1.0
• vba-debug-adapter contract: 1.0; protocol 2.0
• vba-language-server: 0.1.0

Artifacts

• VSIX: vba-tools-win32-x64-0.1.6.vsix
• Standalone vba-dev: vba-dev-win-x64-0.1.0.zip
• Checksums: SHA256SUMS

Known Release Verification Risk

One VS Code renderer access violation (0xC0000005, read at 0x84) was observed during the 0.1.6 VM verification with VS Code 1.140.0 / Electron 43.7.3. The cause remains unresolved; it has not been attributed to VBA Tools, formatting, CPU affinity, or the CLR. After resuming the session, the planned functional verification completed.

The maintainer explicitly accepted this observation as a known release verification risk and authorized publication of this exact tag and commit. Completion of the subsequent checks is not proof of the cause, a fix, or unconditional stability. Existing intermittent CLR/access-violation risks remain unresolved.

Verification evidence and explicit maintainer acceptance.