SolidWorks API: COM Registration and Add-in Discovery

01Executive summary

Registration is where most first add-ins stall. The code compiles, the interface is implemented correctly, and nothing appears in the SolidWorks add-ins list. The reason is almost always that one of two independent registrations is missing: the class must be registered with COM so the operating system can produce it on request, and a discovery entry must exist under the SolidWorks registry key so the application knows to ask.

The elegant part of the standard pattern is that the second is driven by the first. Registration hooks on your class run automatically when the assembly is registered for COM, and it is inside those hooks that you write and remove the SolidWorks keys — so a single registration action does both jobs, and a single unregistration cleanly reverses them.

2registrations required

2registry hives written

3class attributes

2hook methods

02The attribute set

Three attributes sit above the class declaration. Two are demanded by COM; the third is specific to SolidWorks and supplies the metadata shown in the add-ins dialog.

AttributesAdd-in class decoration

[Guid("e3397eb9-2dc3-4c21-a9cf-26aa10dc9763"), ComVisible(true)]
[SwAddin(Title       = "KEVOS Example",
         Description = "Demonstration add-in",
         LoadAtStartup = true)]
public class KevosAddin : ISwAddin

Guid: The stable identity of the class among every registered COM object on the machine. Generate it once and never change it — the GUID is the name of the registry key SolidWorks looks for, so altering it orphans every existing installation.
ComVisible: Makes the class visible to COM. Without it the class is compiled but unreachable, and SolidWorks will never see it.
SwAddin.Title: The name shown in the SolidWorks add-ins dialog.
SwAddin.Description: The supporting text shown alongside the title in that dialog.
SwAddin.LoadAtStartup: Whether the add-in should be pre-ticked to load with every SolidWorks session, or left for the user to enable on demand.

Syntax differences

In Visual Basic the attributes are enclosed in angle brackets, separated by spaces rather than commas, and joined to the class declaration with a line-continuation so that the whole set is treated as one line above the class.

03Registration hooks

Two static methods, marked with the COM registration and unregistration attributes, are invoked by the registration process. They receive the type being registered, which is how they obtain the GUID without it being duplicated as a literal.

C# — registration and unregistration hooksIllustrative

using Microsoft.Win32;

private const string AddinKey =
    @"SOFTWARE\SolidWorks\AddIns\{{{0}}}";
private const string StartupKey =
    @"Software\SolidWorks\AddInsStartup\{{{0}}}";

[ComRegisterFunction]
public static void RegisterFunction(Type t)
{
    string id = t.GUID.ToString();

    // Machine-wide: tells SolidWorks the add-in exists.
    using (RegistryKey k =
        Registry.LocalMachine.CreateSubKey(
            string.Format(AddinKey, id)))
    {
        k.SetValue(null, 0);                        // load state
        k.SetValue("Title", "KEVOS Example");
        k.SetValue("Description", "Demonstration add-in");
    }

    // Per-user: 1 loads with every session, 0 loads on demand.
    using (RegistryKey k =
        Registry.CurrentUser.CreateSubKey(
            string.Format(StartupKey, id)))
    {
        k.SetValue(null, 1);
    }
}

[ComUnregisterFunction]
public static void UnregisterFunction(Type t)
{
    string id = t.GUID.ToString();
    Registry.LocalMachine.DeleteSubKey(
        string.Format(AddinKey, id), false);
    Registry.CurrentUser.DeleteSubKey(
        string.Format(StartupKey, id), false);
}

Make unregistration forgiving

Deleting a key that is not there should not throw. Using the overload that tolerates a missing key means a partially completed installation can still be cleanly removed — which matters far more in the field than it does on the development machine.

04The registry map

Two keys, in two different hives, doing two different jobs. The distinction is not cosmetic: one is machine-wide and requires elevation, the other is per-user and does not.

Registry entries written at registration
Key	Hive	Purpose	Values
`SOFTWARE\SolidWorks\AddIns\{GUID}`	Local machine	Declares that an add-in with this identity exists. SolidWorks enumerates this key at start-up.	Default (load state), `Title`, `Description`
`Software\SolidWorks\AddInsStartup\{GUID}`	Current user	Records whether this user wants the add-in loaded automatically.	Default: `1` load at start-up, `0` on demand
`SOFTWARE\SolidWorks\SolidWorks <release>\AddIns`	Local machine	Release-scoped variant of the discovery key consulted by some SolidWorks versions.	Same shape as the machine-wide key

Elevation and redirection

The machine-wide key cannot be written without administrative rights, which is precisely why registration belongs in an installer rather than in first-run application code. On 64-bit Windows, a 32-bit process writing to the machine software hive is silently redirected to the 32-bit compatibility subtree — so a 32-bit registration utility and a 64-bit host will not see the same key. Register with the utility that matches the host's architecture.

05Manual registration

Where automatic registration on build is unavailable, or when registering a build on a machine without the development toolchain, the assembly is registered from the command line with the runtime's assembly registration utility.

Locate the utility
It lives in the framework directory for the runtime version your assembly targets. Confirm the correct one before use — the wrong version registers against the wrong runtime.
Register the assembly
Invoke the utility with the path to the compiled library. This publishes the class under its GUID and triggers your registration hook.
Add a type library only if needed
Generating a type library alongside registration is optional. It exists to support consumers that need early binding against your types, and is not required by SolidWorks itself.
Verify in the registry
Inspect the discovery key and confirm a subkey named for your GUID exists with the expected title and description.

Shorten the path

Copy the build output to a short path before registering. The command line is typed by hand often enough during development that the saving is real, and long nested build paths are a reliable source of typing errors.

06Failure modes and what they mean

Registration diagnostics
Symptom	Most likely cause	Check
Add-in absent from the dialog	No discovery key	Registry subkey named for the GUID under the add-ins key
Discovery key present, add-in still absent	Class not registered with COM, or not COM-visible	Assembly COM visibility setting and the class attribute
Listed but never loads	Architecture mismatch	Build platform against the installed SolidWorks architecture
Listed but not ticked	Start-up flag set to load on demand	Per-user start-up key default value
Loads on one machine only	Registration ran only where built	Whether an installer performs registration on the target
Stale entry after removal	Unregistration hook not invoked	Uninstall path, and whether the hook tolerates missing keys
Registers, then breaks after a rebuild	GUID changed between builds	Whether the GUID attribute is a fixed literal, not regenerated

07Registration as an engineering discipline

IdentityFix the GUID once. Treat it as part of the product's published interface. Changing it is a breaking change for every installed seat.

SymmetryEvery write has a delete. The unregistration hook should reverse the registration hook exactly, and tolerate having already been partially reversed.

PrivilegeMachine-wide writes need elevation. Push registration into the installer where elevation is already established.

VerificationTest on a clean machine. A development workstation has been registered against so many times that it no longer proves anything.

The last of these is the one most often skipped and most often regretted. A development machine accumulates registry state from every build ever run on it. The only honest test of a registration path is a machine that has never seen the product.

08Quick reference

Class attributes: Fixed Guid, ComVisible(true), and the SolidWorks descriptor carrying title, description and start-up preference.
Hooks: Static methods marked with the COM register and unregister function attributes; both receive the type and read its GUID.
Machine key: Discovery entry named for the GUID, carrying title and description.
User key: Start-up entry named for the GUID; default value 1 to load with every session.
Manual path: Runtime assembly registration utility, matched to the target runtime and architecture.
First check when nothing appears: Does a subkey named for your GUID exist under the add-ins key?

COM Registration and Add-in Discovery