Porting an AutoCAD add-in to BricsCAD: what stays the same and what doesn’t

CAD

Licence costs are rising, part of the design team is moving to BricsCAD – and your own add-ins have to come along. The good news: BricsCAD speaks almost the same .NET language as AutoCAD. The less good news: the “almost” hides in namespaces, the user interface and setup, and it tends to show up only at the user’s desk.

What stays the same

Rent a car in England and you find the pedals and steering wheel where they always are – but your first attempt to indicate switches on the wipers. Moving to BricsCAD feels much the same. The classes of the BricsCAD API have the same names as in AutoCAD: Database, Transaction, BlockTableRecord, Editor, CommandMethod. A transaction is started, committed and disposed of in exactly the same way. According to Bricsys, one source can generally build assemblies for both programs.

What differs are the wrappers around these classes:

Two points belong in every plan. According to the Bricsys developer reference, .NET and BRX require BricsCAD Pro or higher, not Lite. And BricsCAD V26 no longer loads add-ins built for .NET Framework 4.8. They have to be rebuilt with the .NET 8 SDK.

One source for both: a switch instead of a copy

The obvious route – copy the project and swap the namespaces with search and replace – takes its revenge after the first year. By then every bug fix has to be made twice. One source with a switch is better. The project file defines a symbol such as BRICSCAD for the BricsCAD target, and the code uses it to choose the namespaces:

#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 Commands
{
    // The same command for AutoCAD and BricsCAD
    [CommandMethod("CountCircles")]
    public void CountCircles()
    {
        var document = Application.DocumentManager.MdiActiveDocument;
        var db = document.Database;
        var count = 0;
        using (var tr = db.TransactionManager.StartTransaction())
        {
            var blockTable = (BlockTable)tr.GetObject(db.BlockTableId, OpenMode.ForRead);
            var modelSpace = (BlockTableRecord)tr.GetObject(
                blockTable[BlockTableRecord.ModelSpace], OpenMode.ForRead);
            foreach (ObjectId id in modelSpace)
            {
                if (tr.GetObject(id, OpenMode.ForRead) is Circle)
                {
                    count++;
                }
            }
            tr.Commit();
        }
        document.Editor.WriteMessage($"\n{count} circles in model space.");
    }
}

Everything below the using lines is the same for both programs. In the project file each target gets its own references, for BricsCAD BrxMgd.dll and TD_Mgd.dll from the program folder. As with AutoCAD, Private is set to false so that the DLLs do not end up in the output folder. With TargetFrameworks, one project builds the versions for BricsCAD V26 (.NET 8) and AutoCAD 2027 (.NET 10) one after the other. Where the programs really differ, the code belongs in a thin adapter layer – not in #if blocks scattered across every file.

Where the real differences are

• Ribbon and images: the classes in Bricscad.Windows resemble those of AutoCAD but are not identical. In our add-ins, a ribbon button’s tooltip in BricsCAD was plain text only. Images loaded via a WPF pack URI stayed empty; loaded from the resource stream, they appeared reliably.
• Loading and setup: AutoCAD conveniently loads add-ins from a bundle folder. For BricsCAD, Bricsys describes loading via the registry, under Software\Bricsys\BricsCAD\<Version>\<Language>\Applications with the values LOADER and LOADCTRLS familiar from AutoCAD. Your setup needs its own branch for this.
• Undocumented features: anything that comes from Autodesk.AutoCAD.Internal or via COM in AutoCAD is the first candidate for trouble.
• Behaviour: a method with the same name does not behave the same in every edge case. The compiler only proves that the names exist; only a test in BricsCAD shows whether the result is right.
• LISP and C++: BricsCAD supports LISP including the Visual LISP functions. For ObjectARX code there is BRX, where a recompile is often enough.

From practice

For a large CAD software company we modernised a civil engineering add-on that had grown over twelve years: several hundred thousand lines of C++, COM, MFC and ObjectARX. After a feasibility study and a cost-benefit calculation, we ported the user interface and CAD core to C# and the AutoCAD .NET API, so that the add-on also runs in BricsCAD. The code became considerably shorter and simpler. Our own checking tool for drawing standards follows the same principle: the checking core knows no CAD program, and thin adapters talk to BricsCAD and to Revit.

Typical mistakes

• The project is copied and the namespaces are replaced. A year later the two versions have drifted apart.
• The add-in for BricsCAD V26 is still built for .NET Framework 4.8. V26 does not load it.
• The business case assumes BricsCAD Lite. No .NET add-in runs there.
• The DLL arrived by email or download and is blocked by Windows. BricsCAD then reports “Operation is not supported”. Ticking “Unblock” in the file properties fixes it.
• The setup only knows the AutoCAD bundle. In BricsCAD the add-in then does not load by itself.

Sources: Bricsys Developer Reference, “dotNET overview” and “Registry DemandLoad”; Bricsys Help, “How to develop and run .NET plugins in BricsCAD V26”; Ebi F. Eilber, AutoCAD .NET API (book, expected 2027); case study “Modernising an AutoCAD add-on for civil engineering”, Cadida case studies.