NXOpen Python vs. C#: Die Kurzfassung
NXOpen Python vs. C# ist eine Deployment-Entscheidung, keine Frage der Sprachvorliebe. Python läuft als unsigniertes Journal auf jedem NX-Arbeitsplatz und braucht keinen Compiler; C# wird zu einem signierten Add-in kompiliert, mit richtiger Oberfläche und besserer Performance bei großen Baugruppen. inteliScience liefert beides — die Wahl richtet sich danach, wie die Automatisierung die Konstrukteure erreichen muss.
| Python-Journal | Kompiliertes C#-Add-in | |
|---|---|---|
| Kommt auf den Arbeitsplatz durch | Kopieren einer Datei | Bauen, signieren, ausrollen |
| Zusätzliche Lizenz für die Auslieferung | Keine | Author-Lizenz zum Signieren |
| Stark bei | Iteration, kleine Teams, Stapelverarbeitung | Dialoge, große Baugruppen, .NET-Landschaften |
Das Problem: Man wählt einmal und lebt jahrelang damit
Fast niemand schreibt eine NX-Automatisierung in der anderen Sprache neu. Das erste Journal, das jemand aufzeichnet und anpasst, legt die Sprache für alles Folgende fest — denn das zweite Skript borgt sich vom ersten, das dritte vom zweiten, und drei Jahre später gibt es vierzig Dateien und eine Build-Pipeline, die niemand anfassen will.
Die Frage ist deshalb zwanzig Minuten Vorüberlegung wert. Online wird sie schlecht beantwortet. Wer sucht, findet Forenbeiträge von 2014 über VB.NET und Tutorial-Sammlungen für Einsteiger. Die meistbeachtete Python-Sammlung der Community, Foadsf/NXOpen_Python_tutorials, steht bei 104 Sternen und 13 Forks, zuletzt aktualisiert am 19. Februar 2026 (abgerufen am 18. August 2026). Das ist das gesamte öffentliche Signal für eine API-Oberfläche mit mehreren tausend Klassen — und auch der Grund, warum Code-Assistenten bei der Python-Variante merklich besser sind als bei der C#-Variante.
Beide Sprachen sprechen dieselbe API an. NX Open liefert Bindings für C++, C# und VB.NET, Java und Python, und alles, was Sie in NX interaktiv tun können, können Sie aus dem Code heraus in jeder davon tun. Die Unterschiede, auf die es ankommt, liegen um den Code herum: Lizenzen, Signierung, Deployment, Debugging — und wer im Team die Sache in zwei Jahren noch ändern kann.
NXOpen Python vs. C#: Neun Kriterien, die sich wirklich unterscheiden
Syntax-Vergleiche können Sie ignorieren. Dies sind die Kriterien, die Projektergebnisse verändern — auf Basis von NX 2506, dem Release vom Juni 2026, das Siemens jetzt als Designcenter führt, allgemein verfügbar seit 23. Juni 2026.
| Kriterium | Python | C# |
|---|---|---|
| Läuft als unsigniertes Journal | Ja | Ja |
| Compiler auf dem Zielrechner nötig | Nein | Ja, zum Bauen des Add-ins |
| Signier-Lizenz für die Verteilung | Nicht für Journals | Author-Lizenz für kompilierten Code |
| Eigene Dialoge und Ribbon-Integration | Machbar, aber der .NET-Weg ist besser dokumentiert | Voller Block-UI-Styler- und WinForms-Support |
| Fremdbibliotheken | Nur über einen externen Interpreter | NuGet in kompilierten Projekten; in Journals eingeschränkt |
| Performance bei großen Baugruppen | Interpretiert — für I/O ausreichend, langsamer in engen Geometrie-Schleifen | Kompiliert, messbar schneller |
| Debugging | Listing-Fenster, print-Ausgaben, externe IDE mit Einrichtungsaufwand | Visual Studio am NX-Prozess angehängt |
| Wer es pflegen kann | Jeder Ingenieur, der Code lesen kann | Ein .NET-Entwickler plus eine Build-Pipeline |
| Verteilung | Eine .py -Datei kopieren | DLL und Menüdateien bauen, signieren, ausliefern |
Lesen Sie die Tabelle als zwei Gruppen statt als neun Einzelpunkte. Die Zeilen eins bis drei und Zeile neun drehen sich darum, wie die Sache auf einen Arbeitsplatz kommt. Die Zeilen vier, sechs und sieben drehen sich darum, wie weit sie wachsen kann. Die erste Gruppe gewinnt Python klar. Die zweite gewinnt C#.
Dieselbe Automatisierung, zweimal geschrieben
Hier eine Aufgabe, die jedes Variantenkonstruktions-Team kennt: einen benannten Ausdruck setzen, das Modell neu aufbauen, das Ergebnis ausgeben. Zuerst in Python, als Journal, das Sie direkt ausführen können über 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()Dieselbe Logik in C#. Beachten Sie GetUnloadOption am Ende — verwalteter NX-Open-Code braucht das, um NX mitzuteilen, wann die Assembly freigegeben wird. Es zu vergessen ist der klassische Grund, warum eine neu gebaute DLL erst nach einem NX-Neustart zu wirken scheint.
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;
}
}Vierzehn Zeilen gegen sechsundzwanzig, und die zusätzlichen zwölf sind Zeremonie, nicht Logik. Dieser Abstand bleibt ungefähr konstant, egal wie groß die Automatisierung wird — weshalb das Zeilenzahl-Argument das schwächste in diesem ganzen Vergleich ist und wir davon abraten würden, danach zu entscheiden.
Lizenzierung und Deployment entscheiden mehr als die Syntax
Das ist der Abschnitt, der die meisten Projekte entscheidet — und der in den Tutorials am wenigsten vorkommt.
Python- und .NET-Code können beide als Journals ohne Entwicklerlizenz laufen. Das ist der stille Vorteil: Ein Ingenieur zeichnet ein Journal auf, Sie passen es an, und es läuft noch heute Nachmittag auf seinem Arbeitsplatz. C, C++ und Java haben das nicht — Kompilieren und Ausführen erfordert dort eine Entwicklerlizenz.
Journals bringen zwei harte Grenzen mit. Sie müssen in einer einzigen Datei liegen, und sie dürfen keine Bibliotheken jenseits der von NX erlaubten referenzieren — NXOpen.dll, NXOpen.Utilities.dll, NXOpenUI.dll, NXOpen.UF.dll und eine kurze Liste von .NET-Kernassemblies. Sobald Sie eine echte Projektstruktur oder eine externe Abhängigkeit brauchen, kompilieren Sie.
Und Kompilieren verändert die Lizenzlage. Kompilierter .NET-Code muss mit der Author-Lizenz signiert werden, bevor NX ihn ausführt. Das ist ein Beschaffungsthema, kein technisches — und es lohnt sich, das mit dem Siemens-Reseller zu klären, bevor die Architektur feststeht, nicht danach. Lizenzbedingungen unterscheiden sich je nach Vertrag und Region.
Zwei weitere Deployment-Details aus den aktuellen Releases. NX 2412 setzt .NET Framework 4.8 auf dem Rechner voraus, um eigene .NET-Anwendungen auszuführen und .NET-Journals abzuspielen. Mit NX 2506 dokumentiert Siemens Microsofts Wechsel von .NET Framework zu .NET (Core); die zertifizierte Version steht in den Programming Tools Product Notes — legen Sie Ihr Ziel-Framework also auf das fest, was die Notes für genau Ihr Release nennen, und nicht auf das, was Visual Studio vorgibt.
Auf der Python-Seite ist der in NX mitgelieferte Interpreter bewusst spartanisch. Brauchen Sie numpy, pandas oder irgendetwas anderes von PyPI, verweisen Sie NX über UGII_PYTHON_LIBRARY_DIR und UGII_PYTHONPATH. Das funktioniert, und es ist eine echte Abhängigkeit, die Sie nun auf jedem Arbeitsplatz verwalten müssen — was einen Teil von Pythons Deployment-Vorteil stillschweigend wieder aufhebt. Prüfen Sie die tatsächlich laufende Version, bevor Sie dagegen entwickeln:
import sys, NXOpen
session = NXOpen.Session.GetSession()
lw = session.ListingWindow
lw.Open()
lw.WriteLine(sys.version) # the shipped version changes between NX releasesTiefer einsteigen? Was Sprachmodelle beim Schreiben dieses Codes richtig und falsch machen — und die Prüfschleife, die generierte Journals von Produktivarbeitsplätzen fernhält — steht in unserem praxisnahen Leitfaden zur NX-Open-Codegenerierung.
Wo jede Sprache gewinnt
Wählen Sie Python für Journals, Exploration, Stapelverarbeitung, Zeichnungs- und PMI-Aktualisierungen, Datenextraktion und alles, was ein kleines Konstruktionsteam selbst betreuen wird. Der Großteil der NX-Programmierarbeit, die wir liefern beginnt hier, aus einem Grund vor allen anderen: Auf dem Zielrechner wird kein Compiler benötigt. Wenn das Ziel in einer validierten Umgebung steht — oder in einem air-gapped Verteidigungsnetz in dem das Installieren einer Toolchain einen Änderungsantrag bedeutet, hört das auf, eine Bequemlichkeit zu sein, und wird zum ausschlaggebenden Faktor.
Wählen Sie C# wenn die Automatisierung einen Dialog braucht, den Ingenieure täglich benutzen, wenn sie sich in eine bestehende .NET-Landschaft mit gemeinsamen Bibliotheken und CI-Pipeline einfügen muss, wenn Sie enge Geometrie-Schleifen über große Baugruppen laufen lassen, oder wenn Sie sie als kompiliertes Artefakt statt als lesbaren Quellcode ausliefern wollen. Konfigurator-artige Werkzeuge, die Varianten aus einer Kundenspezifikation erzeugen landen meist hier, sobald sie echte Nutzer haben.
Unsere klare Empfehlung: prototypisieren Sie in jedem Fall zuerst in Python. Bringen Sie die API-Aufrufe dort in Ordnung, wo die Rückmeldung in Sekunden kommt, und portieren Sie erst dann nach C#, wenn die obigen Kriterien es erzwingen. Ein funktionierendes 200-Zeilen-Journal zu portieren ist ein Tagewerk. Nach drei Wochen C# festzustellen, dass die API nicht das tut, was Sie angenommen haben, ist es nicht.
Das Muster, von dem wir abraten würden, ist jenes, bei dem ein Team am ersten Tag C# wählt, weil es professioneller wirkt, und dann das Projekt damit verbringt, gegen Build- und Signier-Infrastruktur zu kämpfen — für eine Automatisierung, die vier Leute zweimal im Monat ausführen.
Was Sie prüfen sollten, bevor Sie sich festlegen
Fünf Fragen, in der Reihenfolge, in der sie meist entscheiden:
- Braucht es einen Dialog? Einen echten, mit Feldern und Validierung, kein Listing-Fenster. Ja → C#.
- Wer pflegt es in zwei Jahren? Lautet die Antwort “das Konstruktionsteam”, dann Python. Lautet sie “unsere Softwareabteilung”, dann beides.
- Wo läuft es? Abgeschottete, validierte oder offline betriebene Arbeitsplätze sprechen für Python-Journals — nichts zu installieren, nichts zu signieren.
- Greift es in einer Schleife auf große Baugruppen zu? Messen Sie einen Python-Prototyp, bevor Sie C# annehmen. Die meisten Automatisierungen sind I/O-gebunden durch Datei- und Teamcenter-Operationen, nicht CPU-gebunden.
- Haben Sie die Author-Lizenz? Wenn nicht, und die Beschaffung ist langsam, kann allein das die Frage für die nächsten sechs Monate entscheiden.
Zeigen die ersten vier Antworten in die eine Richtung und die fünfte in die andere, folgen Sie der fünften. Lizenzen sind die Randbedingung, um die man nicht herumkonstruieren kann.
Häufig gestellte Fragen
Ist NXOpen Python langsamer als C#?
Ja, aber meist nicht dort, wo es zählt. C# ist kompiliert und gewinnt bei engen Geometrie-Schleifen und beim Durchlaufen großer Baugruppen. Die meisten realen Automatisierungen verbringen ihre Zeit mit Datei-I/O, Teamcenter-Zugriffen und Modell-Updates — dort warten beide Sprachen auf dieselben NX-Operationen. Messen Sie Ihre tatsächliche Last, bevor Sie Performance zum entscheidenden Kriterium machen.
Brauche ich eine Lizenz, um NXOpen Python oder C# auszuführen?
Journals in Python oder .NET laufen ohne Entwicklerlizenz — deshalb sind sie der schnellste Weg zu etwas Lauffähigem. Kompilierter .NET-Code ist etwas anderes: Er muss mit der Author-Lizenz signiert werden, bevor NX ihn ausführt. C++ oder Java brauchen für Kompilierung und Ausführung ohnehin eine Entwicklerlizenz. Klären Sie die genauen Bedingungen mit Ihrem Siemens-Reseller, sie unterscheiden sich je nach Vertrag.
Was kostet es, ein Python-Journal auf ein kompiliertes C#-Add-in umzustellen?
Für ein eigenständiges Journal von einigen hundert Zeilen rechnen Sie mit ein bis drei Tagen Portierung plus dem Aufbau einer Build- und Signier-Pipeline — die Pipeline ist der Teil, den Teams unterschätzen. Die API-Aufrufe lassen sich fast eins zu eins übertragen; der Aufwand steckt in Projektstruktur, GetUnloadOption, Deployment und Menü-Integration. Ist die Author-Lizenz nicht bereits vorhanden, dauert die Beschaffung länger als der Code.
Kann ich numpy oder pandas in einem NXOpen-Python-Journal verwenden?
Nicht mit dem Interpreter, der in NX mitgeliefert wird — der ist bewusst minimal gehalten. Sie installieren eine separate Python-Distribution passender Version und verweisen NX darauf über die UGII_PYTHON_LIBRARY_DIR und UGII_PYTHONPATH -Umgebungsvariablen. Das funktioniert gut, wird aber zu einer Abhängigkeit, die Sie auf jedem Arbeitsplatz pflegen müssen, der die Automatisierung ausführt.
NXOpen Python vs. C# — was sollte ein neues Team zuerst lernen?
Python, in nahezu jedem Fall. Aufgezeichnete Journals liefern vom ersten Tag an lauffähigen Code zum Anpassen, die Rückmeldung kommt in Sekunden statt nach einem Build-Zyklus, und die öffentlich verfügbaren Beispiele sind überwiegend Python. Wechseln Sie zu C#, wenn eine konkrete Anforderung dafür spricht — ein Dialog, eine .NET-Landschaft, eine Performance-Grenze.
Nächster Schritt
inteliScience baut NX-Automatisierungen in beiden Sprachen, von einzelnen Python-Journals bis zu signierten C#-Add-ins, mit erfahrenen Ingenieuren aus Rumänien, unseren DACH-Kunden nur eine Stunde voraus. Wenn Sie vor dieser Entscheidung stehen und eine echte Automatisierung dahinter haben, spart ein kurzes Gespräch meist mehr Zeit als eine weitere Woche Evaluierung.
