Choosing a Language for NXOpen: VB, C#, C++, and Python in Practice

The official docs describe each supported language's API surface, but real-world guidance on which language to actually pick comes mostly from community discussion. A well-regarded write-up on NX Journaling ("VB vs C++ for NXOpen") and a practitioner blog post from SWMS lay out the trade-offs developers actually weigh.

C++ vs VB: the classic NX Journaling comparison

C++ advantages:

• More concise, readable application code using standard C++ idioms.
• Uses pointers to objects rather than tags, which maps more directly onto the underlying object model.
• Native C++ exception handling.
• Strong typing caught at compile time.
• Full object-oriented inheritance/encapsulation support.
• Cannot be run as an interpreted journal — it must be compiled.

VB advantages:

• Roughly an order of magnitude more online documentation and examples exist for VB NXOpen than for C++.
• More accessible to non-programmer teammates who may need to maintain the code later.
• Structured exception handling comparable to C++, and also strongly typed unless explicitly disabled.
• Full access to the SNAP library for simplified common tasks.
• Easier for a team to maintain collectively.

The pragmatic conclusion from that discussion: the best language is "the one you're most familiar with." If colleagues will need to maintain your code and your shop doesn't have deep C++ expertise, VB's superior documentation and broader familiarity make it the practical default — C++'s power doesn't pay for itself without a team that can support it. C# is called out as a middle ground: C++-like syntax, fewer legacy VB quirks, and still full access to the SNAP library.

Architectural guidance from SWMS (application extensions blog)

A few points from SWMS's practitioner blog on structuring NXOpen application extensions, which go beyond what the API reference documents:

• Modern .NET languages recommended over legacy C/C++ for new development, favoring maintainability and development speed over raw performance.
• Session.GetSession() is a singleton — it's your one gateway to all NX data types and currently loaded parts, and application architecture should treat it that way rather than passing session references around ad hoc.
• Start from a recorded journal, then productionize it. Record the process you want to automate as a journal to understand what NX actually does, then use that as a template — this "can even be automated without a costly additional license" since Python/.NET journals don't require a developer license the way compiled C++/Java do.
• Recorded journals only capture literal values. A journal will hardcode whatever numbers you typed during recording; production code needs a deliberate refactor to add real input handling (dialogs, WinForms/WPF, or NX's own Block UI Styler) rather than relying on what the recorder captured.
• Reuse standard UI frameworks. WinForms, WPF, or Block UI Styler are recommended over building custom dialog infrastructure from scratch.
• Target frequent, small workflows for automation ROI. The advice given: collapsing a multi-step export wizard into "one click" is a better automation target than something used rarely, because small per-use time savings compound.

Practical takeaway

• Match language choice to team skill and maintenance realities, not to raw capability — VB/C# are the pragmatic default for most shops; C++ pays off mainly with strong in-house C++ expertise.
• Use journal recording as a starting point, not a finished product — literal/hardcoded values from recording must be deliberately parameterized.
• Treat Session.GetSession() as the intentional single entry point into NX state in your application's architecture.