Well written. There are a few things I did a little bit differently.
For the post build step, I use the $(TargetPath) macro, which includes the path, filename, and extension, all in one macro.
copy $(TargetPath) ..\..\..\..\GameDownload\Outpost2\trunk\
Since you changed the output filename in the project settings, you can omit the destination filename, and just provide a destination folder. I didn't rename the project output filename so I included a destination filename to do the rename during the copy.
copy $(TargetPath) ..\..\..\..\GameDownload\Outpost2\trunk\ml4Hoo.dll
I didn't add Outpost2.exe as a project in my workspace/solution. Instead, I set Outpost2.exe as the startup executable for the DLL project. You get the same benefit of easily launching Outpost2.exe when you want to run or debug your level.
I added the Outpost2DLL and OP2Helper projects to my workspace/solution, and set the level DLL project to depend on them. Any changes to SDK projects would then cause the level to be rebuilt as well. That aspect is mostly helpful for people actually working on the SDK files, but still useful when an SDK update is downloaded. What's more widely beneficial is being able to easily open and browse SDK header files, since the projects are right there in the workspace/solution.
I suspect updating the project files for the API projects will make the toolset error go away. Checking inside Outpost2DLL.sln I see the following text:
Microsoft Visual Studio Solution File, Format Version 11.00
# Visual C++ Express 2010
Also interesting is inside of Outpost2DLL.vcxproj is the text:
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
It's the same thing for the OP2Helper project.
Standardizing on the latest version of Visual Studio makes the most sense to me. Particularly since it's a free download.
I'm pretty sure the toolset is tied in to what redistributable package is needed to run the code. If you do a static compile though, it won't depend on the external redistributable libraries, so it shouldn't matter. Maybe we should just set the example projects to statically link the CRT. I doubt the slight increase in size is much of a problem these days. Besides, the tools have gotten better at stripping out unneeded stuff.
You're quite likely right about not stepping through code properly in a release mode. When optimizations are turned on, certain parts of the code can be reordered, merged, or omitted, which complicates stepping through the source view. A debug compile should turn off optimizations, ensuring the assembly code more closely maps to the source code. I don't generally use the debugger to trace code, which is one reason why I haven't bothered with debug builds.
I think older versions of Visual Studio could setup the ReleaseMinSize settings automatically when you asked it to optimize for size. The name is a holdover from the Visual Studio 6 version of the project files. It might be better to just go with the default Release configuration name, and just change the settings to optimize for size over speed. We only ever really used one Release configuration, and it was to optimize for size.
Microsoft supplies a redistributable package for release builds. It doesn't provide a redistributable package for debug builds. Hence you're not supposed to redistribute the Microsoft debug libraries with your code. If your code dynamically links to those libraries, that's a problem for distribution.