VC Build Hook utility for Visual Studio 2008

The new Visual Studio 2008 has been released, and to celebrate, I’ve updated VC Build Hook. The updated utility allows you to use the new IDE while still building with older versions of the build tools.

Why is this necessary? If you build your AutoCAD 2007/2008 ObjectARX application with the Visual C/C++ 9.0 tools, AutoCAD will display a warning message about an incompatible module when you try to load it. You can use VC Build Hook to target all previous AutoCAD versions from a single Visual Studio 2008 solution (if you have the correct version of Visual C/C++ installed alongside Visual Studio 2008).

In my testing so far, existing Visual Studio 2005 projects build without problems in Visual Studio 2008 when VC Build Hook is installed and the new ‘BuildToolVersion’ property is set to the correct version.

OpenDCL 4.0 Debuts

OpenDCL 4.0 has finally been released. If you’re not familiar with OpenDCL, check it out at www.opendcl.com, or on SourceForge at sourceforge.net/projects/opendcl.

OpenDCL, based on the original commercial ObjectDCL software by Chad Wanless, is a modern replacement for the old DCL dialog control language in AutoCAD. The current OpenDCL Runtime supports AutoCAD 2002 through 2008 (except AutoCAD 2008 x64). It is designed to give AutoCAD end users and AutoLISP application developers a simple yet powerful way to design and use rich user interfaces in their applications.

The goal for version 4.0 was to get it stable and fix all the bugs, with minimal new feature development. OpenDCL 4.1 will add support for AutoCAD 2008 x64. After that we will start working on localized language versions, and adding new features.

OpenDCL is licensed under the GNU General Public License (GNU GPL) open source license, completely free to use, and source code is available on SourceForge.

Visual Studio Build Configuration Tip

I’ve received several emails recently from users of my VC Build Hook utility that mention switching the ‘UseVC7Paths’ setting on and off depending on the build configuration they are working on. If you are doing this, you need to change your project structure!

Build configurations in Visual Studio 6 and later are logically attached to the solution, not to an individual project as they were in older Visual Studio versions. What happens is that programmers find it easy to add a new build configuration to an existing ObjectARX wizard created project for targeting a new release of AutoCAD — unfortunately those configurations end up belonging to the entire solution instead of just one project. Since VC Build Hook cannot be set on a per-configuration basis, they end up having to change the project setting depending on which configuration they are building. That’s bad, very bad!

The correct way to handle this situation is to create new projects, not new build configurations. Yes, it’s a bit more work, and it would be nice if Microsoft added an easy way to clone a project, but them’s the breaks. Targeting different AutoCAD releases requires project-level changes, so you must create a new project instead of trying to get by with a new build configuration. You can and should share source code files between the projects, however.

When I create a new multi-target solution that e.g. targets AutoCAD 2000 – AutoCAD 2008, I structure the project files on my hard drive like this:

Solution (.sln file)
ARXProject (ARX module source files)
 +ARXProject.15 (.vcproj file)
 +ARXProject.16 (.vcproj file)
 +ARXProject.17 (.vcproj file)
DBXProject (DBX module source files)
 +DBXProject.15 (.vcproj file)
 +DBXProject.16 (.vcproj file)
 +DBXProject.17 (.vcproj file)

When starting a new project, I first use the wizard to create a default project structure and source code files for the current AutoCAD release. Once I’ve got that set up the way I want (including moving the project file into a subdirectory and modifying the source file paths appropriately, as well as setting the _ACADTARGET preprocessor macro), I clone projects by copying the .vcproj files and editing the copies in a text editor to give them a new GUID, then recreate my solution’s project structure from scratch by dragging and dropping the project files back into the solution and editing them as necessary.

If you need to target multiple AutoCAD releases from a single project, invest the time to set your solution up this way (and follow the other advice on my ARX tips page!), otherwise you will find yourself constantly fighting the system.

Introducing OpenDCL for AutoCAD

AutoLISP programmers may remember a product named ObjectDCL, by 3rd Day Software. ObjectDCL was released as open source in the summer of 2006 by developer Chad Wanless due to his inability to continue supporting the software because of “health reasons”. At the time, many users of ObjectDCL hoped that someone would update the code to work in AutoCAD 2007. Programmer David Robison did some work to get AutoCAD 2007 supported, but the project has been languishing, almost to the point of extinction.

After being asked by several ObjectDCL users whether I could help, I decided a few weeks ago to contribute to the community by getting the original C++ code updated to support AutoCAD 2007. As I am wont to do, I’ve ended up re-architecting much of the code in the process.

The results of my work are available now at the new OpenDCL project on SourceForge. The new 4.0 release is still in the alpha testing phase. If you program in AutoLISP and want to create rich user interfaces for your applications, check it out!

My ManuSoft manifest manifesto

With the advent of Visual Studio 2005 and automatically generated manifest files, the topic of when and how to use manifest files comes up occasionally. Since a default ObjectARX wizard generated project in Visual Studio 2005 generates an embedded manifest by default, most people don’t even think about it. Of course that was the whole idea — the manifest would ensure that the correct dependent DLLs get loaded, and voila, no *need* to think about it. One of my programming axioms applies in this case: TANSTAAFL.

The problem is that ObjectARX applications are not in charge. AutoCAD is in charge, and it will decide which VC runtime and MFC runtime DLLs to load. If your ObjectARX application loads a different VC or MFC runtime than the ones AutoCAD is using, you’ll encounter big problems. I’ve always advised disabling the manifest completely (see my ObjectARX Tips page) to avoid such a possibility. Unfortunately, there’s a catch.

The problem is that linking to the ATL80.DLL file isn’t possible by just disabling the manifest and doing nothing more. ATL is now a side-by-side (SxS) assembly, and it no longer lives on the Windows support path, so a standard un-manifested DLL won’t be able to find it. The preferred solution is to link statically to ATL (see Configuration -> General -> ‘Use of ATL’ in VS 2005 project properties) and avoid the problem altogether. If you only have one module that uses ATL, this is always the best solution.

The less desirable solution is to add a *manually-created* manifest that specifies the desired ATL SxS assembly, but ignores the VC and MFC runtime DLLs. You’ll still need to decide whether to make ATL shared or private, and in either case you *must* distribute ATL with your application to ensure that it is available when your application is deployed. You can cheat, and let VS generate your manifest file (instruct it to *not* embed the file), then just edit the resulting .manifest file to remove references to the VC and MFC assemblies. For example, here’s one that I generated (you’ll need to generate your own to ensure that the manifest matches the version you are redistributing):

<?xml version=”1.0″ encoding=”UTF-8″ standalone=”yes”?>
<assembly xmlns=”urn:schemas-microsoft-com:asm.v1″ manifestversion=”1.0″>
<dependency>
<dependentassembly>
<assemblyidentity type=”win32″ name=”Microsoft.VC80.ATL” version=”8.0.50727.762″ processorarchitecture=”x86″ publickeytoken=”1fc8b3b9a1e18e3b”>
</assemblyidentity>
</dependentassembly>
</dependency>
</assembly>

In my work, I’ve had very little need for manifests. The VC optimizer is able to strip the unused portions of statically linked ATL out of your code, leaving a much smaller footprint than the entire assembly would require. This eliminates the need to redistribute ATL with your application, thus reducing the overall potential for deployment issues. Nevertheless, there are exceptions to every rule, and your mileage may vary.