Siemens NX Open development: how to build, sign and ship an NX plugin

NX Open development is documented far less in public than Revit or SolidWorks development. Teams that start their first Siemens NX plugin tend to hit the same three surprises: licensing, signing and the release calendar. This guide explains how NX plugins are built, signed and shipped, and what to settle before the first line of code.

The NX Open toolbox

NX Open is the programming interface of Siemens NX. It can be used at three levels:

• Journals. NX records your actions as code in C#, VB.NET, Python, Java or C++. You edit the recording and replay it. Journals are the fastest way to prototype and to automate one person's routine.
• Compiled applications. Libraries and executables built against the NX Open assemblies. They load at start-up or on demand, add commands to the ribbon and can run without a user interface.
• Block UI Styler dialogs. A designer for dialogs that look and behave like native NX ones.

The older Open C functions are still there too, and occasionally expose something the newer classes do not.

Licensing decides the form

The third row is how production plugins ship. It leads to the step that surprises newcomers.

Signing an NX Open application

NX checks every compiled application it loads. If the application is not signed, NX looks for an author licence. Without one, the application does not load.

Signing tells NX that the code was built by a licensed author. For a .NET application the steps are:

1. Add the NXSigningResource.res file from the NX installation to the project as an embedded resource.
2. Build the assembly.
3. Run the signing utility that ships with NX on the built file, on a machine where an author licence is available.
4. Verify the signature, then distribute.

Siemens documents the procedure in its support article on signing an NX Open DLL. Two details matter in practice. The resource file and the signing tool belong to a specific NX version, so use the ones from the version you target. And signing is the last step: any rebuild invalidates it.

The release calendar

NX ships a new series twice a year, named by year and month: 2406, 2412, 2506, 2512. Updates arrive in between. Customers stay on a series for a long time, and large ones run several at once.

For a plugin this means a build, a signature and a test pass per supported series. Check the release notes of each series for the compiler and runtime it expects, and keep version differences in one place in the code.

Native mode and managed mode

NX runs in two ways. In native mode, parts are files in folders. In managed mode, NX runs inside Teamcenter, and parts are items and revisions in a database.

Code that opens, saves, names or searches parts behaves differently in each. A plugin written and tested only on a developer's native installation often fails on the first day at a customer who runs managed mode. Decide early which modes you support, and test both if the answer is "both".

A CI/CD pipeline for NX plugins

Signing makes NX builds awkward to automate, because one step needs Windows, NX tools and a licence. The pipeline we run splits the work:

1. Build, package and publish on Linux container runners. They are fast, cheap and disposable.
2. Sign on a dedicated Windows runner. It is tagged for this job only and holds the Siemens signing tools.
3. Treat the signing credential as a secret. It is stored as a protected, masked CI variable, written to disk only for the duration of the job, and wiped afterwards.

The credential touches one job on one machine; every other step runs on cheap, disposable runners.

Two more stages are worth adding once the basics run. A smoke test that starts NX in batch and confirms the plugin loads. And a journal that runs the main commands against a reference part and compares the result.

Connecting NX to Teamcenter and to the cloud

Three patterns cover most integration work.

Inside NX, let NX talk to Teamcenter. In managed mode, NX already handles check-out, save and revision rules. A plugin that goes through NX inherits that behaviour for free.

Outside NX, use Teamcenter's service interfaces. Reports, bulk property updates and workflow actions rarely need NX running at all.

For a cloud application and an on-premises Teamcenter, use a connector agent. The agent runs inside the customer's network and makes outbound connections only, so no inbound firewall rule is needed. It takes jobs from a queue, works under a least-privilege Teamcenter account and writes an audit log. This is the architecture we work with on a current project that links a cloud engineering application, plugins for NX and SolidWorks, and a customer-side Teamcenter.

One constraint shapes all three. Native NX part files come from NX. If a workflow must deliver native parts, NX or NX batch has to be somewhere in the loop. Settle where before you fix a scope.

Six questions before you start

1. Which NX series do your users run today, and which next year?
2. Native mode, managed mode, or both?
3. Who holds the author licence: you or your developer?
4. Does the interface need Block UI Styler dialogs or a custom window?
5. How will the plugin be deployed: a shared custom directory, an installer, a managed environment?
6. What must it produce: native parts, drawings, PMI, exports, data for another system?

Consedge Tech builds NX Open plugins and integrations alongside its Revit, Tekla and SolidWorks work. If you are planning an NX tool, book a Feasibility Review. You get a written verdict on feasibility in the API, the risks and what production will involve. Software companies that need NX capacity under their own brand can read about our partner model. For SolidWorks, see our SolidWorks API automation guide.

FAQ

Do users need an NX Open author licence to run a plugin?

Not if the plugin is signed. Only the developer who builds and signs it needs the author licence.

Which language should we use for NX Open?

C# is the usual choice for Windows teams and shares skills with other CAD platforms. C++ suits performance-critical or legacy code. Python is convenient for journals and scripts.

Does a plugin have to be rebuilt for every NX release?

Plan for it. Compatibility between series is not guaranteed, so a build, a fresh signature and a test pass per series is the safe routine.

Can NX automation run without a user interface?

Yes. NX can run journals and applications in batch. A licence is still required.