AutoCAD Development; Moving from AutoLisp to C# .NET Environment

[erdem_babayigit]

I am hoping this is the right place to post this sort of Question and I would be very grateful for any tips or hints in the right direction.

I’ve recently started working for a company that has been creating and using Plugins/Extensions for AutoCAD MAP 3D for almost 30 years now, they are involved in the cartography business and are a service company for the Oil and Gas Industry. It was all done by one old Mr. who has now gone into retirement with all of his knowledge left in cryptic autolisp notes, especially in the acad.lsp file. The wish of the company is to move from the AutoLisp environment into the .NET C# environment for better error handling as well as better extendibility in the future and distribution to other systems. I am trying to build an overview/understanding of the whole software that sits on AutoCAD, i.e which lisp files call which lisp files, for the fist part.

By the way I am a complete beginner to this whole world of AutoCAD/AutoLisp but find it extremely interesting.

The plan would be to start from the acad.lsp file and translate each of the lisp scripts into C# script and eventually build .dll files that AutoCAD can load, into the one drawing that we are always using.

My question is, will I always have to keep the acad.lsp file for initiation? I’m guessing probably yes? Like checking which version of AutoCAD I am using?

Perhaps, instead I could keep moving the routines and load instructions(for .lsp routines) slowly from the acad.lsp into a general autocad.dll file? Where for example try catch blocks would be easier to integrate, once all of the acad.lsp file has been “slimmed down” I guess I could move on with migrating the individual lisp scripts into dll files as well?

How would one proceed in this situation? Any suggestions or further questions are very welcome, thanks in advance and wishing everyone a beautiful day wherever they are!

[norman.yuan]

How to transit your LISP-based AutoCAD customization to .NET API-based customization would mostly depend on how much man-power resources available: you need someone who knows vey well about the business functions/features the existing LISP routines do - not necessarily knowing the code in detail, rather, knowing what they do and how critical these features are to the business operation; then you need someone who know AutoCAD programming well (not only AutoCAD .NET API, but also .NET framework programming in general, such as UI development, data access/management...).

I did similar things with different offices a few times (I worked in Oil & Gas surveying side for about 20 years), and it usually were staged works: first, analysing the existing customization features, be it LISP, or VBA, or even pure scrip macros; then analysing the business operation workflow (the CAD operation) to identify the mission-critical features; then decide the staged transitions. 

With LISP-heavily customized CAD environments of many offices, usually, there is lack of data-driven information foundation/infrastructure, due to the inherited historical baggage, while with modern IT technology, it is essential to build CAD applications on top of sound data-driven foundation. 

So, you could get help from empierced CAD users in the company about the existing features and how important they are in the current CAD operation (again, knowing the code of the LISP routines probably is not that important), but you, or whoever does the transition, need to know more than AutoCAD .NET API. Keep it in mind, with newer technologies, your new .NET API based apps could even result in business workflow changes to make the work more efficient, more quality-improved (that is, you do not just repeat the same features with .NET API as the LISP ones). Therefore, if you are not up to the task yet, or not have someone already, it would be better to seek someone to get things started correctly and/or to get some portion of the task done to lay out a good foundation. When your internal resources (or yourself) gets growingly comfortable, take over and continue the work.

BTW, if you have already gotten started with AutoCAD .NET API and really want to tackle the task on your own, you may want to post most your questions here, unless it is AutoCAD Map specific.

Hope this helps a bit in concept, not in technical details.

[erdem_babayigit]

Dear Norman, thanks for your quick and experienced answer, and from what your are explaining it does indeed seem like a huge undertaking which makes it even more interesting. I guess you are right, data access is currently a challenge, at the moment it is done in Access which should be translated to an SQL based system in the future. I shall post more specific questions, like how to load .lsp routines from .dll files into the .NET Forum like you suggested, wishing you a good day!

[norman.yuan]

Unless your company is fairly small in size, and/or data access to the CAD operation's efficiency/quality is not very critical at current stage, designing proper data access structure/tier could be crucial to the transition to .NET API for CAD applications. You mentioned SQL Server (or any other types of database server). With current .NET technology, especially when the next AutoCAD release will move beyond current .NET framework to adopt .NET Core (.NET 8), data accessing via some sort of services would be standard approach. Therefore, it would be better start the .NET transition from the data tier design in mind and not put it off to the future. Or you only limit your transit to tic for tat type of LISP feature replacement, some kind of temporary fixes.

[fieldguy]

There is quite a bit of information in Help.  Autolisp, using ACAD.lsp and / or ACADDOC.lsp are documented there.

[erdem_babayigit]

Thank you