ACadSharp reads and writes DXF, and writes DWG back out

A format matrix that tells you where the edges are

The most useful thing in the README is the compatibility table, and it should be read before anything else. It maps nine DWG and DXF format versions against four capabilities: DxfReader, DxfWriter, DwgReader and DwgWriter.

The shape of the table is the story. DXF reading works from AC1009 upward, the oldest version listed, and DXF writing starts at AC1012. DWG reading and writing both start at AC1014, so DWG support covers every version from AC1014 through AC1032 with no gaps. The exception is AC1021, the AutoCAD 2007 era version, which has a DWG reader and a DXF reader and writer but no DWG writer.

So the library reads and writes DXF broadly, reads DWG broadly, and writes DWG for most versions but not for the oldest supported DWG and not for AC1021. That is a specific, checkable claim, and a team that knows which AutoCAD version its customers export from can answer the question immediately. A team that does not know will find out from a user's file.

The version identifiers themselves are the ACAD codes, AC1009 being the original release and AC1032 the most recent listed, and the samples directory in the repository carries a matching set of test files: ASCII and binary DXF for AC1009, AC1015, AC1018, AC1021, AC1024 and AC1027, and DWG files for AC1014, AC1015, AC1018, AC1021, AC1024 and AC1027. That pairing of a test file per version per format is a good sign about how the compatibility claims are maintained.

What the library does with the drawing itself

The feature list is short, and each item is a real editing operation rather than a formatting nicety.

The first capability is reading or creating CAD files using .NET, and also extracting or modifying existing content in the files. The second is the granular one: extracting or modifying the geometric information from the different entities in the model, with a link to the Autodesk object reference for what an entity is. The third is control over the table elements like Blocks, Layers and Styles, allowing you to read, create or modify the different tables.

That third item is what separates a CAD library from a file converter. A converter moves a file; a library lets a program open a drawing, look at the layer table, add a block definition, attach it to an entity, and write the result out. That is what you need for a checker, a redaction tool, a data extractor or a batch processor, and it is why the library is described in terms of reading and writing rather than conversion.

The project also separates the core library from export formats. For other format export like svg, image, json or pdf, the README points to ACadSharp.Formats, a separate repository. That is a sensible split, since those conversions are a different problem from the CAD data model, and it means the core library stays focused on DXF and DWG.

For a team evaluating this, the practical question is which of those two pieces they need. If the requirement is SVG or PDF output, the answer is the other repository, and ACadSharp may not be involved at all.

Reading a DWG takes three lines and a notification callback

The code example in the README is deliberately small, and it shows the shape of the API rather than the whole of it:

public static void Main()
{
	string path = "sample.dwg";
	CadDocument doc = DwgReader.Read(path, onNotification);
}

// Process a notification from the reader
private static void onNotification(object sender, NotificationEventArgs e)
{
	Console.WriteLine(e.Message);
}

The entry point is DwgReader.Read, taking a path and a notification handler, and it returns a CadDocument. The document object is the centre of the model, and everything else, the entities, the tables, the geometry, hangs off it.

The notification callback is the part worth pausing on. A CAD file is not a simple container. A DWG from a real drawing contains objects that other applications have written in ways the library may not fully understand, and the reader is given a channel to report what it finds as it goes. A handler that writes the message to the console is the smallest possible example, and it is also the shape of the handler you would want in production, writing to a log rather than to standard output.

That mechanism is what makes the format support claim testable. When a reader hits something it can parse but not perfectly understand, it says so, and the caller decides whether to continue. The alternative, silently dropping content, would be much harder to detect in a batch conversion pipeline.

The repository has a more extensive set of examples at src/ACadSharp.Examples, which the README links to, so the single snippet above is a starting point rather than the full API.

Building requires the submodules, and the samples show the range

The build section is three lines, and the first one matters:

git submodule update --init --recursive

That command clones the submodules necessary to build the project, and the repository has a .gitmodules file at the top level. A clone without it produces a tree that compiles or fails in confusing ways, which is the usual failure mode for a project with submodules and a README that mentions it once.

The samples directory is where the library's range is visible. Alongside the CAD test files, there are directories for aec_objects, dynamic-blocks, geolocation and patterns, and loose files including an image and a PDF definition. A dynamic blocks sample in particular suggests support for the block table features that make real drawings complicated, and a geolocation sample suggests the library handles the coordinate system metadata that a drawing carries alongside its geometry.

The top-level layout also has a reference directory and a docs directory, and the README points to the API documentation hosted at domcr.github.io/ACadSharp for specific information about the library. The documentation is therefore the primary reference, with the README acting as an index of features, versions and samples.

The build and test badge in the header points at a workflow named csharp.yml, and the coverage badge tracks the master branch through Coveralls, so the project reports on its own test coverage rather than leaving it unstated.

An active .NET library with a 3.x line and a lot of patch releases

The release history is dense, and it is a good sign for a library that has to track a format as complicated as DWG.

The recent versions are v3.8.0 on 2026-09-21, v3.7.16 on 2026-09-18 and v3.7.1 on 2026-08-18. The last push to the repository was on 2026-10-21, and the default branch is master. The version numbering tells you that the project is past the awkward early stage, and the volume of patch releases on the 3.7 line says that format edge cases are still turning up and being fixed.

That is characteristic of this kind of library. A CAD file format is a specification that implementations disagree about, and the disagreements only surface when a user opens a file produced by a different program or a different version. A library that keeps shipping 3.7.16 and 3.8.0 is a library whose users keep finding files that break it.

The licence is MIT, with a LICENSE file at the repository root, so there is no complication in embedding it in a commercial product. The package is published on NuGet under the name ACadSharp, and the header carries the version and download badges from that registry.

The topic list is worth a glance for the shape of the intended use: cad, dwg, dwg-files, dwg-reader, dwg-writer, dxf, dxf-files, dxf-reader, dxf-writer. The explicit reader and writer topics for both formats tell you this is a bidirectional library rather than a one-way reader, and that both directions are intended to be first class.

Where a .NET team should look before committing

Three limits deserve to be stated plainly.

The first is the DWG writing gap. The format table shows no DWG writer for AC1009, AC1012 or AC1021, and the DXF writer does not cover AC1009 either. If your users work in AutoCAD 2007 files, AC1021, you can read them and convert them to DXF, but you cannot write DWG back. That is a real constraint for a round-trip workflow, and it is documented, but it has to be discovered before it is discovered by a user.

The second is the dependency on the AutoCAD object model rather than on AutoCAD itself. This is a from-scratch implementation of the file formats, which is what makes it usable in a server or service context where no CAD application is installed. The trade is that anything the format permits but the library has not implemented is missing, and the notification callback is how you find out.

The third is scope beyond DXF and DWG. SVG, image, JSON and PDF export live in a separate project, so a requirement that spans both means working with two repositories rather than one.

The realistic use cases that fit well are batch conversion, geometry extraction into a data pipeline, modification of layers, blocks and styles in existing drawings, and generating DXF from scratch. A CAD viewer, a full editor or a parametric modelling tool is a different ambition, and nothing in the feature list suggests the library is heading there.

Editorial conclusion

ACadSharp suits a .NET team that has to read or generate DXF geometry, or to round-trip a DWG file, without a dependency on the AutoCAD SDK or on a native library, and it is a good fit for a converter or a reporting tool built on the samples directory. It is the wrong tool for the newest DWG versions, since the format table shows DWG writing starting at AC1014 and no DWG writing at all for AC1009, AC1012 or AC1021, and it is the wrong tool when you need SVG, image, JSON or PDF output, because that is a separate project. Before you adopt it, check the compatibility table against the file versions your users actually have, run git submodule update --init --recursive before building, and read the API documentation linked from the project rather than relying on the single example the README shows.

Frequently asked questions

Official sources

1. DomCR/ACadSharp on GitHub
2. Issues
3. License: MIT
4. README
5. Releases