Deploying SolidWorks Macros to Non-Technical Users — The Zero-Setup Approach

A r/SolidWorks thread from last week: an engineer built a macro that exports a DXF, renames it, and drops a PDF in the right folder. It works on their machine. When they try to run it on a manager’s laptop or a shop floor PC, it crashes with a COM exception or silently does nothing. The replies cover the symptoms but not the root cause, and nobody agrees on the right distribution approach.

The short version: SolidWorks macros fail outside the developer’s machine for predictable, fixable reasons. There are five distribution patterns. Most teams should use the standalone EXE approach. Here is why, and how to build it.

Why macros fail on other machines

Before choosing a distribution approach, understand the failure modes:

Missing COM references. VBA macros reference SolidWorks type libraries via GUIDs. If the target machine has a different SolidWorks version, or if the reference was set using early binding (Dim swApp As SldWorks.SldWorks instead of As Object), the macro throws a runtime error on load before executing a single line.

Hardcoded paths. Open "C:\Users\JohnEng\Desktop\output.dxf" fails on every machine except John’s. The failure mode ranges from an obvious file-not-found error to a silent early exit if the error handler swallows exceptions.

Security restrictions. SolidWorks checks macro trust settings. On a freshly provisioned corporate machine, the macro security level may block .swp or .swb files that are not explicitly trusted. The user sees no error — the macro simply does not run.

VBA IDE differences. On older SolidWorks versions (pre-2019), the VBA IDE version differs, and macros compiled in a newer version may silently refuse to execute in an older one.

No error handling for non-developers. A raw VBA error box showing Run-time error '91': Object variable not set communicates nothing useful to a shop floor supervisor. They close the box, try again, and call IT.

Five distribution approaches

1. Shared .swp folder + Macro menu

The simplest option: save the compiled macro (.swp) to a network share, and add the path to Tools > Customize > Keyboard or Tools > Options > File Locations > Macros. Every SolidWorks user on the domain resolves to the same file. Updates deploy instantly — edit the .swp on the share.

When it works: Small teams where everyone runs the same SolidWorks version, same service pack, and has network access to the share. Used primarily for macros run by engineers, not non-technical staff.

Failure mode: Version skew between the developer’s SolidWorks and the user’s breaks the COM references in the compiled .swp.

2. CommandManager tab from macro folder

A recent open-source project on r/SolidWorks does something practical: it reads a folder of macros and builds a CommandManager tab from them automatically. The swMacroTool_e API makes this doable in a few hundred lines. Each .swp or .swb file in the folder becomes a button with the filename as the label.

This is a good pattern for engineering teams who want a shared macro library without paying for a full add-in development cycle. The setup cost is moderate: you need to build and deploy the “loader” add-in once, but macro updates are just file drops to the shared folder.

Limitation: The loader add-in requires installation on each machine (once). Still subject to the same SolidWorks version COM reference issues as direct .swp distribution.

For when this escalates to a full add-in, VBA vs C# for SolidWorks API — When to Use Which covers the architectural decision.

3. SolidWorks PDM task

If your team uses SOLIDWORKS PDM (Standard or Professional), the Task interface (IEdmTaskHandler) runs code on the PDM server in response to state transitions. A “Generate Flat Pattern DXF on approval” task runs automatically when a drawing reaches the Approved state — no user action needed.

When it works: Teams with PDM who want event-driven, zero-user-interaction automation.

Failure mode: PDM tasks run in a separate SolidWorks session on the server. Writing a PDM task is a full add-in project (C# or VB.NET), not VBA. The server requires SolidWorks and a Task Add-in license. This is not a quick deployment option.

SolidWorks PDM Batch Plot — Automate Drawing Exports from the Vault covers the PDM task pattern in detail.

4. Standalone EXE (recommended for non-technical users)

A standalone Windows executable connects to an already-running SolidWorks session via COM, performs the operation, and exits. The user double-clicks a shortcut on their desktop. No VBA, no macro menu, no SolidWorks UI interaction required.

The COM connection uses the Running Object Table:

using SldWorks = SldWorks;

static ISldWorks ConnectToSolidWorks()
{
    var rotType = Type.GetTypeFromProgID("SldWorks.Application");
    object obj = null;
    
    // GetActiveObject from ROT
    try
    {
        obj = Marshal.GetActiveObject("SldWorks.Application");
    }
    catch (COMException)
    {
        throw new InvalidOperationException(
            "SOLIDWORKS is not running. Open SOLIDWORKS before running this tool.");
    }
    
    return (ISldWorks)obj;
}

The GetActiveObject call returns the running SolidWorks instance. From there, swApp.ActiveDoc gives you the open document. The full operation runs in a standard .NET console or WinForms app.

What users see: a desktop shortcut labelled “Export DXF Files”. They click it while the assembly is open in SolidWorks. A console window appears, shows progress, and closes. If something goes wrong, they see a plain-language error message — not a stack trace.

Design rules for this approach:

• One job per shortcut. No menus, no configuration dialogs at launch. If configuration is needed, use a one-time config.json that the user sets up once and never touches again.
• Human-readable errors. Catch every exception and translate it: “The open document is not a sheet metal assembly” is useful. NullReferenceException at ExportHelper.cs:47 is not.
• Idempotent. Running the export twice should produce the same output as running it once. Do not delete files before regenerating — overwrite them. This matters when users click the shortcut twice by accident.
• Log the result. Write a summary to a text file alongside the output: “Exported 12 DXF files to Z:\Shop\DXF\2026-08-23. Skipped 2 non-sheet-metal parts.” The log is evidence the tool ran and tells the user what to expect.

Why the ROT approach over creating a new SolidWorks instance:

new SldWorks.SldWorks() launches a second, headless SolidWorks session. This is legitimate but has two problems for non-technical users: it requires a SolidWorks license to be available (seat check), and the headless session runs at the same priority as the visible one — on a machine with 16GB RAM, two SolidWorks instances will page heavily. The ROT approach uses the already-running, already-licensed instance.

Version targeting. The SldWorks.Application ProgID without a version number resolves to whatever SolidWorks is registered as the default, which changes after upgrades. For a stable reference, use the versioned ProgID: SldWorks.Application.30 for SolidWorks 2022, SldWorks.Application.32 for 2024. If you want version-independent resolution, enumerate the ROT:

IRunningObjectTable rot;
GetRunningObjectTable(0, out rot);
IEnumMoniker monikerEnum;
rot.EnumRunning(out monikerEnum);
// Iterate and match "SldWorks" in the display name

5. Full COM add-in

A properly deployed COM add-in ([ComVisible(true)] class implementing ISwAddin) integrates directly into the SolidWorks UI. Buttons appear in the CommandManager, context menus, or the task pane. State changes (document open, save, activate) are handled via SolidWorks event subscriptions.

When to use it: When you need access to SolidWorks events (auto-export on save), when the operation requires deep SolidWorks integration, or when the tool will be used by engineers who work inside SolidWorks all day and want minimal context switching.

Deployment cost: An add-in requires an installer (or at minimum a .reg file) to register the COM class on each machine. Unlike a standalone EXE, you cannot just copy files. When to Upgrade from a SolidWorks Macro to a Full Add-in covers the threshold for when this investment pays off.

CadShift is a COM add-in for exactly this reason: it needs the SolidWorks CommandManager, PropertyManager pages for configuration, and event hooks to stay in sync with the active assembly.

Which approach to use

The standalone EXE approach handles the most common case — taking a tool that works for an engineer and making it available to people who have SolidWorks open but are not SolidWorks developers. The setup is a desktop shortcut and a config.json in a shared folder. Updates are a file copy.

What makes macros reliable for any audience

Regardless of distribution method, these three practices prevent the majority of failures:

Late binding for COM references. Declare your SolidWorks objects as Object (VBA) or dynamic (C#) instead of the typed interface. This removes the COM reference GUID dependency that breaks across SolidWorks versions. The tradeoff is no IntelliSense, which is acceptable for production code if you develop on the typed version and switch to late binding before distribution.

Guard the entry point. Validate prerequisites before doing anything: “Is an assembly open? Is the active document a sheet metal part? Does the output folder exist?” Fail fast and clearly, before any COM call that might produce an inscrutable error.

Test on a clean machine. Before distributing any macro or EXE, test it on a machine where you did not develop it. The most common bugs — missing DLL references, hardcoded paths, COM version mismatches — only appear on the first run on a new machine, never on the developer’s.

For the broader decision between VBA macros and C# add-ins for different automation scenarios, the deployment requirement is one of the deciding factors: if the tool needs to run reliably on machines you do not control, the standalone EXE or full add-in approach forces you to handle distribution properly from the start.