Solid Edge API 2026 in practice: type libraries, add-ins and what to automate first

A designer changes three values in the variable table, updates the drawing, fills in the title block and exports a PDF and a STEP file. When that sequence repeats on every order, it is the classic first job for the Solid Edge API. This guide reflects the state of October 2026: Designcenter Solid Edge 2026 (v2510) is the current release, and Siemens has announced the launch of Solid Edge 2027 for 11 November 2026. The API facts come from the Siemens SDK documentation listed under sources; how we turn them into tools for a design team is described under Solid Edge automation.

What the Solid Edge API consists of

The Solid Edge API consists of COM type libraries that are installed with Solid Edge, plus the SDK with the Programmer’s Guide, the object reference and samples. Any language that can use COM works. Siemens documents VB.NET, C# and C++ and also names Python. Solid Edge 2026 runs on 64-bit Windows only, so programs are built for x64.

The SDK help contains the Programmer’s Guide with code samples in VB.NET and C#. The installation media hold an SDK\Advanced folder with header files, add-in samples and tools, and for current samples the SDK help points to the SolidEdgeCommunity repository on GitHub. Solid Edge ships no interop assemblies for customers, so you generate them yourself, with “Add Reference” in Visual Studio or with tlbimp.

How the Solid Edge API compares with its closest neighbour is covered in Solid Edge vs SolidWorks API, and the CAD API comparison adds Inventor and CATIA.

Add-ins (ISEAddInEx) or external programs

An add-in is a COM DLL that Solid Edge loads into its own process. It adds commands as a tab and works directly on the open model. An external program runs as its own EXE and connects to Solid Edge through the ProgID SolidEdge.Application. Both use the same type libraries; they differ in speed, deployment and error handling.

What an add-in implements

Every add-in implements ISolidEdgeAddIn with three methods: OnConnection when Solid Edge connects to the add-in, at startup, by the user or externally; OnConnectToEnvironment when an environment such as Part or Draft connects; and OnDisconnection. For add-ins written for V20 or later, Siemens recommends ISEAddInEx, whose method SetAddInInfoEx takes a resource file name instead of a module handle. Without it, add-ins run into problems on 64-bit Solid Edge. ISEAddInEx2 followed with ST7.

We recommend starting with an external program for batch work and read-only checks. It is quick to deploy and easy to debug. Move a function into an add-in once designers need it as a button in their environment.

Parts, assemblies, Draft and the variable table

All Solid Edge documents implement the common SolidEdgeDocument interface, and its Type property tells you whether a part, sheet metal part, assembly or draft is active. From there, each environment has its own collections. These four entry points cover most automation projects in file-based setups (Solid Edge with Teamcenter is a topic for our sister brand inteliScience):

• File properties: Document.Properties returns the PropertySets. Solid Edge has five property sets, summary information, extended summary information, project information, document summary information and mechanical modeling, plus Custom for user-defined properties. Material sits in mechanical modeling, document number and revision in project information.
• Variable table: Document.Variables returns the Variables collection. Query filters by name and type, Add creates a variable, Edit changes its formula. Every dimension is automatically available as a variable. Values are stored in internal units, meters for lengths and radians for angles, and the Expose property of a variable publishes it as a custom property.
• Assemblies: AssemblyDocument.Occurrences lists the parts and subassemblies. AddByFilename places a file at the position it has in its own file, and the Subassembly property tells parts and subassemblies apart.
• Draft: DraftDocument.ModelLinks links the model, Sheet.DrawingViews.AddPartView creates a view, and PartsLists.Add creates a parts list with automatic balloons from the saved settings in DraftList.txt in the Template\Reports folder.

Example: read the variable table in C#

This console program connects to a running Solid Edge 2026 session and lists every variable and dimension of the active document with its value. It follows the Variables.Query sample in the Siemens SDK.

// Console app, .NET Framework 4.8, platform target x64.
// COM references: Solid Edge Framework Type Library, Solid Edge Constants Type Library.
// Start Solid Edge 2026 and open a part, sheet metal part or assembly first.
using System;
using System.Runtime.InteropServices;

class ReadVariables
{
    [STAThread]
    static void Main()
    {
        // Attach to the running Solid Edge session
        var app = (SolidEdgeFramework.Application)Marshal.GetActiveObject("SolidEdge.Application");
        var doc = (SolidEdgeFramework.SolidEdgeDocument)app.ActiveDocument;
        var variables = (SolidEdgeFramework.Variables)doc.Variables;

        // All variables and dimensions, matched by system name or user name
        var list = (SolidEdgeFramework.VariableList)variables.Query("*",
            SolidEdgeConstants.VariableNameBy.seVariableNameByBoth,
            SolidEdgeConstants.VariableVarType.SeVariableVarTypeBoth,
            false);

        Console.WriteLine(doc.Name + ": " + list.Count + " entries");
        for (int i = 1; i <= list.Count; i++)
        {
            dynamic item = list.Item(i); // a variable or a dimension
            // Values are in internal units: meters for lengths, radians for angles
            Console.WriteLine(item.DisplayName + " = " + item.Value);
        }
    }
}

For a production tool, add the OleMessageFilter class from the SDK help, which retries calls while Solid Edge is busy. Marshal.GetActiveObject exists only in .NET Framework up to 4.8.1, so a .NET 8 program needs another way to reach the running session. For that reason we recommend .NET Framework 4.8 and x64 for Solid Edge tools today.

What to automate first

Start with tasks that repeat on every order, read more than they write and touch few features: property checks, batch exports, variants from the variable table and parts lists. They pay off quickly, are easy to test on copies of real data and survive new Solid Edge releases better than code that builds geometry.

1. Property check: read document number, material and revision from every file of a project and list what is missing before release. The program only reads, so no file changes.
2. Batch export: drafts to PDF and DXF, models to STEP, as an external program that runs overnight with DisplayAlerts switched off.
3. Variants: set formulas or values with Variables.Edit, recompute and save under a new name, for cases that family of parts does not cover.
4. Parts lists: create parts list and balloons in the draft with PartsLists.Add and your saved settings, so every drawing looks the same.

We advise against starting with feature creation. Building sketches and features through the API takes the most effort and is the part most exposed to changes in the modelling technology. Once the first tools run, the same API carries AI functions: an assistant reads properties and variables, proposes changes as a preview, and the engineer confirms each one as a single undo step.

A console program that reads the variable table on one workstation is a good test. A tool that 20 designers use with your templates, Solid Edge Data Management and release states also needs registration, versioning and a test run on every release. Our Quick Scan shows in one week which use cases are worth that step.

How we scope and build such tools across CAD systems is described under CAD automation.

Limits and pitfalls: versions, registration, performance

Most problems in Solid Edge automation come from the environment around the API: a new release, an add-in registered on one workstation but missing on the next, colliding interop assemblies, or an external program that makes thousands of single calls in a loop. Each of them has a documented countermeasure.

Versions

Siemens releases Solid Edge once a year. Solid Edge 2026 carries the version v2510 and runs on 64-bit Windows 10 or Windows 11; the next release to test against is Solid Edge 2027. Each document reports CreatedVersion and LastSavedVersion, and the Install Data library returns the installed version, which helps when files from several releases meet. API changes do happen. With ST3, Siemens merged the synchronous part and sheet metal APIs into the traditional objects, and programs written only for the old synchronous document types stopped working.

Registration

An add-in only appears after it is registered as a COM component on the workstation. Solid Edge reads its ProgID from that registry entry, and the Add-Ins dialog in the Solid Edge settings lists what is installed. Plan registration as part of your software rollout, usually together with IT. For add-ins inside the Solid Edge process, Siemens advises generating uniquely named interop assemblies. If two add-ins load an assembly called Interop.SolidEdgeFramework.dll, only the first one gets its own version, and the resulting errors are hard to trace.

Performance

Calls from an external program cross a process boundary, so a loop over thousands of dimensions is slow. Move such loops into an add-in or reduce the number of calls. During bulk changes, Application.DelayCompute suspends recomputation and ScreenUpdating switches off screen updates, while DisplayAlerts suppresses messages that would stop an unattended run.

Frequently asked questions