SolidWorks API: Deployment Methods and Installer Engineering

01Executive summary

Deployment is where an add-in stops being a development artefact and becomes a product. It is also where the consequences of the architecture decision arrive: a stand-alone tool can often be copied into a folder and run, while an add-in must be registered with COM, must write a machine-wide registry key, and therefore needs elevation and an uninstall path.

There is a ladder of deployment methods, and the engineering answer is to climb only as far as the product requires. A full installer for a single-file utility is waste; a manual copy procedure for a COM-registered add-in is a support burden that never ends.

02The deployment ladder

Rung 01Manual installation
The user copies files into place and performs any registration by following instructions. Legitimate for a single self-contained executable; unworkable at scale for anything needing registry entries.
Rung 02Plain archive
The same thing, packaged. Suits a multi-file product that lives entirely in one folder and needs no registration. Cheap, and honest about being cheap.
Rung 03Self-extracting archive
An executable that unpacks itself. Can target standard locations, create shortcuts, carry a title, icon and description, and be password protected. Limited in interface, logic and size — but sufficient for a surprising number of products.
Rung 04Installation package
A dedicated installer with prerequisite checks, licence acceptance, custom actions, shortcut creation, upgrade handling and a proper uninstall. Required as soon as COM registration is involved.

Choosing a rung
If the product…	Rung	Rationale
Is one executable with no dependencies	Manual or archive	There is nothing to install
Is several files in one folder, no registration	Archive or SFX	Packaging is convenience, not necessity
Needs shortcuts or standard install locations	SFX	Within the capability of a self-extractor
Needs COM registration	Installer	Requires elevation, a custom action and a reversible uninstall
Needs prerequisite checks or licence acceptance	Installer	Conditional logic is beyond a self-extractor
Will be upgraded in the field	Installer	Upgrade and removal semantics have to be defined somewhere

03Define the installer's requirements first

An installer is a small program with its own specification. Writing that specification down before opening the tool is what separates a twenty-minute job from a two-day one.

Text — worked example of an installer specificationIllustrative

PRODUCT      KEVOS Model Information add-in

FILES        All build outputs to a single application folder, so
             assembly references resolve at load time.
             Exclude debug symbols, host-process stubs and
             manifests not required at run time.

REGISTRY     Register the primary library with COM during install.
             Registration hook writes the SolidWorks discovery key
             and the per-user start-up key.

PREREQS      SolidWorks must already be installed - abort with a
             clear message if absent.
             Required runtime present, or offered for install.

CONSENT      Licence agreement shown and accepted before any file
             is written.

SHORTCUTS    Start menu entry for documentation and uninstall.
             No desktop shortcut - the product lives inside the host.

REMOVAL      Unregister COM, delete both registry keys, remove all
             installed files and the application folder.

UPGRADE      Detect an existing installation; remove it before
             installing the new version.

PRIVILEGE    Installer requires elevation - machine-wide registry
             writes cannot be performed as a standard user.

04Installer tooling

Several established tools do this job. They differ in cost, in authoring model and in how much they will let you do, and each carries its own documentation and conventions — there is no single procedure that spans them.

Common installer tooling
Tool	Model	Typically chosen for
Visual Studio setup project	Visual, integrated with the solution	Availability, and an authoring surface already familiar to the developer
InstallShield	Commercial suite	Complex products, wide platform coverage, established support
InstallAnywhere	Commercial, cross-platform	Products distributed beyond Windows
Ghost Installer	Commercial	Scripted customisation of the install sequence
WISE	Commercial	Long-standing enterprise packaging practice
Nullsoft installer	Script-driven, free	Small footprint and complete control over the sequence
Setup Factory	Visual, commercial	Rapid authoring with a designed presentation

The COM registration custom action

An installer does not automatically run your registration hooks. Registration must be requested explicitly for the assembly that carries them — usually by marking the primary output for COM registration, or by invoking the runtime's registration utility as a custom action. Whichever route the tool offers, the install and uninstall sequences must both be wired, or removal leaves the registry entries behind.

05Curating the payload

Not everything in the build output belongs in the installer. Shipping the whole folder increases download size, exposes internal paths and occasionally ships something you did not intend to.

Include

Primary library and dependencies

The registered assembly, any referenced libraries it needs at run time, and interop assemblies not supplied by the host.

Include

Resources and configuration

Icons, image lists, templates and any default configuration the product reads on first run.

Exclude

Debug artefacts

Symbol files and host-process stubs exist for the debugger. They have no role on a user's machine and their presence invites questions.

Exclude

Build scaffolding

Manifests and intermediate outputs that are not required at load time. If you are unsure, remove it and confirm the product still loads on a clean machine.

Stage the payload

Copy the curated set into a dedicated staging folder and point the installer project at that, rather than at the build output directory. The installer then has a stable, reviewable input, and updating a release becomes a matter of refreshing one folder.

06Verifying a deployment

Clean machine
Install on a machine that has never built the product. This is the only test that proves registration works rather than that it happened once during development.
Standard user
Run the installer as a standard user and confirm elevation is requested and handled, rather than the install silently completing without the machine-wide key.
Load and use
Open the host, confirm the add-in appears with the expected title and description, and exercise a command that touches the parts you shipped.
Upgrade path
Install the previous version, then the new one. Confirm the outcome is one working installation, not two registrations fighting over the same GUID.
Uninstall
Remove the product and confirm the files, the discovery key and the start-up key are all gone, and the host opens cleanly afterwards.

Uninstall is a feature

An add-in that cannot be cleanly removed is a support liability for as long as it exists on a machine. Orphaned registry entries leave a phantom entry in the host's add-ins list; orphaned files confuse the next version's installer. Test removal with the same seriousness as installation.

07Quick reference

Ladder: Manual, archive, self-extracting archive, installation package. Climb only as far as required.
Trigger for a full installer: COM registration, prerequisite checks, licence acceptance or field upgrades.
Specify first: Files, registry, prerequisites, consent, shortcuts, removal, upgrade, privilege.
Registration: Requested explicitly as a custom action or output property; wire install and uninstall.
Payload: Curate into a staging folder; exclude debug and build scaffolding.
Verification: Clean machine, standard user, load and use, upgrade path, complete uninstall.

Deployment Methods and Installer Engineering