AutoCAD-Add-in nach BricsCAD portieren: was gleich bleibt, was nicht

CAD

Die Lizenzkosten steigen, ein Teil der Konstruktion soll auf BricsCAD wechseln – und die eigenen Add-ins sollen mit. Die gute Nachricht: BricsCAD spricht fast dieselbe .NET-Sprache wie AutoCAD. Die weniger gute: Das „fast“ steckt in Namensräumen, Oberfläche und Setup, und es zeigt sich gern erst beim Anwender.

Was gleich bleibt

Wer gewohnt ist, rechts zu fahren, und in England einen Mietwagen nimmt, findet Gas, Bremse und Lenkrad wie immer. Nur der Schalthebel sitzt links, und beim ersten Blinken geht der Scheibenwischer an. So ähnlich fühlt sich der Wechsel an. Die Klassen der BricsCAD-API heißen wie bei AutoCAD: Database, Transaction, BlockTableRecord, Editor, CommandMethod. Eine Transaktion wird genauso gestartet, bestätigt und entsorgt. Bricsys schreibt in seiner Entwicklerhilfe selbst, dass sich in der Regel aus demselben Quelltext Assemblys für beide Programme bauen lassen.

Anders sind die Hüllen um diese Klassen:

Zwei Punkte gehören in jede Planung. Laut Übersicht der Bricsys-Entwicklerhilfe gibt es .NET und BRX erst ab BricsCAD Pro, nicht in Lite. Und BricsCAD V26 lädt keine Add-ins mehr, die für das .NET Framework 4.8 gebaut wurden. Sie müssen mit dem .NET-8-SDK neu gebaut werden.

Ein Quelltext für beide: Schalter statt Kopie

Der naheliegende Weg – Projekt kopieren, Namensräume per Suchen und Ersetzen tauschen – rächt sich nach dem ersten Jahr. Dann gibt es zwei Fassungen, und jede Fehlerbehebung muss doppelt gemacht werden. Besser ist ein Quelltext mit einem Schalter. Die Projektdatei setzt für das BricsCAD-Ziel ein Symbol wie BRICSCAD, der Code wählt damit die Namensräume:

#if BRICSCAD
using Bricscad.ApplicationServices;
using Teigha.DatabaseServices;
using Teigha.Runtime;
#else
using Autodesk.AutoCAD.ApplicationServices;
using Autodesk.AutoCAD.DatabaseServices;
using Autodesk.AutoCAD.Runtime;
#endif

public class Befehle
{
    // Derselbe Befehl für AutoCAD und BricsCAD
    [CommandMethod("ZaehleKreise")]
    public void ZaehleKreise()
    {
        var dokument = Application.DocumentManager.MdiActiveDocument;
        var db = dokument.Database;
        var anzahl = 0;
        using (var tr = db.TransactionManager.StartTransaction())
        {
            var blockTable = (BlockTable)tr.GetObject(db.BlockTableId, OpenMode.ForRead);
            var modellbereich = (BlockTableRecord)tr.GetObject(
                blockTable[BlockTableRecord.ModelSpace], OpenMode.ForRead);
            foreach (ObjectId id in modellbereich)
            {
                if (tr.GetObject(id, OpenMode.ForRead) is Circle)
                {
                    anzahl++;
                }
            }
            tr.Commit();
        }
        dokument.Editor.WriteMessage($"\n{anzahl} Kreise im Modellbereich.");
    }
}

Alles unterhalb der using-Zeilen ist für beide Programme gleich. In der Projektdatei bekommt jedes Ziel seine Verweise, für BricsCAD BrxMgd.dll und TD_Mgd.dll aus dem Programmordner. Wie bei AutoCAD steht Private auf false, damit die DLLs nicht im Ausgabeordner landen. Weil BricsCAD V26 auf .NET 8 und AutoCAD 2027 auf .NET 10 läuft, baut ein Projekt mit TargetFrameworks beide Fassungen nacheinander. Wo sich die Programme wirklich unterscheiden, gehört der Code in eine dünne Adapterschicht – nicht als #if quer durch alle Dateien.

Wo die Unterschiede wirklich liegen

• Menüband und Bilder: Die Klassen in Bricscad.Windows ähneln denen von AutoCAD, sind aber nicht gleich. In unseren Add-ins war die Quickinfo eines Menüband-Knopfs in BricsCAD nur ein Text, ohne Bild und Formatierung. Bilder per WPF-Pack-Adresse blieben leer. Aus dem Ressourcenstrom geladen, erschienen sie zuverlässig.
• Laden und Setup: AutoCAD lädt Add-ins bequem aus einem Bundle-Ordner. Für BricsCAD beschreibt Bricsys das Laden über die Registry, unter Software\Bricsys\BricsCAD\<Version>\<Sprache>\Applications mit den Werten LOADER und LOADCTRLS, die man von AutoCAD kennt. Ihr Setup braucht dafür einen eigenen Zweig.
• Undokumentiertes: Was in AutoCAD aus Autodesk.AutoCAD.Internal oder über COM kommt, ist der erste Kandidat für Ärger. Prüfen Sie diese Stellen einzeln.
• Verhalten: Eine Methode mit gleichem Namen verhält sich nicht in jedem Randfall gleich. Der Compiler beweist nur, dass es die Namen gibt. Ob das Ergebnis stimmt, zeigt erst ein Test in BricsCAD.
• LISP und C++: BricsCAD kennt LISP samt den Visual-LISP-Funktionen. Für ObjectARX-Code gibt es BRX, oft genügt dort ein neues Kompilieren.

Aus der Praxis

Für ein großes CAD-Softwarehaus haben wir einen über zwölf Jahre gewachsenen Aufsatz für den Tiefbau modernisiert: mehrere hunderttausend Zeilen in C++, COM, MFC und ObjectARX. Nach Machbarkeitsstudie und Wirtschaftlichkeitsrechnung haben wir Oberfläche und CAD-Kern nach C# in die AutoCAD .NET API portiert – so, dass der Aufsatz zusätzlich in BricsCAD läuft. Der Code wurde dabei deutlich kürzer und einfacher. Nach demselben Prinzip ist unser eigenes Prüfwerkzeug für Zeichnungsrichtlinien gebaut: Der Prüfkern kennt kein CAD-Programm, schmale Adapter sprechen mit BricsCAD und mit Revit.

Typische Fehler

• Das Projekt wird kopiert, die Namensräume werden ersetzt. Nach einem Jahr laufen zwei Fassungen auseinander.
• Für BricsCAD V26 wird weiter mit dem .NET Framework 4.8 gebaut. V26 lädt das Add-in nicht.
• Die Rechnung geht von BricsCAD Lite aus. Dort läuft kein .NET-Add-in.
• Die DLL kam per Mail oder Download und ist von Windows blockiert. BricsCAD meldet dann „Operation is not supported“. Abhilfe schafft „Zulassen“ in den Dateieigenschaften.
• Das Setup kennt nur das AutoCAD-Bundle. In BricsCAD lädt das Add-in dann nicht von selbst.

Quellen: Bricsys Developer Reference, „dotNET overview“ und „Registry DemandLoad“; Bricsys-Hilfe, „How to develop and run .NET plugins in BricsCAD V26“; Ebi F. Eilber, AutoCAD .NET API (Fachbuch, erscheint voraussichtlich 2027); Fallstudie „Modernisierung eines AutoCAD-Aufsatzes für den Tiefbau“, Cadida-Fallstudien.