可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

My teacher is horsed to use Visual Studio 2010 by the school, because they don't want to bother installing anything new. I've been using Visual Studio 2015 and am really liking it. However, when she tries to run any of the code, it produces a bunch of errors. I tried a solution for making 2013/2012 projects compatible with 2010 by editing the solution file, but it still produces errors. Is there a solution?

Here is the console output when I try to run the source file in Visual Studio 2010:

1>------ Build started: Project: typingSalon, Configuration: Debug Win32 ------
1>Build started 4/8/2015 8:19:30 AM.
1>Project file contains ToolsVersion="14.0". This toolset is unknown or missing. You may be able to resolve this by installing the appropriate .NET Framework for this toolset. Treating the project as if it had ToolsVersion="4.0".
1>C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets(518,5): error MSB8008: Specified platform toolset (v140) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected.
1>
1>Build FAILED.
1>
1>Time Elapsed 00:00:00.05
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========

回答1:

The problem is that the project file references the v140 C++ toolset, which basically means use the C++ compiler from Visual Studio 2015. This compiler is not installed, which causes your error message.

From the top of my head, there are two ways for you to overcome your situation:

Install Visual Studio 2010 on your computer. Then, from within 2015, select the 2010 platform toolset in the project settings. Your project will then always be compiled with 2010, but you have the advantage to not accidentally use C++ features that 2010 does not have.
Don't install Visual Studio 2010 on your computer, but use the second computer (with just 2010 installed) to create a second build configuration, which has the platform toolset set to Visual Studio 2010 (v100). Use the appropriate configuration depending on which Visual Studio you use.

Both of these solutions basically mean you do not use the improved C++ capabilities of Visual Studio 2015 over Visual Studio 2010, which is somewhat unfortunate.

回答2:

Updated for Visual Studio 2017 and Visual Studio 2019

You can make this work actually, with just a few changes, if you only use the Visual Studio IDE itself (not MSBuild on the command line) to compile, with more or less full functionality on both platforms.

Unfortunately the rules for C++ projects are different than C#/.NET, and require some manual intervention, unlike the C# projects fairly automatic for round tripping after project "upgrade". These changes will require editing the project files manually.

Later versions of Visual Studio will override the tools version when the build is run through the IDE. Simply setting the ToolsVersion to 4.0, to satisfy Visual Studio 2010 and then fixing the PlatformToolset in a common property group to get the correct default action in the Visual Studio 2015 IDE will probably do it.

The reason for setting PlatformToolset is so that the defaults for correctly when changing build properties, like when you go to Debug or Release settings in the IDE and choose <inherit from parent or project defaults> you will get the 2015 version by default and not 2010.

Steps for Visual Studio 2010, Visual Studio 2015, Visual Studio 2017, and Visual Studio 2019 cohabitation on same project file for C++:

ToolsVersion attribute to 4.0
Add common default value of PlatformToolset to v140 for Visual Studio 2015
Add common default value of PlatformToolset to v141 for Visual Studio 2017
Add common default value of PlatformToolset to v142 for Visual Studio 2019
Save file and reload project

1. Tools version to 4.0:

<?xml version="1.0" encoding="utf-8"?>
  <Project DefaultTargets="Build" ToolsVersion="14.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <ItemGroup Label="ProjectConfigurations">
      <ProjectConfiguration Include="Debug|Win32">
        <Configuration>Debug</Configuration>
        <Platform>Win32</Platform>
      ...

By changing only 14.0 to 4.0 in Project tag for ToolsVersion it becomes

<?xml version="1.0" encoding="utf-8"?>
  <Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <ItemGroup Label="ProjectConfigurations">
      <ProjectConfiguration Include="Debug|Win32">
        <Configuration>Debug</Configuration>
        <Platform>Win32</Platform>
      ...

2. Add common default value of PlatformToolset to v140 recognized only by Visual Studio 2015:

  <PropertyGroup Label="Globals">
    <ProjectGuid>{12345678-9876-ABCD-DCCA-765FE987AA1F}</ProjectGuid>
    <Keyword>Win32Proj</Keyword>
    <RootNamespace>myProject</RootNamespace>
    <TargetPlatformVersion>8.1</TargetPlatformVersion>
  </PropertyGroup>
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />

By adding only the new PlatformToolset line to the bottom of the PropertyGroup it becomes:

  <PropertyGroup Label="Globals">
    <ProjectGuid>{12345678-9876-ABCD-DCCA-765FE987AA1F}</ProjectGuid>
    <Keyword>Win32Proj</Keyword>
    <RootNamespace>myProject</RootNamespace>
    <TargetPlatformVersion>8.1</TargetPlatformVersion>
    <PlatformToolset Condition="'$(VisualStudioVersion)' == '14.0'">v140</PlatformToolset>
    <PlatformToolset Condition="'$(VisualStudioVersion)' == '15.0'">v141</PlatformToolset>
    <PlatformToolset Condition="'$(VisualStudioVersion)' == '16.0'">v142</PlatformToolset>
  </PropertyGroup>
  <Import Project="$(VCTargetsPath)\Microsoft.Cpp.Default.props" />

To also load in Visual Studio 2017, a line with toolset v141 is additional required as shown above to continue to seamlessly cross load projects between all three.

In Visual Studio 2019, a line with toolset v142 is additional required as shown above to continue to seamlessly cross load projects between all four.

回答3:

Write a .lua script for premake5 - https://premake.github.io/ How to can be found here: https://github.com/premake/premake-core/wiki

And then simply create project for specific visual studio using visual studio version from command line - for example like this:

premake5 --file=myproject.lua vs2015
premake5 --file=myproject.lua vs2010

Typical script looks like this:

-- If visual studio version is not specified from command line - use vs2013
if _ACTION == nil then
    _ACTION = "vs2013"
end

buildvsver = _ACTION

--
-- I typically use "_vs2013" suffix so autogenerated projects won't conflict with each other.
--
solution ( "MyOwnSolution" .. "_" .. buildvsver)
    platforms {  "x32", "x64" }
    configurations { "Debug", "Release" }
    objdir (  "obj/" .. buildvsver)

project ("MyOwnProject" .. "_" .. buildvsver)
    kind     "SharedLib"                -- http://industriousone.com/kind: ConsoleApp | SharedLib | StaticLib | WindowedApp
    platforms {  "x32", "x64" }
    language "C++"
    targetdir ("bin/%{cfg.buildcfg}_%{cfg.platform}_" .. buildvsver)

    -- If you use managed code
    flags { "Managed" }

    flags { "MFC" }
    flags { "Unicode" }

    -- Add dependency on another project:
    -- dependson { "OtherProject" .. "_" .. buildvsver }

    -- If you use managed code - you can specify .net framework version.
    framework "4.0"

    files {
        "mysource1.cpp",
        "myheader1.h",
        "myheader2.cpp",
    }

    links {
        -- Some of dependent libraries
        "dbghelp.lib",
        "delayimp.lib"
    }

    -- Force to delay load some .dll
    -- Custom / advanced flags.
    linkoptions { "/delayload:dbghelp.dll " }
    linkoptions { "/delayload:mscoree.dll " }

    configuration "*"
        -- I typically use 'ReleaseRuntime' - that's debug = release configuration. 
        -- No special .dll's are needed even for debug version of your application
        flags { "NoRuntimeChecks", "ReleaseRuntime" }

        -- Debug symbols.
        flags { "Symbols" }

        -- Executable name without _vs2013 prefix.
        targetname ( "MyOwnProject" )

        -- C++ defines for both - release and debug configurations.
        defines { "NDEBUG", "_CRT_SECURE_NO_WARNINGS", "WIN32", "WINVER=0x0600", "_WIN32_WINNT=0x0600" }

        -- debugcommand "customExeToLaunch.exe"

        -- Custom post build steps.
        -- postbuildcommands { "call $(ProjectDir)projexport.bat $(PlatformName) $(TargetPath)" }

    configuration "Release"
        -- Only difference from debug - is optimizations for speed.
        optimize "Speed"

        -- Can debug in release.

        --
        -- Enhance Optimized Debugging
        -- https://randomascii.wordpress.com/2013/09/11/debugging-optimized-codenew-in-visual-studio-2012/
        -- https://msdn.microsoft.com/en-us/library/dn785163.aspx
        --
        buildoptions { "/Zo" }


project ("TestMyProject" .. "_" .. buildvsver)
    platforms {  "x32", "x64" }
    kind     "ConsoleApp"
    language "C#"
    targetdir ("bin/%{cfg.buildcfg}_%{cfg.platform}_" .. buildvsver)
    framework "4.0"

    links {
        "System",
        "System.Core",
        "System.Data",
        "System.Drawing",
        "System.Windows.Forms",
        "System.Xml",
        "MyOwnProject" .. "_" .. buildvsver
    }

    files    { 
        "TestMyProject.cs",
    }

    configuration "*"
        targetname ( "TestMyProject" )
        flags { "Symbols" }
        defines { "DEBUG" }

After you reach some sort of understanding how things works - you can even create for .lua itself it's own custom build step to launch premake5, or even to customize project generation - like create lua functions which helps you more advanced projects.

Please note that I'm using a lot of advanced stuff which you might not need (Most of my projects are compiling for 64 and 32 bit cpu's, and so on...) - may be it makes sense to start from zero than to copy config shown by me. Then you will have understanding how things works.