LINQ and the AutoCAD .NET API (Final part)

Welcome to the final part of LINQ and the AutoCAD .NET API. In this post I want to briefly summarize the blog series.


Here are the links to the 10 posts:

Part 1 – Motivation
Part 2 – Staying within a transaction’s scope
Part 3 – From a LayerTable to SymbolTables
Part 4 – From tables to dictionaries
Part 5 – ModelSpace | PaperSpace | CurrentSpace
Part 6 – Write operations
Part 7 – Creating objects I (SymbolTables)
Part 8 – Creating objects II (DBDictionaries)
Part 9 – Brushing up the API
Part 10 – Optimizations

Code on GitHub

With the ideas and code from the posts I created a project on GitHub called Linq2Acad. You can find the full source code and some examples there.


The library is still under development. Working with Blocks and Entities works best at the moment. Access to other tables and dictionaries is implemented, but basically untested. Tests and features will be added little by little. I also want to invite you to contribute to the project, by contributing code, ideas or whatever could be helpful to make Linq2Acad a helpful library.


6 thoughts on “LINQ and the AutoCAD .NET API (Final part)

    • Hello Alexsandro,

      thanks for your comment.

      If you want to get all entities from all layouts (model space and all paper space layouts), you can try this code example (provided you use the latest Linq2Acad code).

      Keep in mind that the library is still under development, so please use it with caution.


  1. Hello Mr Wolfgang

    I done some research: perhaps the following dynamic types can be incorporated into your library – they do not require transaction wrappers. but the catch is that you can’t use intellisense. or perhaps they can be wrapped to allow for intellisense to somehow be incorporated?

    These make for some very interesting reading:

    Have you heard of this new functionality? Do you think it will be useful for such a common library?



    • Hi Ben,

      thank you very much for your research, the links are very helpful. I’ve read some of them before. You already pointed out the drawback of this approach:

      1) Intellisense is not available, since type information is not checked at compile time
      2) DLR based code is evaluated only at run type, so it is slower than statically typed .NET code

      In general, I don’t see a drawback using a transaction wrapper. Quite the contrary, it simplifies AutoCAD code and the main advantage is, that you can use intellisense, which is – in my point of view – indispensable for a library.

      Thanks for your valuable comments Ben!


  2. Pingback: Customization for Autocad, Civil 3D, and 3ds Max | PRO-CAD.NET

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s