NXOpen Python vs C#: The Short Version
NXOpen Python vs C# is a deployment decision, not a language preference. Python runs as an unsigned journal on any NX seat and needs no compiler; C# compiles to a signed add-in with a proper UI and better performance on large assemblies. inteliScience ships both, and the choice follows how the automation has to reach engineers.
| Python journal | Compiled C# add-in | |
|---|---|---|
| Gets to an engineer’s seat by | Copying one file | Build, sign, deploy |
| Extra licence to ship it | None | Author licence for signing |
| Best at | Iteration, small teams, batch work | Dialogs, large assemblies, .NET estates |
The Problem: You Pick Once and Live With It for Years
Almost nobody rewrites an NX automation in the other language. The first journal someone records and edits sets the language for everything built after it, because the second script borrows from the first, the third borrows from the second, and three years later there are forty files and a build pipeline nobody wants to touch.
So the question is worth twenty minutes up front. It is also badly served online. Search for the answer and you get forum threads from 2014 arguing about VB.NET, plus tutorial collections aimed at beginners. The most-starred community Python collection, Foadsf/NXOpen_Python_tutorials, sits at 104 stars and 13 forks, last pushed 19 February 2026 (retrieved 18 August 2026). That is the entire public signal for an API surface of several thousand classes — which is also why code assistants are noticeably better at the Python variant than the C# one.
Both languages talk to the same API. NX Open ships bindings for C++, C# and VB.NET, Java and Python, and anything you can do interactively in NX you can do from code in any of them. The differences that matter sit around the code: licences, signing, deployment, debugging, and who on your team can still change it in two years.
NXOpen Python vs C#: Nine Criteria That Actually Differ
Ignore syntax comparisons. These are the criteria that change project outcomes, based on NX 2506, the June 2025 release; its June 2026 successor ships as Designcenter 2606.
| Criterion | Python | C# |
|---|---|---|
| Runs as an unsigned journal | Yes | Yes |
| Compiler needed on the target machine | No | Yes, to build the add-in |
| Signing licence to distribute | Not for journals | Author licence for compiled code |
| Custom dialogs and ribbon integration | Workable, but the .NET route is better documented | Full Block UI Styler and WinForms support |
| Third-party libraries | Only via an external interpreter | NuGet in compiled projects; journals restricted |
| Large-assembly performance | Interpreted — fine for I/O, slower in tight geometry loops | Compiled, measurably faster |
| Debugging | Listing window, print statements, external IDE with setup effort | Visual Studio attached to the NX process |
| Who can maintain it | Any engineer who can read code | A .NET developer plus a build pipeline |
| Distribution | Copy a .py file | Build, sign, ship DLL and menu files |
Read that table as two clusters rather than nine separate points. Rows one to three and row nine are about getting the thing onto a seat. Rows four, six and seven are about how far it can grow. Python wins the first cluster outright. C# wins the second.
The Same Automation, Written Twice
Here is a job every variant-design team recognises: drive a named expression, rebuild the model, report the result. First in Python, as a journal you can run straight from Tools → Journal → Play.
import NXOpen
def main():
session = NXOpen.Session.GetSession()
work_part = session.Parts.Work
lw = session.ListingWindow
lw.Open()
# Undo mark first — without it a failed update leaves the part dirty
mark = session.SetUndoMark(NXOpen.Session.MarkVisibility.Visible, "Set width")
width = work_part.Expressions.FindObject("width")
work_part.Expressions.Edit(width, "180")
session.UpdateManager.DoUpdate(mark)
lw.WriteLine(f"width is now {width.RightHandSide}")
if __name__ == "__main__":
main()The same logic in C#. Note GetUnloadOption at the bottom — managed NX Open code needs it to tell NX when to release the assembly, and forgetting it is the classic reason a rebuilt DLL appears not to update until NX restarts.
using NXOpen;
public class Program
{
public static void Main(string[] args)
{
Session session = Session.GetSession();
Part workPart = session.Parts.Work;
ListingWindow lw = session.ListingWindow;
lw.Open();
// Undo mark first — same reason as the Python version
Session.UndoMarkId mark =
session.SetUndoMark(Session.MarkVisibility.Visible, "Set width");
Expression width = (Expression)workPart.Expressions.FindObject("width");
workPart.Expressions.Edit(width, "180");
session.UpdateManager.DoUpdate(mark);
lw.WriteLine("width is now " + width.RightHandSide);
}
// Tells NX when to unload the assembly; omit it and stale code keeps running
public static int GetUnloadOption(string dummy)
{
return (int)Session.LibraryUnloadOption.Immediately;
}
}Fourteen lines against twenty-three, and the extra nine are ceremony rather than logic. That gap stays roughly constant no matter how big the automation gets, which is why the line-count argument is the weakest one in this whole comparison — and why we would advise against choosing on it.
Licensing and Deployment Decide More Than Syntax
This is the section that settles most projects, and it is the one least discussed in the tutorials.
Python and .NET code can both run as journals with no developer licence. That is the quiet advantage: an engineer records a journal, you edit it, and it runs on their seat this afternoon. C and C++ and Java do not get this — compiling and running those requires a developer licence.
Journals come with two hard limits. They must live in a single file, and they cannot reference libraries beyond the ones NX permits — NXOpen.dll, NXOpen.Utilities.dll, NXOpenUI.dll, NXOpen.UF.dll and a short list of core .NET assemblies. The moment you need a real project structure or an outside dependency, you are compiling.
And compiling changes the licence position. Compiled .NET code has to be signed with the Author licence before NX will execute it. That is a procurement conversation, not a technical one, and it is worth having with your Siemens reseller before the architecture is fixed rather than after — licence terms vary by contract and by region.
Two more deployment details from the current releases. NX 2412 requires .NET Framework 4.8 on the machine to execute custom .NET applications and to replay .NET journals. With NX 2506, Siemens documents Microsoft’s move from .NET Framework to .NET (Core), with the certified version named in the Programming Tools Product Notes — so pin your target framework to what the notes say for your exact release rather than to whatever Visual Studio defaults to.
On the Python side, the interpreter that ships inside NX is deliberately bare. If you need numpy, pandas or anything else from PyPI, you point NX at a separately installed distribution through UGII_PYTHON_LIBRARY_DIR and UGII_PYTHONPATH. It works, and it is a real dependency you now have to manage on every seat — which quietly cancels out part of Python’s deployment advantage. Check the version you are actually running before you build against it:
import sys, NXOpen
session = NXOpen.Session.GetSession()
lw = session.ListingWindow
lw.Open()
lw.WriteLine(sys.version) # the shipped version changes between NX releasesReady to go deeper? What language models get right and wrong when they write this code — and the verification loop that keeps generated journals off production seats — is in our practical guide to NX Open code generation.
Where Each One Wins
Choose Python for journals, exploration, batch processing, drawing and PMI updates, data extraction, and anything a small engineering team will own. Most of the NX programming work we deliver starts here, for one reason above the others: no compiler is needed on the target machine. When the target sits in a validated environment — or in an air-gapped defence network where installing a toolchain means a change request — that stops being a convenience and becomes the deciding factor.
Choose C# when the automation needs a dialog engineers will use daily, when it has to slot into an existing .NET estate with shared libraries and a CI pipeline, when you are running tight geometry loops over large assemblies, or when you want it shipped as a compiled artefact rather than readable source. Configurator-style tools that generate variants from a customer specification usually end up here once they have real users.
Our clear recommendation: prototype in Python regardless. Get the API calls right where the feedback loop is seconds, then port to C# only if the criteria above force it. Porting a working 200-line journal is a day of work. Discovering after three weeks of C# that the API does not do what you assumed is not.
The pattern we would push back on is the one where a team picks C# on day one because it feels more professional, then spends the project fighting build and signing infrastructure for an automation that four people run twice a month.
What to Check Before You Commit
Five questions, in the order they usually decide it:
- Does it need a dialog? A real one with fields and validation, not a listing window. Yes → C#.
- Who maintains it in two years? If the answer is “the design team”, Python. If it is “our software group”, either.
- Where does it run? Locked-down, validated or offline seats favour Python journals — nothing to install, nothing to sign.
- Does it touch large assemblies in a loop? Measure a Python prototype before assuming C#. Most automations are I/O-bound on file and Teamcenter operations, not CPU-bound.
- Do you have the Author licence? If not, and procurement is slow, that alone can settle it for the next six months.
If the first four answers point one way and the fifth points the other, follow the fifth. Licences are the constraint you cannot engineer around.
Frequently Asked Questions
Is NXOpen Python slower than C#?
Yes, but usually not where it matters. C# is compiled and wins on tight geometry loops and large-assembly traversal. Most real automations spend their time on file I/O, Teamcenter round-trips and model updates, where both languages wait on the same NX operations. Measure your actual workload before treating performance as the deciding criterion.
Do I need a licence to run NXOpen Python or C#?
Journals in Python or .NET run without a developer licence, which is why they are the fastest route to something working. Compiled .NET code is different: it has to be signed with the Author licence before NX will execute it, and C++ or Java need a developer licence to compile and run at all. Confirm the exact terms with your Siemens reseller, since they vary by contract.
How much does it cost to move a Python journal to a compiled C# add-in?
For a self-contained journal of a few hundred lines, budget one to three days of porting plus the setup of a build and signing pipeline — the pipeline is the part teams underestimate. The API calls translate almost one to one; the effort sits in project structure, GetUnloadOption, deployment and menu integration. If the Author licence is not already in place, procurement will take longer than the code.
Can I use numpy or pandas in an NXOpen Python journal?
Not with the interpreter that ships inside NX, which is intentionally minimal. You install a separate Python distribution of a matching version and point NX at it with the UGII_PYTHON_LIBRARY_DIR and UGII_PYTHONPATH environment variables. That works well, but it becomes a dependency you have to maintain on every seat that runs the automation.
NXOpen Python vs C# — which should a new team learn first?
Python, in almost every case. Recorded journals give you working code to modify on day one, the feedback loop is seconds rather than a build cycle, and the public examples that do exist are mostly Python. Move to C# when a specific requirement — a dialog, a .NET estate, a performance ceiling — makes the case for it.
Next Step
inteliScience builds NX automations in both languages, from single Python journals to signed C# add-ins, with senior engineers delivering from Romania, just one hour ahead of our DACH clients. If you are standing at this decision with a real automation behind it, a short conversation usually saves more time than another week of evaluation.