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.
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.
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).
I've installed these files from their site:
Qt 5.3.1 for Windows 64-bit (VS 2013, OpenGL, 571 MB)
Visual Studio Add-in 1.2.3 for Qt5
After that, I tried to follow this simple tutorial but when I try to actually build the generated project it fails at linking saying "error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'". I did exactly as the guy in the tutorial says, changed the Target Machine to Machine64 and set the platform to be x64. If I try to build it as Win32, the following message box pops up.:
I've set the "Qt Version" path to C:\Qt\Qt5.3.1\5.3\msvc2013_64_opengl. Maybe that's what's bothering the linker? On a side note, I have three projects in the solution - two of them are x86 and the Qt one is x64.
UPDATE: Everything works just fine in Qt Creator.
UPDATE 2: Qt project's vcxproj.user file:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<ShowAllFiles>true</ShowAllFiles>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">
<QTDIR>C:\Qt\Qt5.3.1\5.3\msvc2013_64_opengl</QTDIR>
<LocalDebuggerEnvironment>PATH=$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">
<QTDIR>C:\Qt\Qt5.3.1\5.3\msvc2013_64_opengl</QTDIR>
<LocalDebuggerEnvironment>PATH=$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'">
<LocalDebuggerEnvironment>PATH="$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
<QTDIR>C:\Qt\Qt5.3.1\5.3\msvc2013_64_opengl</QTDIR>
</PropertyGroup>
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Release|x64'">
<LocalDebuggerEnvironment>PATH="$(QTDIR)\bin%3b$(PATH)</LocalDebuggerEnvironment>
<QTDIR>C:\Qt\Qt5.3.1\5.3\msvc2013_64_opengl</QTDIR>
</PropertyGroup>
</Project>
Solved by exchanging the x64 edition of Qt with the x86 one. The project builds and runs as expected.
Your issue is that both 32 bit and 64 bits of your app are configured to link with Qt 64 bits. The 32 bit version requires Qt 32 bits and the 64 bit version requires Qt 32 bit. A successful configuration would set <QTDIR> to C:\Qt\Qt5.3.1\5.3\msvc2013_32_opengl on win32 and C:\Qt\Qt5.3.1\5.3\msvc2013_64_opengl on x64.
I've got a shiny new laptop with the latest Dev tools installed such as Visual Studio 2010.
Now I've got a task to build a C++ CLR app targeting the 2.0 runtime (this is well outside my comfort zone). So I've specifed the v90 Platform Toolset but when I build I get:-
error MSB8010: Specified platform toolset (v90) requires Visual Studio 2008. Please make sure that Visual Studio 2008 is installed on the machine.
Seriously, do I really need to install 2008 as well? Is there some way round this, such as just copying in some folders from a 2008 install?
If not just how much of the VS 2008 installation do I need?
Part of the problem is that VS2010 redid how compiling in c++ (cli or not) works. It now uses the MSBuild structure but I believe what you are trying to do will need the VCBuild framework that is not in 2010.
You may be able to get away with using the Visual Studio 2008 express to build. If not you should only need the c++ portion of VS2008.
Do you need to use the vc90 target though? I build my c++/cli (still new myself) with the vc10 target and it builds fine. (however i am targeting the 4.0 framework referencing some 2.0 portions)
If you set the 'Platform Toolset' in general tab of your project settings to "inherit from parent or project defaults" it will work in most of the cases.
in *.vcxproj
<PropertyGroup Label="Globals"> //Globals
<ProjectGuid>{E0047D4D-366D-4870-980B-DBB5A375BCE2}</ProjectGuid>
<RootNamespace>ECGConvertWrapper</RootNamespace>
<Keyword>Win32Proj</Keyword>
<WindowsTargetPlatformVersion>10.0</WindowsTargetPlatformVersion>
<TargetFrameworkVersion>v2.0</TargetFrameworkVersion> //there
</PropertyGroup>
Well i wrote a c++ app for a Windows CE device and selected the platform (from the sdk that came with the CD) for it, if i open the project file it says Platform Name="IEI_PXA270_E205 (ARMV4I)"
<?xml version="1.0" encoding="Windows-1252"?>
<VisualStudioProject
ProjectType="Visual C++"
Version="9,00"
Name="BootInstall"
ProjectGUID="{EBCFC92F-CD0C-4451-8FD0-4C422C5DA8C2}"
RootNamespace="BootInstall"
Keyword="Win32Proj"
TargetFrameworkVersion="196613"
>
<Platforms>
<Platform
Name="IEI_PXA270_E205 (ARMV4I)"
/>........
now i reinstalled my windows and installed the same sdk but i can't load the project it just says
"The project consists entirely of configurations that require support for platforms which are not installed on this machine. The project cannot be loaded."
and if i try to create a new project the sdk is not there..
so what am i missing i know where the sdk is located on my local hard drive... is there any way to add a "platform" manualy or some thing... the only thing that has changed that i can think of is that i have visual studio 2010 installed..
ok had to try i turned UAC off and restarted my pc installed the SDK and tada it works... gotta love UAC...?