My project has Project > Properties > General > Platform Toolset set to v100, however when I try to build I get
Microsoft.Cpp.Win32.Targets(511,5): error MSB8008: Specified platform toolset (v110) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected.
I have searched the project file for v110 and it is not in the file. I am coming from Linux and this Visual Studio stuff is being a big headache.
Is there another setting somewhere that I may be missing?
Edit:
I am getting this message when opening the project.
C:\Users\Ryan\Downloads\CRYENGINE_Build_PC_v3_5_8_2310_freesdk\Code\CryEngine\CryAction\CryActionHeaders.vcxproj : warning : Platform 'x64' referenced in the project file 'CryAction' cannot be found. Please make sure you have it installed under '%VCTargetsPath%\Platforms\x64'.
Edit2:
I think I have found the problem. The $(PlatformToolset) macro is v110, im just not sure how to edit it yet.
I had a similar problem a long time ago. I concluded it was probably due to a bug in VS. I 'solved' it by creating a new project, and importing everything again.
Check that you build the same project configuration as you are looking at.
At the top of the General page there are Configuration > Debug/Release and Platform (can be Win32/x64) comboboxes. Toolset setting can be different for each project configuration.
Open .vcproj in a text application (Notepad++), then find all instances of that declare the version.
Anything labeled v1xx or that has the word version in the tag (ie ) will be what needs to be changed to some form representative of the target version you are using.
If it has something like v141 and you want VS10 then it needs to be changed to v101.
Hope that helps.
Related
At the start I'd like to note that I've spent some time researching this issue and suggested solutions for similar questions like this one didn't help me.
Problem background
I need to migrate a Firebreath plugin project (which I haven't worked on previously) from PC_1 to PC_2.
As far as I'm aware the project was started on PC_1 on Visual Studio 2010 and later moved to Visual Studio 2013 Pro. There's one solution consisting of 19 projects. I have an instruction which says that in order to get the plugin installer I should first Build project_x and after that Build project_y_WiXInstall. Both steps work without any issues on this machine.
Then there's PC_2 which had Visual Studio 2015 Community installed before I started working on it. I've removed it, installed Visual Studio 2013 Pro (version 12.0.21005.1 REL - exactly the same as on PC_1), moved all of the needed files and I'm trying to get rid of all of the compilation errors. So far I figured out I had to install Cmake 2.8, Windows Driver Toolkit 7.1 and manually override an incorrect VCTargetsPath MSBuild variable
Problem description
Currently when I try to compile the project on the new machine I get these two errors (this is an image link since I can't embed images yet on this account). I'm not sure what's going on with the first error message since it looks incomplete and the file CUSTOMBUILD doesn't exist, but I'm not bothered by it too much since the previous compilation error I fixed also had a similar "artifact" as the first error and it disappeared after fixing the second one.
The covered part of the second error message is the project path. The error origin (Microsoft.Cpp.Platform.targets file, line 64) looks like this:
<!-- Error out if toolset does not exists in Visual Studio 2010 or 2012 -->
<VCMessage Code="MSB8020" Type="Error" Arguments="$(_CurrentPlatformToolsetShortName);$(PlatformToolset)" Condition="'$(ToolsetTargetsFound)' != 'true'" />
What didn't help
The error description suggests using an Upgrade Solution... option, but there's no such thing when I right-click the solution
As an accepted answer for the question I've posted at the start of my post suggests, I've checked the Properties of all 19 of my projects (including the project ZERO_CHECK) but their Platform Toolset is already set to Visual Studio 2013 (v120).
I've also tried changing the Platform Toolset to inherit from parent or project defaults for all of the projects. This resulted in it switching to Visual Studio 2010 (v100) (not installed) and after that I've right-clicked on the projects and chose Upgrade VC++ compiler and libraries. After this the Platform Toolset was back to the Visual Studio 2013 (v120) but it didn't help with the compilation error.
As a NON-accepted answer for the question I've posted at the start of my post suggests, I've tried searching for all of the occurrences of 10.0 and V100 in all of my .vcxproj files to replace them but I haven't found any occurrences of them.
[EDIT]
I just got an idea to try building the project with MSBuild from the command line. There's a bit more info compared to errors inside Visual Studio, so maybe it will help with resolving the issue: https://pastebin.com/JhN3dXM3
So the thing you're missing here is that FireBreath projects are built using CMake -- the actual contents of the build directory should always be completely temporary and never stored in source control. To build the project on a new computer you need to run the prep command again from scratch.
If the previous maintainer changed the build files manually and/or migrated it to a newer version of visual studio without using cmake to do it then they did some very ugly things and all bets are off... good luck.
This is why all the firebreath documentation (I wrote most of it) strongly urges that the build directory be transient and you always do project file updates in cmake.
Hope that helps!
I just downloaded Visual Studio 2017 and converted my dialog-based C++/MFC project with it (from Visual Studio 2008 SP1.) But then when I go to Resources it shows this error:
fatal error RC1015: cannot open include file 'winres.h'
And idea how to fix this?
I just also came across this issue. It seems my friend missed to push some VS 2017 meta file to the server. My quick solution is to change the Windows SDK version to match the Windows 10 OS version or below.
You can check your OS version from the cmd tool.
Jeff T. answer is great if you have a single project.
If you have many projects in which you have to change the target Windows SDK (or if you want to make sure they all match), you'll probably prefer to use the Retarget Solution button found when right clicking on the solution:
Then just select some Windows SDK version that you have installed, and apply it to all (or whatever) projects you need to change:
That list of Windows SDK versions will probably show some that don't really work. You might have to try.
The missing files are located in two directories:
C:\Program Files\Windows Kits\10\Include\10.0.15063.0\um
C:\Program Files\Windows Kits\10\Include\10.0.15063.0\shared
Add the two paths to project properties (Project >> ...Properties >> Configuration Properties >> VC++ Directories >> Include Directories).
You should install the framework MFC
For anyone who stumbles onto this question is in the same boat as me (tried all of the above with no luck)..
I just created a fresh project and created a resource immediately (no issue) and then went ahead and readded all the code / libs that were needed. A bit annoying but I'm sure it was a mistake I made while configuring the project settings
Hopefully this helps someone out
I my case, it was caused by wrong project configuration. Specifically Property Pages -> VC++ Directories -> Include Directories and there check Inherit from parent or project defaults.
Probably VS2017 fatal error RC1015 when attempting to add a new resource. fellow also got this error with VS2017.
I am attempting to build a C++ project in a Visual Studio 2013 solution on TC 8.0.6 (build 27767).
I have installed the latest MSBuild "Microsoft Build Tools 2013" stuff (which is normally installed as part of VS 2013 install) directly on the server.
But I get the following error:
[17:05:23]VCTargetsPath is c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\
[17:05:23]PlatformToolset is v120
[17:05:23]VCMessage
[17:05:23]c:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32
Microsoft.Cpp.Win32.Targets(512, 5): error MSB8008: Specified platform toolset (v120) is not installed or invalid. Please make sure that a supported PlatformToolset value is selected.
[17:05:23]Project MyCppProject\smCpp.vcxproj failed
As far as I can see I have everything I need and I have tried various hacks to set the PlatformToolset to v110 etc., but that doesn't work either.
At this stage I would like to verify exactly what I need to install on the build server. Can someone clarify if I need anything extra please?
Many thanks
Brian
Ultimately you need to set the correct path to MSBuild. With VS 2013, build tooling became part of VS rather than .NET, making it version 12.0 instead of 4.0. The default path in this instance is:
"C:\Program Files (x86)\MSBuild\12.0\bin"
If the team foundation build is broken then it's likely because the TF server is not on version 2013. To fix the problem you need to make yourself a copy of the build template the build definition uses (assuming your version is >= 2010 and < 2013) and point to the correct tooling folder. The build templates are located in the following source path:
$/YourTeamProjectName/BuildProcessTemplates
If you can edit the template in Visual Studio you open the Workflow Foundation design surface. In there find the Run MSBuild for Project tasks (note in the default template there is more than one, but I've shown a pic of what to look for) and change the tool path property to the above path.
Once you created the template you need to change your build definition to use the new template.
For TeamCity you need to set the MSBuild ToolsVersion to version 12.0 in your build step. I'm not sure what version of TC started support for version 12.
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?
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.
.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.
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.
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.
When I try to debug my C++ application I get the error
The program can't start because MSVCP100D.dll is missing from your
computer. Try reinstalling the program to fix this problem.
I found someone with a similar problem here: Remote debugging C++ on the Windows Server 2008 platform with VS2010; MSVCP100D.dll missing however the solution given there doesn't seem to show up when I go to the solution properties.
Would reinstalling Visual Studio fix this problem?
Usually you don't want MSVCP100D.dll on your system. It's for debugging purposes only. If you get this error for your release build you must make sure that you didn't accidently add a 'Debug'-tagged Project Output to your setup project.
If you really need to debug your software on a remote machine, I suggest you do the following:
Create a new Setup project called 'CRTDebug100Setup' and add the following Merge Modules (found under C:\Program Files\Common Files\Merge Modules):
Microsoft_VC90_DebugCRT_x86.msm
policy_9_0_Microsoft_VC90_DebugCRT_x86.msm
Build, and deploy on your computer to be debugged!
Reinstalling Visual Studio fixed the problem.
This can also occur if Generate Debug info is not set to No
Configuration Properties -> Linker -> Debugging -> Generate Debug info
Followup on l33t's answer above (tried to revise it but it did not seem to appear).
Added later by gpicher 10 Jan 2012: I believe those .msm packages would be for a 9.x version of the DLL in question, not a 10.x version. I resolved a similar problem I had by making a setup project with Visual Studio 2010 installed on a 64 bit Windows installation, using the merge module Microsoft_VC100_DebugCRT_x86.msm in the folder C:\Program Files (x86)\Common Files\Merge Modules. There's a similar x64 version of the .msm if the application showing the error dialog is a 64 bit application. In this case a third party was providing me a debug build of their application in order to develop and test new plugin code against, so I couldn't change build settings, and wanted the debug functionality.
Find the Visual Studio 2010 install iso file.
Extract cab44.cab file from the ISO.
Then extract file "F_REDIST_DLL_APPLOCAL_msvcp100d_x86" from the .cab file using 7z.
Rename the file to msvcp100d.dll.
For x64 version. The cab file name is cab26.cab and the file name is F_REDIST_DLL_APPLOCAL_msvcp100d_x64.
For similar issue such missing msvcr*d.dll for another visual studio version. Here is the way I used to find the answer:
Find the Visual Studio ISO.
Extract all the .cab file.
7z.exe t *.cab > filelist.txt
gvim filelist.txt
searching for the interested file name. Hope this helps.