Portar un add-in de AutoCAD a BricsCAD: qué se mantiene y qué no

CAD

Los costes de las licencias suben, una parte del departamento de diseño debe pasar a BricsCAD, y los add-ins propios tienen que acompañarla. La buena noticia: BricsCAD habla casi el mismo lenguaje .NET que AutoCAD. La no tan buena: el «casi» está en los espacios de nombres, la interfaz y la instalación, y suele manifestarse en casa del usuario.

Lo que sigue igual

Quien está acostumbrado a conducir por la derecha y alquila un coche en Inglaterra encuentra el acelerador, el freno y el volante como siempre. Solo la palanca de cambios está a la izquierda, y al poner el intermitente por primera vez se encienden los limpiaparabrisas. Algo parecido se siente con el cambio. Las clases de la API de BricsCAD se llaman igual que en AutoCAD: Database, Transaction, BlockTableRecord, Editor, CommandMethod. Una transacción se inicia, se confirma y se libera exactamente igual. La propia Bricsys escribe en su ayuda para desarrolladores que, por regla general, a partir del mismo código fuente se pueden compilar ensamblados para ambos programas.

Lo que es distinto son los envoltorios de estas clases:

Dos puntos deben formar parte de cualquier planificación. Según la visión general de la ayuda para desarrolladores de Bricsys, .NET y BRX solo están disponibles a partir de BricsCAD Pro, no en Lite. Y BricsCAD V26 ya no carga add-ins compilados para .NET Framework 4.8. Hay que volver a compilarlos con el SDK de .NET 8.

Un código fuente para ambos: un conmutador en lugar de una copia

El camino más obvio (copiar el proyecto y cambiar los espacios de nombres con buscar y reemplazar) se paga caro al cabo del primer año. Entonces hay dos versiones, y cada corrección de errores debe hacerse dos veces. Es mejor un código fuente con un conmutador. El archivo de proyecto define para el destino BricsCAD un símbolo como BRICSCAD, y el código elige con él los espacios de nombres:

#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

{

    // El mismo comando para AutoCAD y 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.");

    }

}

Todo lo que hay debajo de las líneas using es igual para ambos programas. En el archivo de proyecto, cada destino recibe sus referencias; para BricsCAD, BrxMgd.dll y TD_Mgd.dll de la carpeta del programa. Como en AutoCAD, Private está en false para que las DLL no acaben en la carpeta de salida. Como BricsCAD V26 funciona con .NET 8 y AutoCAD 2027 con .NET 10, un proyecto con TargetFrameworks compila ambas versiones una tras otra. Donde los programas difieren de verdad, el código debe ir en una capa adaptadora fina, no como #if repartidos por todos los archivos.

Dónde están realmente las diferencias

• Cinta de opciones e imágenes: las clases de Bricscad.Windows se parecen a las de AutoCAD, pero no son iguales. En nuestros add-ins, la información rápida de un botón de la cinta de opciones era en BricsCAD solo un texto, sin imagen ni formato. Las imágenes mediante una dirección pack de WPF quedaban vacías. Cargadas desde el flujo de recursos, aparecían de forma fiable.
• Carga e instalación: AutoCAD carga cómodamente los add-ins desde una carpeta de bundle. Para BricsCAD, Bricsys describe la carga a través del registro, en Software\Bricsys\BricsCAD\<Version>\<Sprache>\Applications, con los valores LOADER y LOADCTRLS que ya se conocen de AutoCAD. Su instalador necesita para ello una rama propia.
• Lo no documentado: lo que en AutoCAD procede de Autodesk.AutoCAD.Internal o de COM es el primer candidato a dar problemas. Revise estos puntos uno por uno.
• Comportamiento: un método con el mismo nombre no se comporta igual en todos los casos límite. El compilador solo demuestra que los nombres existen. Si el resultado es correcto, solo lo muestra una prueba en BricsCAD.
• LISP y C++: BricsCAD conoce LISP, incluidas las funciones de Visual LISP. Para el código ObjectARX existe BRX; a menudo basta con volver a compilar.

De la práctica

Para una gran empresa de software CAD modernizamos una aplicación vertical para obra civil que había crecido durante más de doce años: varios cientos de miles de líneas en C++, COM, MFC y ObjectARX. Tras un estudio de viabilidad y un cálculo de rentabilidad, portamos la interfaz y el núcleo CAD a C# en la AutoCAD .NET API, de forma que la aplicación funciona además en BricsCAD. El código se volvió así mucho más corto y sencillo. Según el mismo principio está construida nuestra propia herramienta de comprobación de normas de dibujo: el núcleo de comprobación no conoce ningún programa CAD, y unos adaptadores finos se comunican con BricsCAD y con Revit.

Errores típicos

• Se copia el proyecto y se sustituyen los espacios de nombres. Al cabo de un año, dos versiones divergen.
• Para BricsCAD V26 se sigue compilando con .NET Framework 4.8. V26 no carga el add-in.
• El cálculo parte de BricsCAD Lite. Allí no funciona ningún add-in .NET.
• La DLL llegó por correo o por descarga y Windows la ha bloqueado. BricsCAD muestra entonces «Operation is not supported». La solución es marcar «Desbloquear» en las propiedades del archivo.
• El instalador solo conoce el bundle de AutoCAD. En BricsCAD, el add-in no se carga entonces automáticamente.

Fuentes: Bricsys Developer Reference, «dotNET overview» y «Registry DemandLoad»; ayuda de Bricsys, «How to develop and run .NET plugins in BricsCAD V26»; Ebi F. Eilber, AutoCAD .NET API (libro técnico, publicación prevista para 2027); caso de estudio «Modernización de una aplicación vertical de AutoCAD para obra civil», casos de estudio de Cadida.