After installation and uninstallation of Visual Leak Detector from https://kinddragon.github.io/vld/ it left a lot of it's Include/Lib Directories at the default VS2017 settings.
That doesn't make any problem to projects, but I just want to know, how can I change it back to defaults? Google provided answers only for older Visual Studio.
Here are screenshots:
Where does Visual Studio 2017 store its config?
In this topic (link above) it is told, that VS2017 now saves it's settings in a separate file.
But it also keeps this %AdditionalIncludeDirectories and %AdditionalLibraryDirectories in separate folder c:\Users\YourName\AppData\Local\Microsoft\MSBuild\v4.0\
Here is how Microsoft.Cpp.Win32.user.props looked like:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets">
</ImportGroup>
<PropertyGroup Label="UserMacros"/>
<PropertyGroup/>
<ItemDefinitionGroup><ClCompile><AdditionalIncludeDirectories>C:\Program Files (x86)\Visual Leak Detector\include;%(AdditionalIncludeDirectories)</AdditionalIncludeDirectories></ClCompile><Link><AdditionalLibraryDirectories>C:\Program Files (x86)\Visual Leak Detector\lib\Win32;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories></Link><Lib><AdditionalLibraryDirectories>C:\Program Files (x86)\Visual Leak Detector\lib\Win32;%(AdditionalLibraryDirectories)</AdditionalLibraryDirectories></Lib></ItemDefinitionGroup>
<ItemGroup/>
</Project>
Also same in Microsoft.Cpp.x64.user.props.
So change the settings for whatever you want and that will change settings in VS2017 (I just deleted the folder).
Related
Since about one of the latest updates to Visual Studio 2017 I started getting the following warning during the build of my MFC project:
1>C:\Program Files (x86)\Microsoft Visual
Studio\2017\Community\Common7\IDE\VC\VCTargets\Platforms\x64\PlatformToolsets\v141_xp\Toolset.targets(39,5):
warning MSB8051: Support for targeting Windows XP is deprecated and
will not be present in future releases of Visual Studio. Please see
https://go.microsoft.com/fwlink/?linkid=2023588 for more information.
How do I disable this warning?
Here's the project configuration:
Add this to your .vcxproj file either into an existing PropertyGroup or one of its own.
<PropertyGroup>
<XPDeprecationWarning>false</XPDeprecationWarning>
</PropertyGroup>
or via command line
msbuild [project file] /p:XPDeprecationWarning=false
Another possibility is to go to your Property Manager window and "Add a new property sheet..." to your project. Right click on the new sheet and select "common Properties"->"User Macros"->"Add Macro" and use the name XPDeprecationWarning and a value of false. Sadly you can't just do this on your project as Visual Studio doesnt allow you to use the GUI to edit UserMacros on the root project file (I have always wondered why as the node is there in the file ).
These should all do exactly the same thing so if one is not working for you then I'm not sure why any of the others would be any more successful.
For those using separate property sheets (found in View --> Other Windows --> Property Manager) to combine properties from multiple projects into a single file, where mine is AllCommon.props, I was able to add replace a null <PropertyGroup /> with
<PropertyGroup>
<XPDeprecationWarning>false</XPDeprecationWarning>
</PropertyGroup>
So the whole property file now looks like:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets" />
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
<XPDeprecationWarning>false</XPDeprecationWarning>
</PropertyGroup>
<ItemDefinitionGroup>
<ClCompile>
<WarningLevel>Level4</WarningLevel>
<AdditionalIncludeDirectories>..\MyCommonLibrary</AdditionalIncludeDirectories>
<CallingConvention>StdCall</CallingConvention>
<TreatWarningAsError>true</TreatWarningAsError>
</ClCompile>
</ItemDefinitionGroup>
<ItemGroup />
</Project>
This works, and I curiously didn't have to do anything with User Macros. This file has to be edited by hand, as I have not found a way to do it with the GUI.
Basically, I want everything in my "Resources" folder to be an EmbeddedResource.
This question is perfect, but the question there is about the old csproj format. In Visual Studio, how can I set the Build Action for an entire folder?
This seems to work, in the .csproj file:
<ItemGroup>
<EmbeddedResource Include="Resources\**" />
</ItemGroup>
When I try to create win32 C++ project it's giving me the following error:
Unable to read the file. project cannot be loaded. Root element is missing
Here is a screen shot. I had to reinstall the studio:
The C:\Users\...\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props is missing, as the OP clarified in a comment. This would suggest that the VS (re)installation did not complete successfully.
For a quick try, you could create the missing file yourself in Notepad with the following contents.
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
</Project>
Chances are, however, that there may be more issues with the VS installation than just this missing file.
My setup is the following:
Windows 8.1, Microsoft Visual Studio 2012
I wish to build against the Windows 8.1 SDK. My application is c++, no windows runtime components or anything like that.
I have the windows 8.1 SDK installed but Visual Studio is building against the Windows 7 SDK, so to switch targets I modify my registry keys which point to the current SDK version:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows
However when I check the macros in Visual Studio it is now building against windows SDK 8.0 instead of 8.1.
Can anyone explain why this is happening? I have not been able to build against the windows 8.1 SDK with my setup, is it just not possible using Visual Studio 2012? I cannot find any conclusive information to tell me if it is supported or not.
What's going on
The WindowsSdkDir is a Visual Studio internal variable which is derived from registry keys based on the "Platform Toolset" project property (under "Configuration Properties / General"). For the "Visual Studio 2012 (v110)" platform toolset, registry keys such as:
HKLM\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0
HKCU\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v8.0
HKLM\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v8.0
HKCU\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Windows\v8.0
are used, irrespective of the CurrentVersion and CurrentInstallFolder keys.
How to build against Windows 8.1 SDK with Visual Studio 2012
As to described in this blog:
VS 2010/2012 users: You can use the property sheet technique for the Windows 8.1 SDK that was described in this Visual C++ Team blog post originally for VS 2010+Windows 8.0 SDK. For VS 2010, just change the part of the paths with "8.0"/"win8" to "8.1"/"winv6.3" but otherwise use all those instructions. For VS 2012, you can simplify all the paths to just add the 8.1 paths before the existing value for each variable. The updated .props are attached to this blog post. This should only be used for Win32 desktop application development.
After making those changes, you should get a property sheet (which is also provided as an attachment to the same blog) which for x86 looks like:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets" />
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
<ExecutablePath>$(ProgramFiles)\Windows Kits\8.1\bin\x86;$(ExecutablePath)</ExecutablePath>
<IncludePath>$(ProgramFiles)\Windows Kits\8.1\Include\um;$(ProgramFiles)\Windows Kits\8.1\Include\shared;$(ProgramFiles)\Windows Kits\8.1\Include\winrt;$(IncludePath)</IncludePath>
<LibraryPath>$(ProgramFiles)\Windows Kits\8.1\lib\winv6.3\um\x86;$(LibraryPath)</LibraryPath>
<ExcludePath>$(ProgramFiles)\Windows Kits\8.1\Include\um;$(ProgramFiles)\Windows Kits\8.1\Include\shared;$(ProgramFiles)\Windows Kits\8.1\Include\winrt;$(ExcludePath)</ExcludePath>
</PropertyGroup>
<ItemDefinitionGroup />
</Project>
And similarly for x64:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ImportGroup Label="PropertySheets" />
<PropertyGroup Label="UserMacros" />
<PropertyGroup>
<ExecutablePath>$(ProgramFiles)\Windows Kits\8.1\bin\x64;$(ExecutablePath)</ExecutablePath>
<IncludePath>$(ProgramFiles)\Windows Kits\8.1\Include\um;$(ProgramFiles)\Windows Kits\8.1\Include\shared;$(ProgramFiles)\Windows Kits\8.1\Include\winrt;$(IncludePath)</IncludePath>
<LibraryPath>$(ProgramFiles)\Windows Kits\8.1\lib\winv6.3\um\x64;$(LibraryPath)</LibraryPath>
<ExcludePath>$(ProgramFiles)\Windows Kits\8.1\Include\um;$(ProgramFiles)\Windows Kits\8.1\Include\shared;$(ProgramFiles)\Windows Kits\8.1\Include\winrt;$(ExcludePath)</ExcludePath>
</PropertyGroup>
<ItemDefinitionGroup />
</Project>
A word of caution however. While this would define all the paths required to build against Windows 8.1 SDK, it does not change the WindowSdkDir and related macros which would still point to the Windows 8.0 SDK. This could potentially lead to build inconsistencies if you use those macros to define project properties.
Finally, note that Visual Studio 2013 ships with Windows 8.1 SDK, and correspondingly it is the SDK used with the default "Visual Studio 2013 (v120)" platform toolset property. So if upgrading to VS2013 is an option, that might save you a bit of trouble.
I have upgraded a solution from VS2010 to VS2012.
I did that with other solutions, and it worked fine.
But now when I tried to build the updated solution, the compiler tells me:
Error 1596 error MSB8020: The builds tools for Visual Studio 2010 (Platform Toolset = 'v100') cannot be found. To build using the v100 build tools, either click the Project menu or right-click the solution, and then select "Update VC++ Projects...". Install Visual Studio 2010 to build using the Visual Studio 2010 build tools. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.Platform.targets 42 5 praat3
I don't know why the compiler tries to use VS2010.
In the project property pages, I see under "Debug source files" the following entries:
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\crt\src\
C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\atlmfc\src\mfc\
etc.
Also, if I set the "Platformtoolset" to "Inherit from project above or project standard", it defaults to "v100". I think this is the best hint about what goes wrong here.
By accident I managed to open up the Microsoft.Cpp.Platform.targets file, and I see that v90 and v100 are listed there, but not v110.
Could somebody who uses only VS2012 perhaps have a look at that file?
This is what it looks like for me:
<!--
***********************************************************************************************
Microsoft.Cpp.Platform.targets
WARNING: DO NOT MODIFY this file unless you are knowledgeable about MSBuild and have
created a backup copy. Incorrect changes to this file will make it
impossible to load or build your projects from the command-line or the IDE.
This file defines the steps/targets required to build Visual C++ projects
specifically on x86 platforms.
Copyright (C) Microsoft Corporation. All rights reserved.
***********************************************************************************************
-->
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ToolsetTargetsFound Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\$(PlatformToolset)\Microsoft.Cpp.$(Platform).$(PlatformToolset).targets')">true</ToolsetTargetsFound>
<VCTargetsPathEffective Condition="'$(ToolsetTargetsFound)' == 'true'">$(VCTargetsPath)</VCTargetsPathEffective>
</PropertyGroup>
<!-- Import Before -->
<Import Condition="Exists('$(VCTargetsPath)\Platforms\$(Platform)\ImportBefore')" Project="$(VCTargetsPath)\Platforms\$(Platform)\ImportBefore\*.targets"/>
<!-- Import platform toolset file if found in this version -->
<Import Condition="'$(ToolsetTargetsFound)' == 'true'" Project="$(VCTargetsPath)\Platforms\$(Platform)\PlatformToolsets\$(PlatformToolset)\Microsoft.Cpp.$(Platform).$(PlatformToolset).targets" />
<!-- Try to find the toolset in older versions -->
<Import Condition="'$(ToolsetTargetsFound)' != 'true' and '$(MinSupportedVCTargetsVersion)' != 'v110'" Project="Microsoft.Cpp.Platform.Redirect.targets" />
<PropertyGroup>
<PrepareForBuildDependsOn>PlatformPrepareForBuild;$(PrepareForBuildDependsOn)</PrepareForBuildDependsOn>
</PropertyGroup>
<Target Name="PlatformPrepareForBuild" DependsOnTargets="$(PlatformPrepareForBuildDependsOn)">
<PropertyGroup>
<ConfigurationPlatformExists Condition="'%(ProjectConfiguration.Identity)' == '$(Configuration)|$(Platform)'">true</ConfigurationPlatformExists>
</PropertyGroup>
<!-- Error out when building an platform that is not set in the project file -->
<VCMessage Code="MSB8013" Type="Error" Arguments="$(Configuration)|$(Platform)" Condition="'$(DesignTimeBuild)'!='true' and '$(ConfigurationPlatformExists)' != 'true'"/>
<!-- Check if toolset exists in Visual Studio 2010 or Dev11 -->
<VCMessage Code="MSB8020" Type="Error" Arguments="$(_PlatformToolsetShortNameFor_v100);$(PlatformToolset)" Condition="'$(DesignTimeBuild)'!='true' and '$(ToolsetTargetsFound)' != 'true' and '$(PlatformToolset)' == 'v100'" />
<VCMessage Code="MSB8020" Type="Error" Arguments="$(_PlatformToolsetShortNameFor_v90);$(PlatformToolset)" Condition="'$(DesignTimeBuild)'!='true' and '$(ToolsetTargetsFound)' != 'true' and '$(PlatformToolset)' == 'v90'" />
<VCMessage Code="MSB8020" Type="Error" Arguments="$(PlatformToolset);$(PlatformToolset)" Condition="'$(DesignTimeBuild)'!='true' and '$(ToolsetTargetsFound)' != 'true' and '$(PlatformToolset)' != 'v90' and '$(PlatformToolset)' != 'v100'" />
</Target>
<!-- Import After -->
<Import Condition="'$(ToolsetTargetsFound)' == 'true' and Exists('$(VCTargetsPath)\Platforms\$(Platform)\ImportAfter')" Project="$(VCTargetsPath)\Platforms\$(Platform)\ImportAfter\*.targets"/>
</Project>
Thank you for the help.
The project is set to build with VS2010 compilers (platform toolset). You might have uninstalled VS2010 and got this error.
You can change the platform toolset in project properties->General->Platform Toolset.
Change it Visual Studio 2012.
Same error for me recently with VS2017.
Turned out the solution was merely missing a dependent project.
If this is the cause, you should see something like:
Done building project "someproject.vcxproj" -- FAILED.
on the next line after the error message:
error MSB8020: The build tools for Visual Studio 2010 (Platform Toolset = 'v100') cannot be found.
This error can be confusing since your projects may have already been retargeted.
I have met the same issue as #Greg and #Jahmic when building OpenCV on Windows using CMake and VS 15 2017 (toolset v141).
I get this error:
error MSB8020: The build tools for Visual Studio 2010 (Platform Toolset
= 'v100') cannot be found.
It happens when the target config is not the first specified for DCMAKE_CONFIGURATION_TYPES in the CMAKE_ARGS.
EDIT (12/01/2020): clarification for Stanislav
It's been a while, so I hope I will not say wrong things or confuse you more since I am no expert... So take this answer very carefully please.
In my case, I was when building my project solution in a CI after adding OpenCV in our Superbuild.
The configuration of the Superbuild was done by these lines:
cmake.exe -G "Visual Studio 15 2017" -A "x64" ../myProject/Superbuild
cmake.exe --build . --config RelWithDebInfo --target ALL_BUILD
But OpenCV doesn't support the config RelWithDebInfo.
Indeed, in our External-OpenCV.cmake file I can find:
ExternalProject_Add(OpenCV
GIT_REPOSITORY "https://github.com/opencv/opencv.git"
GIT_TAG "${OPENCV_TAG}"
SOURCE_DIR OpenCV
BINARY_DIR OpenCV-build
#CMAKE_GENERATOR ${gen}
#CMAKE_GENERATOR_PLATFORM "x64"
CMAKE_ARGS
${ep_common_args}
-DCMAKE_CONFIGURATION_TYPES:STRING=Release;Debug;
-DBUILD_SHARED_LIBS:BOOL=OFF
-DBUILD_WITH_STATIC_CRT:BOOL=OFF
-DCMAKE_BUILD_TYPE:STRING=Release
-DBUILD_WITH_DEBUG_INFO:BOOL=ON
-DBUILD_DOCS:BOOL=OFF
-DBUILD_EXAMPLES:BOOL=OFF
-DBUILD_PERF_TESTS:BOOL=OFF
-DBUILD_TESTS:BOOL=OFF
-DCMAKE_INSTALL_PREFIX:PATH=${OPENCV_INSTALL_DIR}
So the lines have been changed to these ones:
cmake.exe -G "Visual Studio 15 2017" -A "x64" -T v141 ../myProject/Superbuild
cmake.exe --build . --config Release --target ALL_BUILD
Now we have understood that we didn't need to add the target platform option (-T v141) so it has been removed.
Under "C/C++", there was a lib in "Additional include directories". I did not use this lib, but it was referenced. I removed this lib.
I also deleted all "studio 2010" entries in the registry.
I know this is an old thread, but perhaps this might help somebody else who comes here because of similar issues.
I had a similar problem. VS 2015 Community (MSBuild 14) building a c++ app, wanted to use VS 2010 (v100) tools. It all came down giving msbuild an invalid configuration option. Strange.
So, recheck all those options and parameters.
I had the same issue and found out in was caused by calling msbuild without options, i.e.:
msbuild myLib.vcxproj
Calling it with an explicit target solved the issue, i.e.:
msbuild myLib.vcxproj t:Rebuild /p:Configuration=Release;Platform=x64
Maybe it helps someone 🙂
In my case, I was building using the MSbuild command for VS2017.
The problem was an incomplete conversion of the VS solution file which was partially VS2010 and partially VS2017; converting individual projects within the solution did not correct the problem, since the solution file is used at the build level to define the build version.
To correct it, I used the /Upgrade switch on the command line:
SET msbuild="C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\devenv.exe"
%msbuild% .\MyNiceProject.sln /Upgrade
After that, then I could compile the project from the command line without the error message:
%msbuild% .\MyNiceProject.sln /Rebuild "Release|Win32" /Out .\buildinfo.log