Add-ins & Deployment

01What an add-in actually is

Structurally it is a .NET class library, visible to COM, carrying a unique identifier, implementing the published add-in interface, and registered so that SOLIDWORKS knows to load it.

02The connect and disconnect contract

Two methods carry the whole lifecycle. Everything your add-in offers is created in the first and removed in the second.

[ComVisible(true)]
[Guid("PUT-YOUR-OWN-GENERATED-IDENTIFIER-HERE")]
public class KevosTools : ISwAddin
{
    private ISldWorks      swApp;
    private ICommandManager cmdMgr;
    private int             addinCookie;

    public bool ConnectToSW(object thisSw, int cookie)
    {
        swApp       = (ISldWorks)thisSw;
        addinCookie = cookie;

        // Register this object to receive command callbacks.
        swApp.SetAddinCallbackInfo2(0, this, addinCookie);

        cmdMgr = swApp.GetCommandManager(addinCookie);
        BuildCommands();

        return true;      // false tells SOLIDWORKS the add-in failed to start
    }

    public bool DisconnectFromSW()
    {
        RemoveCommands();
        cmdMgr = null;
        swApp  = null;
        return true;
    }
}

03Command groups and items

The command manager turns your methods into menu entries and toolbar buttons. A group holds items; a group becomes both a menu and a toolbar.

Enable methods

Each item may name a second method that SOLIDWORKS calls to decide whether the command should currently be available. It returns a small integer describing both whether the item is enabled and whether it appears selected. This is how a command that requires an assembly greys itself out when a part is open — and it is far better user experience than an error message after the fact.

Icons

Older add-ins supply a single wide bitmap containing every icon side by side, indexed by position. Current releases accept lists of image files at several sizes, which is what you should use for anything new: interfaces scale, and a single low-resolution strip looks obviously wrong on a modern display. Supply every size the interface asks for.

04Registration

Registration does two things: it makes the class creatable through COM, and it tells SOLIDWORKS the add-in exists. Both happen when the library is registered, and the second is code you write yourself.

[ComRegisterFunction]
public static void RegisterFunction(Type t)
{
    // Describe the add-in to SOLIDWORKS, and set whether it loads at start-up.
    // Machine-wide entry:  HKEY_LOCAL_MACHINE\SOFTWARE\SolidWorks\AddIns\{guid}
    //   default value  1 = load at start-up, 0 = available but not loaded
    //   "Title"        the name shown in the add-ins dialogue
    //   "Description"  the explanatory line beneath it
    // Per-user entry:      HKEY_CURRENT_USER\Software\SolidWorks\AddInsStartup\{guid}
    //   1 = this user loads it at start-up
}

[ComUnregisterFunction]
public static void UnregisterFunction(Type t)
{
    // Remove both entries. Leaving them behind is what produces
    // "add-in not found" errors long after the file has gone.
}

05Removal and diagnosis

Removing an add-in cleanly matters more than it sounds, because the failure mode is a persistent error at every start-up on somebody else's machine.

1. Unregister first, delete secondRunning the unregister step while the file is still present removes the entries properly. Deleting the file first leaves entries pointing at nothing, and SOLIDWORKS will complain at every start-up.
2. Clear both locationsThe machine-wide entry and the per-user start-up entry are separate. Removing one leaves the other.
3. Check for orphans after an identifier changeIf the identifier was ever changed, older entries remain and must be removed by hand.
4. Verify in the dialogueThe add-ins dialogue is the plain check: the entry should be gone, with no error on restart.

06Deploying to a team

The engineering is finished; the rollout is not. An add-in used by twenty people is a small piece of software with real deployment obligations.

07Quick reference