15

Me and my partner are both sharing a c++ solution via subversion.

He is using Visual Studio 11 and I am using Visual Studio 2010.

After the first time he commited and i updated, i get the following error:

Error 31 error MSB8008: Specified platform toolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected.

also, in header files i get the following error on #include <stdio.h>:

error: cannot open source file "stdio.h"

I am guessing this is a compatibility issue. How can we resolve this?

James McNellis
  • 348,265
  • 75
  • 913
  • 977
Michael
  • 22,196
  • 33
  • 132
  • 187

4 Answers4

30

In Visual Studio 11 there is a property option that allows you to specify the platform toolset.

Platform Toolset v110 is used by default if you create a new project starting from Visual Studio 11, but if can change it to v100 that is the one used by Visual Studio 2010.

Toolset option

James McNellis
  • 348,265
  • 75
  • 913
  • 977
Drake
  • 8,225
  • 15
  • 71
  • 104
  • When you open an existing 2010 project in VC++ 2012 for the first time, it will "helpfully" set the platform toolset to v110. That's how I got to this Q and A on Stackoverflow - trying to figure out how VC++ 2012 broke my project despite advertizing a "seamless round trip." The error message only told me to specify the correct platform toolset without giving any indication as to what that means or how to specify it. Of course the Microsoft documentation was useless. But googling on good old DuckDuckGo.com and clicking on the Stackoverflow hit saved the day. – Jive Dadson Sep 29 '12 at 05:30
  • P.s. Who knew some round trips have seams? In any case, the Platform Toolset item shows up under VS 2010, and setting it back to v100 worked just fine. – Jive Dadson Sep 29 '12 at 05:33
  • 2
    Note that setting it back to v100 rquires VS2010 to be installed. – JohnW Jul 12 '13 at 19:37
3

.sln and .vcxproj files saved in Visual Studio 11 are not backward-compatible with VS2010. Even if they were compatible, eventually you'd step across a code which is compilable in VS11 but not in VS10.

The best (and probably the only) way is to agree on using exactly the same development environment.

James McNellis
  • 348,265
  • 75
  • 913
  • 977
Andriy
  • 8,486
  • 3
  • 27
  • 51
  • 1
    As I understand it, if you have automatic updates running, Microsoft patched VC2010 so that it and VC2012 use the same formats. I see "Platform Toolset" now in VC++ 2010, and I do not remember seeing it there before. – Jive Dadson Sep 29 '12 at 05:35
0

A bit late in the discussion, but since you're using source control, you can remove the project and solution files from the repository and just share source code. Obviously, if you add new modules and such to a project, you'll have to manually add them in the other solution, but at least you wouldn't have to worry about this incompatibility. If you wanted to get down to it, the application can be built from the command line using just the compiler and linker switches, which tend to be far more compatible between revisions. Finally, you could use another build tool (besides MSBuild), that remains compatible across studio versions.

If you decide to remove the solution and project files, one thing to consider is saving a copy of the original YourApp.sln as YourApp.sln.2010. Then you'll have something to seed future solutions from, but updates to projects and solutions will all need done from VS 2010 and the file then copied to their .2010 version and maintained manually.

If SVN has support for patches, or if you're willing to run quilt externally (or if you switch to mercurial, you can use the MQ extensions), you can create the patch files to convert from 2010 to 2011 and remove the upgrade patche(s) before synch.

knockNrod
  • 353
  • 2
  • 10
0

Drake's solution didn't work for me as the properties for all projects in the solution were already correctly set to v100. However, the fix that did work was to clean the builds and remove all other files that weren't source files or project files. I think it was probably removing the files projname.vcxproj.user that fixed it, as perhaps the toolchain preference was somehow overriden in the user preferences.

the_mandrill
  • 29,792
  • 6
  • 64
  • 93