I'm building zeromq 4.0.5. I need a 64-bit static build. I'm using VS2013. When I go into the configuration manager and change the platform to x64 the platform for libzmq remains Win32. If I manually change that one to x64 and close the dialog, it is back at Win32 when I open it again. Why? How do I get it to x64?
I resolved my issue by editing the project file (.vcxproj). I went through made an x64 entry for every win32 entry.
For example, I found this entry:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='StaticRelease|Win32'" Label="Configuration">
<ConfigurationType>StaticLibrary</ConfigurationType>
<CharacterSet>MultiByte</CharacterSet>
<WholeProgramOptimization>true</WholeProgramOptimization>
<PlatformToolset>v120</PlatformToolset>
</PropertyGroup>
So I added this entry:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='StaticRelease|x64'" Label="Configuration">
<ConfigurationType>StaticLibrary</ConfigurationType>
<CharacterSet>MultiByte</CharacterSet>
<WholeProgramOptimization>true</WholeProgramOptimization>
<PlatformToolset>v120</PlatformToolset>
</PropertyGroup>
There were probably around a dozen entries that needed to be added. No changes other than Win32->x64 were made for the entries.
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>
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.
Is it possible to compile AVScan Minifilter given in the MSDN Sample for Windows 7? as it's target client is Windows 8. I am using Visual Studio 2013 with WDK 8.1, the sample project don't have Win7 Debug/Release in the configuration manager. if it is possible how can it be done? Kindly guide me.
I had to do something similar (had to build change minifilter driver for win 7 x64). I just copied the settings from the project file of minispy fs minifilter driver, which had the working win7 configuration. So what you need to do is:
Add a new configuration in config manager called "Win7 Debug". Save and close.
Open the AVScan minifilter C++ project in notepad
Overwrite these sections in the project file:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Win7 Debug|x64'" Label="Configuration">
<TargetVersion>Win7</TargetVersion>
<UseDebugLibraries>True</UseDebugLibraries>
<DriverType>WDM</DriverType>
<PlatformToolset>WindowsKernelModeDriver8.1</PlatformToolset>
<ConfigurationType>Driver</ConfigurationType>
</PropertyGroup>
<ItemDefinitionGroup Condition="'$(Configuration)|$(Platform)'=='Win7 Debug|x64'">
<Link>
<AdditionalOptions>%(AdditionalOptions) /map</AdditionalOptions>
<AdditionalDependencies>%(AdditionalDependencies);$(DDK_LIB_PATH)\fltMgr.lib</AdditionalDependencies>
</Link>
<ClCompile>
<TreatWarningAsError>true</TreatWarningAsError>
<WarningLevel>Level4</WarningLevel>
<AdditionalIncludeDirectories>%(AdditionalIncludeDirectories);..\inc</AdditionalIncludeDirectories>
<PreprocessorDefinitions>%(PreprocessorDefinitions);_WIN2K_COMPAT_SLIST_USAGE</PreprocessorDefinitions>
<ExceptionHandling>
</ExceptionHandling>
</ClCompile>
<ResourceCompile>
<AdditionalIncludeDirectories>%(AdditionalIncludeDirectories);..\inc</AdditionalIncludeDirectories>
<PreprocessorDefinitions>%(PreprocessorDefinitions);_WIN2K_COMPAT_SLIST_USAGE</PreprocessorDefinitions>
</ResourceCompile>
<Midl>
<AdditionalIncludeDirectories>%(AdditionalIncludeDirectories);..\inc</AdditionalIncludeDirectories>
<PreprocessorDefinitions>%(PreprocessorDefinitions);_WIN2K_COMPAT_SLIST_USAGE</PreprocessorDefinitions>
</Midl>
</ItemDefinitionGroup>
Save and close.
Open in VS and build!
There is no need to have a separate binary for Windows 7 or different version of the OS with a few conditions.
Driver binaries are just plain old executable files just like DLLs or EXEs. They have a PE header IAT etc.
As long as your compiled driver does not attempt to call APIs which were not supported in that OS you should be OK.
For those APIs or functions simply dynamically load them if the version you are running on supports them via MmGetSystemRoutineAddress or FltGetRoutineAddress.
So, simply compile your driver with version of lowest OS you plan to support and good luck from there.
Cheers,
Gabriel
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.