Getting Started: .NET for Civil 3D

Episode 1 gave this one clause: if the work is Civil 3D plugins, you will want the .NET SDK, and the version matters. That deserves the rest of an episode.

The SDK

One download, from .NET's own site, per major version. Civil 3D itself decides which one a given release wants, not you, and that number has already moved once in this series, episode 1 named the year it happened. Multiple versions install side by side without conflict, which matters the moment you are supporting two Civil 3D releases in the same week.

The build

A C# plugin compiles with one command, run from inside its own project folder: dotnet build. That produces a DLL. Add -c Release when the DLL is actually leaving your machine, for testing on someone else's; on your own, the plain command is enough.

What the plugin borrows instead of carries

A Civil 3D plugin references Civil 3D's own assemblies to compile, the same ones the running application already has loaded. Those references get marked so the build tool knows not to copy them into the output. Skip that step and the plugin still compiles, but it now carries its own copy of files a different Civil 3D version will disagree with, and it stops loading anywhere but your machine.

Getting it running

The compiled DLL loads from inside Civil 3D itself, with a command typed at Civil 3D's own prompt, not from Windows. There is no installer step past that. The one piece of friction: once Civil 3D has the DLL loaded, the file is locked, so a rebuild usually means closing Civil 3D first. That loop is slower than it sounds, which is exactly why a change gets tried on a real drawing before it gets called done, not after.

There is no automated test suite waiting for you here either. That is not an oversight.

Be Better - build it, then load it, then see it work.