Skip to content
Ewen edited this page Oct 27, 2015 · 2 revisions

##Why Even Is This? I (CADbloke) write AutoCAD plugins, amongst other things. They also need to run in IntelliCAD, NanoCAD, BricsCAD, Graebert ARES, WalmartCAD or whatever else pops up, as well as a lot of versions of AutoCAD dating back to 2007 as well as AutoCAD OEM and RealDwg. Don't forget Teigha. The build settings, .NET framework version, x86/64 and project references are quite different between the platforms but they can (generally) share most of source code. Write once, build many.

I tried other approaches but they were horribly complicated and Nuget broke most of them. Ok, I broke them with Nuget. An online colleague came up with a better solution but it still wasn't simple enough for me. This Solution (see what I did there?) means you can separate the build and code concerns. I also like being able to step through the debugger and see what the code is doing in a specific build. I also like to see what #if compiler directives do to my code. This will never be simple but I wanted something that wasn't a rocket science in itself.

Here are the requirements straight from my Trello board before I wrote this ...
###Code Linker Requirements One project that manages the common Source Code. It needs to be managed by a Visual Studio project because files are included in different ways, eg. XAML.CS files depend on their XAML file etc. This needs to be managed in one place - one version of the truth.

  • The canonical project actually builds and is the primary development project, usually the current version of AutoCAD for me. It is where you will spend most of your time. The destination projects are for build configs and tweakage to make it work for the target platform(s).
  • Adding a build config and debugging should be as easy as adding another project to the build collection with minimal preparation. It should know all about the common Source Code. It can have its own code too that overrides the canonical source with specific code for this build.
  • The primary development project knows nothing of any recycles of it and is never affected by them. NEVER.
  • Source Code should be displayed in the build project.
  • See the code in the context of the platform I am building it for.
  • See #If compiler directives and what code they affect.
  • Debugging should step through the code in the right context.
  • Source code should be synced between projects without user intervention, automatically so it is not overlooked. Set and forget.
  • Easy to maintain. If you accidentally add a code file to the wrong project, just move it to the right place in the Solution Explorer and it all heals itself.
  • Unloading build projects should not affect anything - they should still update and all that. Nothing should break (note: refactoring could break if some code is considered "dead").
  • I keep all the Build projects in a separate folder out of the way to avoid clutter. You can load and unload them all at once.
  • Build projects should also be able to have their own code that compiles as well as the canonical code, if required. This is for Overrides etc.
  • I want to leave some stuff out or just cherry-pick some things.
  • it should easily bolt on top of something that already exists with breaking it.
  • I looked into Shared Projects but they
  • don't have the source code right in front of you,
  • don't do 3rd party libraries and their intellisense etc.. ok, if they do then I got it wrong - tell me.
  • Libraries are good but if you compile them for one platform then that DLL is useless for the other platforms.

Clone this wiki locally