VisualStudio vs SDK requirement

Sep 4, 2014 at 9:42 AM
I'm currently looking into targetting the VS80 toolset from VS2010 (for native code), because operations would like to drop support for VS2005 on their deployed workstations (which I can understand). However for a couple of reasons (Legacy systems, ...) the code base can not be ported to the new VS2010 compiler (at least not yet...). (next step would be VS2013)

I managed to add the vs80 toolset myself (I didn't knew this wonderfull daffodil yet).
But was hoping it would be possible to remove the need of a VS2005-install.
Instead of this I would prefer to modify Microsoft.Cpp.Win32.v80.props
to refer to compiler/linker/platformSDK folder etc. which was deployed through xcopy or by intallation of the "Windows SDK"

Would this be possible? Any possible issues?
Sep 4, 2014 at 4:28 PM
Edited Sep 4, 2014 at 4:28 PM
The purpose of a platform toolset is to use the build tools from that toolset, so yes, they must be installed. Since the build tools are dependent on CRT/MFC SDK files specific for that version of the tools, those specific SDK files must also be installed. Changing .props files to point to a newer platform SDK is no different than just selecting a newer platform toolset, and it does not resolve the dependencies on CRT/MFC SDK files. You can of course update your code to use the VS 2010 toolset, but that's the only practical way to eliminate the need for the VS 2005 build tools.
Sep 4, 2014 at 10:34 PM
Maybe I threw into much info...

I understand I still need all the CRT/MFC and other platform headers,libs,compiler etc...

I sure need the VS2005 build tools, currently they are on the system because VS2005 is installed.
I was hoping I can target the vs80 toolset by using a build/develop-machine with:
-only VS2010 and an older Windows Platform SDK installed (which also contains all build tools of VS2005), but not the VS2005 IDE itself.
-or even better: only VS2010 installed and an xcopy version of CRT/MFC-headers and libs/compiler/linker/... (and thus have a 'portable'-like set of the VS2005 buildtools, in the end we just need to call cl.exe and link.exe with correct parameters and some envVars set... Correct?)
Sep 5, 2014 at 3:31 AM
The VS 2005 build tools are only available as part of VS 2005 proper. I'm sure it would be possible to separate them into an xcopy-able toolchain merged with the older platform SDK, but I doubt this would pass legal muster. In any case, it would be a lot of work in exchange for relatively little savings over just deploying the full VS 2005 and using Daffodil.
Sep 5, 2014 at 7:16 AM
Thanks for your feedback.
I'm gonna ask operations to still support VS2005, and recommend developpers to use VS2010(/daffodil), and put some more effort in converting to the VS2010 crt/compiler