Rebuild installer vs. install+hotpatch (AutoCAD 2000)

Note: This is a decision guide for AutoCAD 2000 only. If the target build must run on newer AutoCAD (e.g., 2026), rebuilding the old installer is not the right effortâ”focus on a new packaging path.

The two options

Option A â” Install v3.60, then hot patch (overlay newer payload)

You install the known-working v3.60 package and then overwrite installed files with the newer buildâTMs scripts/assets.

You are relying on:

  • the v3.60 installer to create the right footprint,

  • the newer payload being broadly compatible with that footprint.

Option B â” Rebuild the installer (new package)

You rebuild packaging so the installer deploys the newer payload directly (and sets any required keys/paths).

You are relying on:

  • having enough installer project/source to rebuild,

  • being able to run old tooling (often InstallShield-era),

  • and understanding exactly what the installer must configure.

Weighting: speed vs. correctness (practical)

If the goal is âoeget it running nowâ

Hot patching is usually the fastest path because it turns the installer into a âoebootstrapâ and avoids toolchain archaeology.

If the goal is âoeship to customersâ

Rebuilding (or replacing) the installer becomes more important because:

  • field installs must be repeatable,

  • support teams need deterministic behavior,

  • and you want an auditable packaging process.

In practice, teams often do A first to validate the payload, then do B later when packaging hardens.

Heuristic odds of success (not a guarantee)

Because we donâTMt yet have a validated diff of v3.60 vs the newer build, the best you can do is estimate based on what changed.

Hot patch likelihood tends to be higher (â%^ 60â”80%) when:

  • the newer build is mostly LSP/DCL/SCR/menu updates,

  • folder layout is the same,

  • no new external dependencies,

  • and the VLX (if any) is unchanged or still compatible.

Hot patch likelihood tends to be lower (â%^ 20â”50%) when:

  • the newer build adds a different VLX compiled against a different runtime,

  • introduces new COM components/DLLs,

  • expects new registry keys created by a different installer,

  • or relocates files in ways that break hard-coded menu paths.

Installer rebuild likelihood tends to be higher when:

  • you already have the installer project definition (or can reconstruct it reliably),

  • and the packaging changes are straightforward (file copy + a few keys/shortcuts).

Installer rebuild likelihood tends to be lower when:

  • installer tooling is obsolete and hard to run reproducibly,

  • you donâTMt have the original installer scripts/projects,

  • or the package behavior is âoetribal knowledgeâ (undocumented custom actions).

Recommendation pattern (what usually minimizes risk)

  1. Try hot patching first in a VM with snapshots.

  2. If you can get a stable working state, write down the exact overlay recipe.

  3. Use that recipe to define the âoetruthâ of what the installer must deploy.

  4. Then decide whether to:

    • rebuild an installer, or

    • replace it with a modern packaging approach (still delivering AutoCAD 2000-compatible file layout).

What to measure during the hot patch attempt (so it isnâTMt wasted effort)

Even if hot patching fails, it should produce useful evidence:

  • A precise list of missing files or mismatched load points.

  • Errors that point to registry keys or paths.

  • Whether the VLX is a hard dependency or optional.

  • The minimal set of files needed for a âoeworkingâ runtime.

That evidence directly informs the packaging work (Option B).