I was hoping that Microsoft would address the need to target earlier versions of Visual Studio within the Visual Studio 2010 IDE, but since they decided to punt, I tackled the problem myself. I’ve released my solution as an open source project named Daffodil for Visual Studio.
With Daffodil installed on your system along with earlier versions of Visual Studio, you can use the new native multi-targeting feature in Visual Studio 2010 to target those earlier versions. This makes it possible to use Visual Studio 2010 for building ObjectARX projects, for example. Daffodil performs essentially the same function that my VC Build Hook utility did in Visual Studio 2008 and 2005.
19 thoughts on “Visual Studio 2010 Native Multi-Targeting”
Fantastic! Thank you sir!
Does this mean you’re now using VS2010 primarily for all your development needs, including older versions of AutoCAD that require, for example, VS2005? Warm regards from Los Angeles,
I still use VS 2008 primarily. I’m in the process of moving a few projects to VS 2010, but there are still some problems unrelated to multi-targeting that I need to find reliable solutions for. One of the projects that I have already ported to VS 2010 targets AutoCAD versions back to AutoCAD 2000.
Super useful – thanks for providing this!
Useful tip in conjunction with Native Multi-Targeting – you can change the directory that is examined for platform toolset definitions, by setting the “MSBuildExtensionsPath32” environment variable. If you do so, you should also copy the contents of the MSBuild directory (i.e. C:Program FilesMSBuild or the equivalent) to whatever the environment variable is set to.
This might be useful if you’re checking in toolset definitions into source control.
Thank you!! Works great.
Do you have all the previous versions of VS (going back to 6.0) installed on a Win7 machine? If so, how? If not, what OS are you using?
Best Regards and Thanks!
Yes, I do have every version from VS 6.0 to VS 2010 installed on Windows 7 64-bit. The build tools for all of them work fine, however the VS .NET (VC 7.0) IDE does not work (it starts then immediately exits). I think I may have “installed” VS .NET by copying files and registry keys from a working installation on a Windows XP 32-bit VM.
Thank you a lot for this! What about “Daffodil for Visual Studio 2012” (since Daffodil just doesn’t seem to work for it – at least it doesn’t for me)?
Before dragging the folder “Platforms” into the one called “v110” in “C:Program Files (x86)MSBuildMicrosoft.Cppv4.0” it didn’t even show the toolsets in project settings. After doing so, Visual Studio 2012 moans ‘MSB4057: The target “Build” does not exist in the project.’.
I had to uninstall VS 2012 because it broke my VS 2010 installation, so I’m afraid I can’t help you.
Greg, I’ve tested the shipping VS 2012 in a virtual machine and it displays the Daffodil platform toolsets in a new project after a clean install. I don’t have any older versions of VS on the virtual machine so I can’t test beyond that, but at least the platform toolsets are displaying as expected.
When I upgraded to Windows 10 last week I was pleased to find that the existing installation of VS6 did seem to work. That’s to say it did build . However on trying to debug something I found that although my application would run in the VC6 debugger, if I had a breakpoint it would break but not then be able to resume, or single step; all of these resulting in an “Access Violation” error (possibly followed by “Privileged Instruction”).
I was very interested to find Daffodil, which I have installed and has allowed me to build my project using VC2013 with the VS6 tools. However, on attempting to run the project in the debugger I am being told “binary was not built with debug information”.
I wonder if anyone else has had this working ? Or is there something incompatible between VS2013’s debugger implementation and VC6’s debug information ? Or have I just missed some configuration somewhere ? Or has Daffodil missed setting something ?
 It was on Win 7, which worked perfectly except for an issue where a process being debugged couldn’t properly be stopped by the debugger (eg using shift-F5), leaving an orphaned process if that was tried, and needed to be stopped using Process Explorer.
Richard did you see this?