Using VC Build Hook to Target Multiple AutoCAD Versions .

Using VC Build Hook to Target Multiple AutoCAD Versions

[Update: Visual Studio 2010 now includes a built in feature called native multi-targeting that replaces the need for VC Build Hook. Read this blog post to learn how to use VS 2010 to target older versions of Visual Studio.]

I created the VC Build Hook utility in order to make it possible to use the current Visual Studio IDE for building ObjectARX applications that target any version of AutoCAD. This is desirable because ObjectARX applications must be built by the Visual C/C++ build tools that correspond to the ObjectARX SDK version for the target AutoCAD version. VC Build Hook works by switching the executables path during a Visual Studio build and pointing the paths to the desired version of the Visual C/C++ build tools. In addition, VC Build Hook automatically fixes build tool command options to account for differences between VC versions so that build commands produced by one version of Visual Studio are correctly interpreted by another version of the build tools. Assuming you've already set up your projects as described here (note that you must have a working installation of the necessary version of Visual C/C++ build tools and runtime libraries), then you'll need to install the current version of VC Build Hook:

Download: VCBuildHookSetup.msi (290k)
Version 4.0.2.5 uploaded 2010-06-05 (supports VC 7.1, VC 8, and VC 9)

Once the VC Build Hook utility is installed, it's just a matter of setting the VC Build Hook extended properties for your projects to use the correct build tools. As of version 4.02, VC Build Hook also sets the INCLUDE and LIB system variables to the current settings for the selected version of VC, so there is no need to explicitly specify the correct paths in your project settings.

When VC Build Hook is started, Visual Studio solutions will have two new extended properties: LowPriorityBuild and BuildToolVersion.

The LowPriorityBuild property is only available for solutions and can be either 'Yes', 'No', or 'NotSet'. Currently, VC Build Hook makes all builds low priority unless this property is set to 'No'. A low priority build means that other tasks will receive more processor time during a build (at the expense of build time, of course). The BuildToolVersion property is available for solutions or projects, and may be set to 'VC7', 'VC8', 'VC9', or 'Default'. A setting of 'Default' for projects causes the solution property to be inherited. If the project and solution are both set to 'Default', then the build tool paths will not be affected and Visual Studio will use the default build tools.

When using Visual Studio 2005 or later IDE:

Disable parallel builds! The VC Build Hook utility does not work correctly if two simultaneous builds are using different settings, so you should disable this feature in Visual Studio global options. To do this, go to Tools->Options, open 'Projects and Solutions', select the 'Build and Run' tab, and change the 'maximum number of parallel project builds' to 1. In my experience, Visual Studio is more stable when parallel builds are disabled, so there is a benefit to disabling this feature that is unrelated to VC Build Hook.

When using the VC 7 build tools:

Disable the Manifest Tool. This is easy to do, but not obvious or well documented. Right-click on a project and select 'Tool Build Order...', then select 'All Configurations' in the configuration dropdown and dismiss the warning dialog, then uncheck the box beside 'Manifest Tool'. Using the IDE, you have to do this one project at a time.

In linker settings, on the 'Manifest File' tab, set 'Generate Manifest' to 'No'. This disables manifest file generation.

Disable error reporting. In C/C++ settings, on the 'Advanced' tab, set 'Error Reporting' to 'Default'. Do the same in linker settings, on the 'Advanced' tab.

Set 'Treat wchar_t as Built-in Type' to 'No' in the in the C/C++ project settings Language section.

Don't use Unicode response files. Change this in C/C++ settings on the 'General' tab by setting 'Use UNICODE Response Files' to 'No'. Do the same in linker settings, also on the 'General' tab. The VC Build Hook utility will automatically convert Unicode response files to ANSI files if they are being sent to a VC 7 build tool, so this step is not strictly required, however the build will be slightly less efficient if the files need to be converted.

If your project uses precompiled headers, there is one additional issue to deal with. Visual Studio 2005 removed support for the "Automatically Generate" (/YX) precompiled header option. This is not a problem when using the VC 8 or later build tools, but when using the VC 7 build tools, it can make the build process unbearably slow. Luckily it's not difficult to re-enable automatic use of precompiled headers when building with VC 7 build tools. To re-enable this feature in a project that is using the VC 7 build tools, you need to edit the 'Precompiled Header' tab of the C/C++ settings. First, make sure precompiled headers are disabled ('Create/Use Precompiled Header' should be set to 'Not Using Precompiled Headers'), then set the 'Precompiled Header File' to '$(IntDir)/$(TargetName).pch' for all configurations, then go to the 'Command Line' tab and add '/YXStdAfx.h' to the 'Additional options' field at the bottom. Voila! Precompiled headers should now work just as they did when building with the Visual Studio .NET 2003 IDE.

If your project was created by a later version of the ObjectARX wizard that does not create a .def file, you must add the following in one of your source files (I prefer acrxEntryPoint.cpp) in order to ensure that the necessary functions get exported:

#pragma comment(linker,"/EXPORT:_acrxEntryPoint")
#pragma comment(linker,"/EXPORT:_acrxGetApiVersion")

I need to stress again that these steps only work without error after you have implemented the practices discussed here.