What Is the SolidWorks API? The COM Object Model Explained

COM (Component Object Model) is Windows' standard for sharing objects between applications. SolidWorks exposes its capabilities as COM interfaces. In practice this has three concrete consequences.

First: language independence. A COM interface is a contract — which method takes which parameters is defined independently of any language. That is why the ModelDoc2 object is reached the same way from VBA, from C#, from C++, and from Python's COM bridge. Method names do not change; only the syntax does. A call you learn in VBA carries over to C# almost verbatim.

Second: object lifetime is your responsibility. COM objects live by reference counting. Hold on to an object and never release it and SolidWorks may refuse to close; release it too early and you get unexpected errors. On the .NET side this is the single most overlooked detail in automation code.

Third: the difference between early and late binding. Early binding means referencing the SolidWorks type library at compile time. You are using early binding when you add a reference to SolidWorks.Interop.sldworks.dll in C#, or tick the SOLIDWORKS type library under Tools → References in VBA. The payoff is large: IntelliSense works, a mistyped method name is caught at build time, and calls are faster.

Late binding resolves the object's type at run time instead — that is what the Dispatch("SldWorks.Application") call in Python does. It is flexible, needs no reference setup, and tolerates different SolidWorks versions more gracefully. The price is that typos only surface at run time, and there is no IntelliSense. I showed the practical consequences on the Python side, with examples, in SolidWorks automation with Python.

The object model is a tree, and everything starts at the root. The table below shows the path that ninety percent of everyday automation work travels along:

Read the chain like this: from the session to the document, from the document to the design tree, from the tree to individual features and dimensions. Each level hands you the next one; you cannot skip a level. Most of the moments where you get lost writing automation actually come from trying to skip a step in this chain.

What each node is for, in one sentence:

• `SldWorks` — the SolidWorks application itself. Opening, closing and creating documents, plus application settings, are managed from here. Every piece of code starts by getting hold of this object.
• `ModelDoc2` — an open document. It carries the behaviour that parts, assemblies and drawings share: saving, rebuilding, view operations, access to the feature tree.
• `PartDoc` — the part-specific interface you reach when the document is a part; solid body operations and material assignment live here.
• `AssemblyDoc` — the assembly-specific interface: components, mates, and assembly-level operations.
• `DrawingDoc` — the drawing-specific interface: sheets, views, and drawing-level operations.
• `Feature` — a single item in the design tree. Its name, type and children are read from here; navigating the tree happens through this object.
• `Configuration` — a configuration of the document. The centre of variant generation and configuration-specific properties.
• `Dimension` — a dimension. Reading and writing its value is the most direct route into parametric automation.
• `CustomPropertyManager` — where custom properties are read and written. You do not get it from ModelDoc2 directly but through ModelDocExtension — this is the point in the hierarchy where people get lost most often.
• `SelectionMgr` — the list of objects the user currently has selected. It turns up constantly in recorded macros; I will come to why it needs handling with care in a later section.

How you read this tree matters: every arrow pointing down means "to get this object you must first hold the one above it." You cannot reach a Dimension object directly; you reach the application, then the document, then the feature.

The first two lines of every piece of automation code are the same — grab the application, get the document.

Every piece of automation starts with the same two moves. First you take hold of the root object: SldWorks, representing the running SolidWorks session. Then you go down one level and take the active document — ActiveDoc.

The critical point here is that the second move can come back empty. If no document is open you get nothing, and the next line of your code blows up. That is why the first check in every automation should be: did a document come back? If not, tell the user "no open document" and exit.

If a document did come back, the second check is its type. The document type determines everything that follows: part, assembly, or drawing? Applying logic written for a part to an assembly is the most common mistake I see in the field.

Carrying on without checking the result of ActiveDoc is the most frequent error I run into. If the document is closed, the code fails silently and the user says "it didn't work."

The second level is descending from the document into the design tree. The feature tree is walked like a linked list: you take the first feature, then ask for the next.

You ask the document for its first feature, then ask each feature "who is your next sibling?" and follow the chain to the end. When the chain runs out you get an empty result back and the loop stops there.

A practical detail: every feature's name is exactly the name you see in the design tree. That is the most useful link you have while debugging — you can search for the name from your code directly in the tree on screen.

The same navigation logic applies to assembly components, drawing views and configurations: ask for the collection, walk it in order, stop when you find what you were after.

Those ten lines summarise the logic of the object model: if you hold an object, there is a way down to the level below it. Once you have learned to navigate the tree, jobs like "find the feature with this name and change its dimension" become mechanical.

In the documentation you will see two names for the same thing: ModelDoc2 and IModelDoc2. This is not a version difference.

The I prefix means interface in COM; it defines the object's contract. The name without the prefix points at the class (coclass) that implements the interface. On the .NET side the SolidWorks interop library offers both, and in practice ModelDoc2 and IModelDoc2 can be used interchangeably; most developers prefer the I-prefixed form in C# because binding to the contract is clearer.

In VBA you usually write the name without the prefix. In the documentation, headings are mostly in the I-prefixed form. Knowing you are looking at the same page saves time while searching — when you cannot find ModelDoc2, search for IModelDoc2.

The fastest way to learn the object model is not to read the documentation front to back. The order is this:

1. Record yourself doing the job by hand. Open the Macro Recorder, perform the operation you want to automate the normal way, stop recording.

2. Look at which interface the generated code calls. Recorded code is not production ready — it comes out dependent on selection and screen state. But it gives you the thing you were looking for: which method on which object does this job.

3. Search for that interface in the API Help. Now you know the name of the thing you are after. In the documentation you read the method's full signature, what the parameters mean, and what alternatives exist.

4. Make the code independent of selection. Recorded code operates on "whatever is selected on screen." Production code should operate on "what it found by name."

What this order buys you is simple: to search the documentation, you first need to know what to search for. The Macro Recorder tells you exactly that. AI tools are also an accelerator at this discovery stage, though they can be confidently wrong about the COM lifecycle and version-specific behaviour; I covered their limits separately in writing a SolidWorks add-in with AI.

Every recorded macro works through SelectionMgr, because the Macro Recorder records your clicks. This route assumes two things: that the user selected the right thing, and that the selection is still valid.

If you genuinely need the selection — say the macro is meant to work on whatever the user has just highlighted — the rule is: do not assume the selection, read it and validate it. First ask how many objects are selected; if the answer is zero, the job stops there and you tell the user. Then check whether the selected object is the type you expected.

There is also a classic trap: indexes in SolidWorks selection collections start at 1, not at zero. Asking for element zero is one of the most common mistakes on the COM side.

The route that does not depend on selection at all is always more robust: ask the document for the object directly. Then the macro works regardless of what the user is doing on screen.

Selection-based code works, but it is brittle for three reasons:

• It depends on screen state. If the user selected the wrong thing, selected nothing, or the selection order changed, behaviour changes.
• It cannot be used in batch work. In a flow processing a hundred files back to back, there is no such thing as "the selected object."
• It can be silently wrong. With the wrong object selected the code does not error; it processes the wrong object. That is worse than erroring.

The robust approach is reaching the object by its identity: finding the feature by name, getting the configuration by name, reading the custom property by its key. Selection should only be used in interactive scenarios where the user has deliberately pointed at something; in batch and background work it should not be used at all.

The SolidWorks API evolves with each release. New interfaces are added and existing methods get new numbered versions — the trailing digits in Save3, GetSelectedObject6 and Add3 are exactly that trail. Older versions generally keep working, but new capabilities only exist on the new interfaces.

Three practical rules:

• Read the documentation for your target version. API Help is published per release. Looking at the 2025 documentation for a 2021 installation will send you hunting for a method that does not exist.
• Identify the lowest common version. If your code will run on five people's machines, the oldest SolidWorks among them is your target.
• On numbered methods, pick the highest supported version. If both Save and Save3 do the job, the newest one your target version supports usually gives you more control.

The API is not sold as a separate product; it is part of the SolidWorks licence. The capabilities you can reach, however, vary with the version and licence level you have.

I care about the order here, because most people start at step three and get stuck:

1. Explore with the Macro Recorder. Record five different jobs and read the generated code. The aim is not to write code but to see which job falls to which interface.

2. Memorise the chain from root to document. SldWorks → ModelDoc2 → the document type branch. Once you can write those three steps without thinking, the rest is exploration.

3. Free a recorded macro from selection. Take a recording you have, strip out the SelectionMgr dependency, find objects by name. This is where you actually learn the object model.

4. Work with custom properties and configurations. CustomPropertyManager and Configuration are the areas that produce real value with no geometric risk. Bulk property filling is a good candidate for your first production automation.

5. Move on to changing dimensions and features. Touching geometry is the last step, because that is where the cost of a mistake is highest. Driving a parametric model from code is the sum of these five steps.

You can see this order applied in the ParametriX project: where parametric model rules meet API automation is exactly step five.

What is the SolidWorks API, briefly? It is a COM programming interface for SOLIDWORKS. It contains hundreds of functions callable from VB, VBA, VB.NET, C++, C# or macro files, and gives external access to the SolidWorks object model.

What is `ModelDoc2` and why does it turn up everywhere? It is the interface representing an open document. Because the shared behaviour of parts, assemblies and drawings is gathered here, almost every piece of automation code passes through this object.

What is the difference between `IModelDoc2` and `ModelDoc2`? The I prefix denotes the COM interface; the name without it denotes the class that implements it. In practice you reach the same capabilities; when searching the documentation, try both forms.

Where should I start learning the API? With the Macro Recorder. Recording a job and looking at which interface the generated code calls moves you forward far faster than reading the documentation from the beginning. For deciding which form to build in — macro, add-in or standalone application — use the decision model in the macro and API guide.

Which language should I choose? Because the object model is the same in every language, the language is a secondary decision at first. VBA gives the fastest start, C#/.NET is preferred for lasting solutions, and Python suits rapid prototyping — I walked through connecting to the API over COM step by step in SolidWorks automation with Python.

Does the API cost extra? Is it bought separately? The API is part of the SolidWorks licence; it is not sold as a separate product. The capabilities you can reach vary with the version you use.

Why does my recorded macro break in production? Because recorded code depends on selection and screen state. Until the SelectionMgr dependency is removed and objects are found by name, the code will either stop or process the wrong object at the first scenario that differs.

Learning the SolidWorks API is not about memorising a list of methods; it is about internalising a map. Once you can write the SldWorks → ModelDoc2 → document type → Feature / Configuration / CustomPropertyManager chain without thinking, every job you have never done turns into nothing more than a search question.

A practical summary:

• Everything starts at the root; you cannot skip a level
• Thanks to COM the object model is language independent — what you learn carries over
• Early binding gives you IntelliSense while learning, late binding gives you flexibility
• The fastest way to find a job is Macro Recorder → generated code → API Help
• Selection-based code is brittle; reach objects by their identity
• Read the documentation for the SolidWorks version you are targeting

If you are thinking about moving repetitive SolidWorks steps into code at your company and cannot decide where to start, we can work through it together — write to me from the contact section.