SolidWorks API: Development Environment and Project Configuration

01Executive summary

Add-in projects fail at configuration far more often than at logic. The assembly must be the right kind of project, must reference the right type libraries, must be marked visible to COM, and must be built for a processor architecture that matches the host. Get any of those wrong and the symptom is identical and unhelpful: the add-in simply never appears.

This page sets out the configuration once. Every subsequent project in the pathway assumes these steps have been taken.

02Choosing the project type

The first decision is made in the new-project dialog and cannot be changed casually later.

Project type by intent
Intent	Project type	Output	Entry point
SolidWorks add-in	Class library	`.dll`	None — instantiated by the host through COM
Stand-alone client	Windows Forms / WPF application	`.exe`	Application entry point you own
Shared logic for both	Class library	`.dll`	Referenced by the add-in or the client
Background service	Windows service	`.exe`	Installed and hosted by the service control manager

A library project has no entry point, which is exactly why it suits an add-in: SolidWorks is the program, and your assembly is a set of types it loads. The same property is what makes a library the right home for logic you intend to share between an add-in and a stand-alone tool, or to version and ship independently of the shell around it.

Naming the class

Rename the default generated class before you write anything. The class name becomes part of the COM identity of your add-in and appears in registration output; a name that describes the product will repay itself the first time you debug a registration problem.

03Type-library references

Nothing in the SolidWorks API is reachable until the COM type libraries are referenced and interop assemblies are generated for them. Four are added from the COM tab of the reference dialog, and one is added by browsing to the SolidWorks installation folder.

References required by an add-in project
Reference	Source	Provides	Required
SolidWorks type library	COM tab	The application object, documents, features, selection and the bulk of the API surface	Yes
SolidWorks commands type library	COM tab	Command Manager, command groups and command item types	Yes
SolidWorks constants type library	COM tab	The enumerators — message-box icons, document types, control types, page options and status codes	Yes
SolidWorks published (add-in) types	COM tab	`ISwAddin` and the interfaces an add-in is required to implement	Yes
`solidworkstools.dll`	Browse — SolidWorks install folder	Helper types for bitmap handling, resource loading and file paths used by toolbar images	Recommended

Version pinning

The type libraries are versioned against the SolidWorks release installed on the build machine. Record which release a build was compiled against in your release notes — it is the first question asked when an add-in loads on one workstation and not another.

04Namespace imports

With the references in place, each code file that touches the API needs the corresponding imports. Adding all of them to every API-facing file is the pragmatic default; the helper-library imports are only needed where you actually use bitmap or file helpers.

C# — using directives for an API-facing fileIllustrative

using System;
using System.Runtime.InteropServices;

// SolidWorks type libraries
using SldWorks;      // application, documents, features
using SWPublished;   // ISwAddin and add-in contracts
using SwConst;       // enumerators and status codes
using SwCommands;    // Command Manager and command items

// Optional helper library (omit if not referenced)
using SolidWorksTools;
using SolidWorksTools.File;

The equivalent in Visual Basic uses Imports in place of using, and the interop attribute namespace is imported the same way. Two syntactic differences are worth noting early because they cause disproportionate confusion: Visual Basic performs the cast from the loosely typed connect parameter to the application type implicitly, where C# requires it to be explicit; and Visual Basic requires the implementation clause on its own line beneath the class declaration.

05Assembly and build settings

Three settings decide whether the compiled assembly is usable as an add-in at all.

Setting 01

Make assembly COM-visible

Set on the assembly information dialog. Without it, the class cannot be exposed to COM regardless of what attributes you place on it.

Setting 02

Register for COM interop

A build option that runs registration automatically each time the project is built, so your registration hook writes the SolidWorks discovery keys without a separate step. Where the option is absent from a given edition of the toolchain, register manually instead — covered in the next part.

Setting 03

Processor architecture

The add-in is loaded into the SolidWorks process, so it must be built for the same architecture as the installed SolidWorks. A mismatch is not a warning; the assembly is simply never loaded.

Setting 04

Interop type handling

On toolchains that offer to embed interop types, disable embedding for the SolidWorks references. The add-in must marshal against the host's own type libraries rather than a private embedded copy.

Symptom without a message

An assembly that is not COM-visible, is registered for the wrong architecture, or was built against a different SolidWorks release produces exactly one symptom: nothing happens. There is no error dialog. Work through the configuration checklist before reaching for the debugger.

06Setting up to debug

An add-in cannot be started directly — it has no entry point. Debugging means running the host and attaching to it.

Point the debugger at the host
Configure the project to start the SolidWorks executable as its external program, so pressing run launches the host with the debugger already attached.
Or attach after the fact
Start SolidWorks normally, then attach the debugger to the running process. Useful when reproducing a defect that only appears in an established session.
Break inside connect
A breakpoint on the first line of the connect method confirms registration and discovery are working before you debug anything else.
Close between builds
The host holds a lock on the loaded assembly. SolidWorks must be closed before the project can be rebuilt — the single largest productivity cost of add-in work.

Shortening the loop

The close-rebuild-reopen cycle is the reason many teams push logic out of the add-in and into a referenced library or a separate stand-alone process, keeping the add-in itself thin. The architectural trade-off behind that choice is examined in Part 07.

07Reading era-specific guidance

Published SolidWorks API material is inevitably tied to the release it was written against. Separating the durable from the dated saves a great deal of time.

Durable versus era-specific configuration decisions
Decision	Nature	Notes
Class library for an add-in	Durable	Follows from the add-in being instantiated by the host rather than run.
Four COM type libraries plus helper library	Durable in shape	The set is stable; the version numbers in the library names track the installed release.
COM-visible assembly and stable GUID	Durable	A requirement of COM itself, not of any particular release.
Named registration utility and framework path	Era-specific	The utility's location moves with the runtime version installed.
Availability of automatic COM registration on build	Era-specific	Has varied by product edition; manual registration is the reliable fallback.
Architecture must match the host	Durable	Becomes more important, not less, as 64-bit hosts became the norm.

08Configuration checklist

Project: Class library, meaningfully named, default class renamed.
References: Four SolidWorks COM type libraries plus the helper library from the installation folder.
Imports: API namespaces plus the interop services namespace in every API-facing file.
Assembly: Marked COM-visible.
Build: Registration on build enabled where available; architecture matched to the host; interop types not embedded.
Debug: External program set to the SolidWorks executable, or attach to the running process.
Discipline: Record the SolidWorks release the build was compiled against.

Development Environment and Project Configuration