I'm working on a solution that was developed under vs2008 but was opened and converted to vs2010. I was only given the vs2010 solution so I have to work under vs2010.
Is their a way to build this solution under vs2010 without using any of the vs2010 libs (Microsoft Visual Studio 10.0\VC\libs) and use only those used by vs2008
In Linker > General> Additionnal Library Directories, I've already added a link to the vs2008 libs folder.
You can change the "General > Platform Toolset" property in the Visual Studio 2010 project properties to specify which version MSBuild should use to build your project. The default value is v100, but setting it to v90 would use Visual Studio 2008. This modifies your PATH, BIN, and LIB directories before compiling/linking, so you don't have to change any directory settings manually.
I think, by default only v100, v90, and Windows7.1SDK are supported, but there are tools available to target older Visual Studio versions as well.
See e.g. http://blog.iangoodsell.com/2010/04/visual-studio-2010-and-platform-toolset.html.
Related
I have tried to switch to Visual Studio 2019 since it is now officially released, but I am having problems building a C++/CX based project.
I have not retargeted the project, but it is still configured to use the v141 platform toolset, i.e. Visual Studio 2017 Build Tools.
As far as I can tell, I have specifically installed the required build tools in Visual Studio 2019, which should be evident here:
Still, according to the project properties, Visual Studio 2017 Build Tools are not installed:
And when I build the project I get the following error:
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(378,5): error MSB8020: The build tools for Visual Studio 2017 (Platform Toolset = 'v141') cannot be found. To build using the v141 build tools, please install Visual Studio 2017 build tools. Alternatively, you may upgrade to the current Visual Studio tools by selecting the Project menu or right-click the solution, and then selecting "Retarget solution".
Am I still missing some components in my installation, or is this a bug in Visual Studio 2019?
EDIT I should point out that I still have Visual Studio 2017 installed on the same computer as well.
I had a similar issue, but this is what I was missing.
You will find these options on the Workloads tab of the VS installer on the right under Installation details (i.e. not under Individual components).
It turns out that the (Windows Runtime Component) project was not properly set up. In the .vcxproj file the ApplicationTypeRevision element was missing, which is also "evident" (if you know what you are looking for...) from looking at the project properties above, where only the General configuration properties node is visible, and the Target Platform value is empty.
Inserting the following line in the .vcxproj file immediately following e.g. the WindowsTargetPlatformMinVersion element should do the trick:
<ApplicationTypeRevision>10.0</ApplicationTypeRevision>
Most likely, it was also necessary to add the C++ Universal Windows Platform Tools. The v142 version was made available when trying to create a new C++ Universal Windows Platform project. As far as I could tell, this component was not otherwise visible in the Visual Studio Installer? Once the v142 component was installed, the corresponding v141 component was also available for installation.
I had this same problem for Visual Studio 2017, even though V141 was explicitly shown as installed. It turned out the problem was that VCTargetsPath was set in System Environment Variables to "C:\Program Files (x86)\MSBuild\Microsoft.Cpp\V4.0\V140". Removing or unsetting this variable solved the issue.
I suspect this variable was set during an earlier install of Visual Studio 2015. Even after uninstalling all other Visual Studios the variable was never removed and the problem persisted.
I recently downloaded a project from GitHub which I need in my Visual Studio Solution. However the project was built with a different platform toolset: Visual Studio 2017 - Windows XP (v141_xp) (not installed). Compiling wouldn't work because the toolset required isn't installed.
Q: As I have Visual Studio 2017 with platform toolset (v141) can I tweak the project so that it will no longer ask for v141_xp toolset ?
I searched for a way to solve the problem(I really need that project), but the only suggestion so far is to create a new solution with my default toolset and import everything manually from the downloaded project(which is pretty big).
Do a rightclick on the project in Solution Explorer inside VS2017, open properties and change the Platform Toolset from v141_xp to v141
I wrote a solution with Visual Studio 2015.
I copied the solution to a PC which has only Visual Studio 2013.
In the Project Properties I have changed the Platform Toolset to Visual Studio 2013 (v120).
The error still remains and I am not able to compile the project. Any suggestions?
Thanks.
If msbuild still complains about v140, this likely means v140 is still in the project file - which you can verify with a text editor.
Are you sure you changed the toolset for all platform/configuration combinations? For instance if you just open the settings dialog and it happens to be showing properties for Debug|Win32 and you change one of those, but then you build Release|Win32, the latter combination will still use v140. Open the proprties dialog again and verify all platforms and configurations use the correct toolset. Or use find/replace from v140 -> v120 in a text editor
Background
I am open sourcing a few old Visual Studio applications I created a while back. I have created new solutions using my new VS2012 environment for them and have gotten the projects set up as git repositories. I got everything working fine in Visual Studio 2012 with no changes to the source code, all I needed to do was make sure I was linking the proper libraries in the new project configurations.
I would like to configure these projects as to have maximum compatibility for others downloading the project from Github. On this machine I have VS2010 installed alongside the latest VS2012 version. After I got everything working right for both of the projects in VS2012, I tried to open them up in VS2010.
When I tried to build I got a single error:
Specified platform toolset (v110) is not installed or invalid.
Please make sure that a supported PlatformToolset value is selected.
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\Microsoft.Cpp.Win32.Targets 518
What I Tried
So I opened up the properties for the project, went to Configuration Options --> General and the Platform Toolset was indeed set to Visual Studio 2012 (v110). This input is a drop down box and the v110 value is not listed, instead I get two choices:
v100
v90
These correspond to VS2010 and VS2008 respectively. If I change the value to v100 and rebuild I get no errors and my program runs just fine in my Visual Studio 2010 environment.
When I open the project back up in Visual Studio 2012, if tells me that I have an old project file and asks if I want to upgrade, I say yes and it upgrades. I rebuild and run to make sure everything is still working. When I open the configuration options in VS2012 the Platform Toolset is set back to `Visual Studio 2012 (v110) but clicking the drop down input there are several more choices listed:
Visual Studio 2012 (v110)
v110_wp80
Visual Studio 2012 - Windows XP (v110_xp)
Visual Studio 2010 (v100)
Visual Studio 2008 (v90)
‹inherit from parent or project defaults›
My Questions
This has led me to several questions. I am going to pose them all. It would be nice to get as much information as I can, but a good answer to just one of them would probably solve my problem.
If I'm not using features specific to newer versions of Visual Studio, is it possible to set up a solution which can be opened and run without modification in as many versions as possible (ie. 2008, 2010, or 2012)? If so, how?
If I set the Platform Toolset to v90 (VS2008) from within Visual Studio 2012, and it's able to build and run, does this mean that it will build and run for users with VS2012, VS2010, and VS2008?
What exactly does the <inherit for parent or project defaults> option do? What would the project defaults be set up as? Can this be used to tell Visual Studio to try to using whichever installed Platform Toolset will work.
Are there any other options besides Platform Toolset in Visual Studio that I can set to increase compatibility with others' development environments?
This is a somewhat tricky situation. One of the underlying problems here is that VS2010 and VS2012 use MSBuild to build C++ projects, but VS2008 farmed it out to VCBuild instead. You can see this by comparing the project files. VS2010/VS2012 use .vcxproj, while VS2008 uses .vcproj.
If I'm not using features specific to newer versions of Visual Studio,
is it possible to set up a solution which can be opened and run
without modification in as many versions as possible (ie. 2008, 2010,
or 2012)? If so, how?
For maximum compatibility, you want to target the lowest common denominator (i.e. vc90 in this case). Note that when you do the upgrade, the solution file and project files get upgraded to the latest version, which may break compatibility with older versions of Visual Studio.
If I set the Platform Toolset to v90 (VS2008) from within Visual
Studio 2012, and it's able to build and run, does this mean that it
will build and run for users with VS2012, VS2010, and VS2008?
Not really, due to the .vcxproj / .vcproj conflict stated above.
For example, I currently have a set of .vcxproj files and a solution designed for VS2010. I use VS2012 as my IDE, so when I open the VS2010 solution in VS2012, I choose to NOT upgrade it and simply open it as is. VS2012 and beyond should be backwards compatible back to VS2010 as far as project files go.
For maximum compatibility in development environments, my recommendation would be use VS2010's solution as the baseline, targeting v100. Developers can use any version newer than that and it should all work together gracefully.
I have a C++/CLI app that is built under Visual Studio 2010 but using .Net 3.5. As required, I hand edited my project file to add the TargetFrameworkVersion with a value of 3.5 and was able to build it without issue when I was in x86 (32-bit) mode. However, when I switched to build it in x64 (64-bit) mode, I got the following error:
error MSB8014: Execution path (C:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\bin\x86_amd64) could not be found.
I do have VS 2008 (9.0) installed, but there is no x86_amd64 directory under the bin folder. I tried fooling it by adding this folder (and the amd64 folder which would have failed thanks to the next line in the targets file), and then I got the error:
fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'
which I can't figure out because my project has no explicit links. I switched the C# assemblies that it interacts with to build in x64 (as opposed to any CPU) but to no avail.
FYI: Everything builds correctly in 32-bit mode. Everything also build correctly in 64 bit mode if I switch to .Net 4.0 (v100). I get the same errors building in both release and debug mode.
Any ideas would be appreciated.
If you are compiling with the "toolset" changed over from V100 to V90 on the project properties, and you have Visual Studio 2008 installed on the same development machine, just go to Control Panel, Programs and Features, select Visual Studio 2008, right-click, select Uninstall/Change, then select to add/remove f eatures, then when you are presented with a list of features, look for x64 compiler/files under Visual C++ which is not installed by default,but by clicking on the checkbox next to it, it will add the needed files.
In VS2010 it should link to C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\bin\x86_amd64
You probably got configuration wrong, or imported from a vs2008 project.
Go to Configuration -> General -> Platform Toolset. make sure it's v100 (vs2010)
If that doesn't help , look at Configuration -> VC++ Directories. That's where that path is set.
You can see that it looks in $(VCInstallDir) which in your computer is set to the VS2008 path.