I'm trying to build boost on windows 7 64-bits. Running bootstrap gives
execnt.c(29) : fatal error C1083: Cannot open include file: 'windows.h': No such file or directory
and some others. I have visual studio 9.0 and the places where I have windows.h is in
C:\Program Files (x86)\Microsoft SDKs\Windows\v5.0\Include**W**indows.h, with capital W
C:\Program Files\Microsoft SDKs\Windows\v6.0A\Include**W**indows.h
C:\Program Files (x86)\Microsoft Visual Studio 9.0\SmartDevices\SDK\Smartphone2003\Include\windows.h
I have the SDK installed and even fully reinstalled Visual studio. Any way I can fix this?
Small update: I installed Visual C++ 2010 express and from the IDE I can include and the test project compiles just fine, but when I use the prompt NO projects can find the header
Try running the boost build from a VS console rather than trying to run 'cmd'. It's probably somewhere in the start menu entry for VS (used to be anyway). It used to also be available from VS itself under tools, but I think they removed it there.
This version is just cmd, but it runs a batch script that sets a bunch of very important environment variables.
For future reference of anyone looking for the same error
I have installed visual studio without registry edition permission, so I had none of the environment variables set, those that boost libraries / libxml2 et al look for when calling the cl compiler
Giving myself permission to edit the registry and uninstalling/reinstalling all visual studio related programs solved it
Edit %VS90COMNTOOLS%vsvars32.bat with administrator privileges any way you like, eg.
runas /user:Administrator "notepad %VS90COMNTOOLS%vsvars32.bat"
Find the section
:GetWindowsSdkDirHelper
#for /F "tokens=1,2*" %%i in ('reg query "%1\SOFTWARE\Microsoft\Microsoft SDKs\Windows" /v "CurrentInstallFolder"') DO (
if "%%i"=="CurrentInstallFolder" (
Change it to
:GetWindowsSdkDirHelper
#for /F "tokens=1,2*" %%i in ('reg query "%1\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v6.0a" /v "InstallationFolder"') DO (
if "%%i"=="InstallationFolder" (
When you install a newer version of the Windows SDK, it updates HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\CurrentInstallFolder to point to the newer version.
Unfortunately, the batch file that Visual Studio 2008 uses to set its paths uses this registry key to identify the location of the Windows SDK, so instead of pointing at the version of the Windows SDK that works with VS2008 (6.0a), it points to the the latest version to be installed.
Editing the registry is one option. A better option is to change the batch file so that it gets the right path from the registry, as above.
Related
I would like to compile a C++ program via Visual Studio command line tools. I would like to target the executable for 32 bit Windows XP. Tried compiling it the usual way, using x86 Native Tools Command Prompt for VS 2019, but it doesn't work on Windows XP, though runs fine on my Windows 10 machine.
Steps I take:
Open x86 Native Tools Command Prompt for VS 2019.
cd to the project directory. There I'll have 2 folders sources and headers, which shall contain .cpp and .h files respectively.
Execute command cl sources\*.cpp /EHsc /D_WIN32_WINNT=0x050103 /I headers /I <path to boost> /link /libpath <path to boost>\boost_1_77_0\bin\x86\lib\libboost_program_options-vc142-mt-s-x32-1_77.lib /out:exec_xp.exe (the project uses the boost library).
Tried this, but it doesn't work. /D \"_USING_V110_SDK71_\" seems to do nothing, and the /SUBSYSTEM:WINDOWS,5.01 piece isn't recognized by the compiler.
I have learnt from this Microsoft page that we should install deprecated Toolset to compile for WinXP. I went ahead to Visual Studio Installer and installed the C++ Windows XP Support for VS 2017 (v141) tools [Deprecated], as said in the tutorial.
But what now? How can I use this Toolset? I can't find it anywhere on my computer, let alone use it! Visual Studio Installer says it's located under C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools, but it's too vague.
UPD:
Tried with msbuild /p:PlatformToolset=v141_xp, getting this error:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Microsoft\VC\v160\Microsoft.CppBuild.targets(439,
5): error MSB8020: The build tools for v141_xp (Platform Toolset = 'v141_xp') cannot be found. To build using the v141_
xp build tools, please install v141_xp 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"
Which suggests, the compiler doesn't see the v141_xp toolset. I wonder why? It's installed for sure, I did it via the Visual Studio Installer.
I suggest you could try to set the PlatformToolset property:
msbuild myProject.vcxproj /p:PlatformToolset=…
For more details, I suggest you could refer to the Doc:MSBuild command-line reference
I'm going to use the HelixToolkit.SharpDX with VS2017 in my Windows 10 workstation, when I attempt to build the solution, it will prompt the Assertion Failed error with "No fxc.exe found".
I have checked the installation option, Windows SDK has been included, nand I have downloaded and install again, and I can see the fxc.exe in "C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x64" & "C:\Program Files (x86)\Windows Kits\10\bin\10.0.16299.0\x86" folders, so it should be available for any windows version, but unfortunately, the same error reported.
However, I have also installed VS2017 in another Windows 7 machine, it works fine, and it has the fxc.exe in the same folder as my Windows 10 workstation, but it can be located by VS2017.
Is there any setting in VS2017 to locate the fxc.exe?
Or how can I fix this issue?
Copy fxc.exe in Bin\10.0.xxx\x86 to Bin\x86 to fix this issue. Because the HLSL compile tool hard coded the path.
One can find solution on helix toolkit github page.
Visual Studio 2017. Windows 10 SDK.
Missing fxc.exe issue with newest Windows 10 SDK:
Copy fxc.exe in C:\Program Files (x86)\Windows
Kits\10\Bin\10.0.xxx\x86 to C:\Program Files (x86)\Windows
Kits\10\bin\x86 to fix this issue. Because the HLSL compile tool hard
coded the path.
This seems to have been fixed in Visual Studio 2019 16.0.2, as of writing. Just have to make sure $(WindowsSDK_ExecutablePath) is pointing to the correct SDK directory and the build version that matches with the Targeted Platform in the Project Properties page.
https://social.msdn.microsoft.com/Forums/windowsdesktop/en-US/a3032567-d8e7-4b01-81b7-0612047a6299/why-do-we-need-to-copypaste-fxcexe-from-bin100xxxxx0x86-to-binx86-directory-in-the?forum=windowssdk
Second post answered:
The executables that the C++ build process uses from the Windows SDK directory are MIDL.exe, MT.exe and RC.exe. If you digitally sign your executables then you will find signtool.exe here too. So I am kind of surprised that it finds some critical build tools correctly but others it fails to find.
My suggestion would be:
1) Verify that you are having this problem with your project in Visual Studio 2019 16.0.2 (the latest version at the time of writing) or Visual Studio 2019 Preview (16.1 Preview 1 at the time of writing). This is to check that if this has been found to be a bug, then it could have been fixed.
2) Create a completely new project. Without touching the project's executable path, try to create a sample that shows this behaviour. It doesn't need to be a full sample, just complete enough to show that Visual Studio fails to find fxc.exe.
3) If doing all of this shows that Visual Studio fails to find fxc.exe, then through Visual Studio 2019, report it as a bug.
But I will mention that a naïve test on my end shows that Visual Studio 2019 can compile HLSL shaders without any issues using the 18362, 17763 and 17134 SDKs. These were tested because these are the versions that I have installed.
As the Visual Studio installer is new from Visual Studio 2017 version, I cannot located the Visual C++ component, explained here.
How do I proceed to get the vsvars32.bat in VS2017?
VS2017 suffers from very seriously brain-damaged install path location choices. Most damning dumb thing they did is to make the edition name (Professional, Enterprise, probably Community) part of the path. This makes it quite difficult to find tools back reliably from one machine to another.
There is one environment variable that I think can solve the problem, the VSAPPIDDIR variable stores the path to the folder where the IDE is installed (devenv.exe). So if you want to run vcvars32.bat from a build event then you'd use
call "%vsappiddir%..\..\VC\Auxiliary\Build\vcvars32.bat" x86
Note that it is vc, not vs, vsvars32.bat no longer exists. You could possibly favor the "Developer Command Prompt:
call "%vsappiddir%..\tools\vsdevcmd.bat"
But judging from your link, you actually want to run the editbin.exe utility:
"%vsappiddir%..\..\VC\Tools\MSVC\14.10.25017\bin\HostX86\x86\editbin.exe" args...
The 14.10.25017 version number is no joy whatsoever either, no real insight in how that is going to change from one update to the next. It probably will.
I know the question is (well) answered, but I would like to share how I solved the problem hoping it will help people googling for a solution
#echo off
set INSTALLPATH=
if exist "%programfiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" (
for /F "tokens=* USEBACKQ" %%F in (`"%programfiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -version 15.0 -property installationPath`) do set INSTALLPATH=%%F
)
echo INSTALLPATH is "%INSTALLPATH%"
REM Save current dir for later
pushd %CD%
if NOT "" == "%INSTALLPATH%" (
call "%INSTALLPATH%\Common7\Tools\VsDevCmd.bat"
) else (
goto ERROR_NO_VS15
)
:WORK
REM Retrieve the working dir and proceed
popd
echo Doing work in %CD%
svcutil this_is_just_an_example
goto END
:ERROR_NO_VS15
echo Visual Studio 2017 Tools Not Available!
:END
echo Processing ends.
A small explanation of the above script.
vswhere.exe is a single-file, native executable you can download or redistribute with your build and deployment environments to locate Visual Studio or other products installed with the new installer for Visual Studio 2017 (from the vswhere wiki)
Starting with Visual Studio 15.2 (26418.1 Preview) vswhere.exe is installed in %ProgramFiles(x86)%\Microsoft Visual Studio\Installer (use %ProgramFiles% in a 32-bit program prior to Windows 10). This is a fixed location that will be maintained (as noted here)
This allows developers to query for several important features of a Visual Studio 2017 (and above) installation. Furthermore, the tool was designed to allow different flavors of Visual Studio (Community Edition, Professional, ...) to be installed on the same machine.
You can find several usage examples here.
As for the script, the first relevant part
if exist "%programfiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" (
for /F "tokens=* USEBACKQ" %%F in (`"%programfiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe" -version 15.0 -property installationPath`) do set INSTALLPATH=%%F
)
Queries vswhere for the installation Path of Visual Studio 2017 (-version 15.0) and sets a variable named INSTALLPATH.
It should be noted that on a 32 bits OS, you should use %programfiles% instead of %programfiles(x86)%.
Due to this issue, the script saves the current directory for later retrieval.
The script then proceeds to test the contents of the INSTALLPATH variable. If the variable is not empty, it appends "Common7\Tools\VsDevCmd.bat" to it (which is a well known relative path where one can find development tools for the corresponding Visual Studio installation). Otherwise, the script jumps to an error message and exits (you may opt to return a non-zero error code).
If all went well, you have now a full fledge Visual Studio development environment at your disposal.
The script now proceeds to retrieve the original directory and execute something, in this case a dummy call to svcutil.
Just change "vsvars32.bat" to "vsdevcmd.bat". This is compatible at least back to VS2015.
call "$(DevEnvDir)..\tools\vsdevcmd.bat"
editbin /largeaddressaware "$(TargetPath)"
Microsoft changes the vcvars32.bat to VsDevCmd.bat in VS 2017 link
I use vcvars32.bat in pré-build (project properties->build events), so for me, I've changed:
"$(DevEnvDir)..\..\VC\bin\vcvars32.bat"
to
$(DevEnvDir)\..\Tools\VsDevCmd.bat"
and it worked!
Edit:
In Visual Studio 15.9 the path was changed (as Fütemire said
in the comment), so I had to change:
$(DevEnvDir)\..\Tools\VsDevCmd.bat"
to:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools\VsDevCmd.bat
*You can create an environment variable to store the path. I couldn't find an already defined.
None of the mentioned solutions worked for me. After getting my head warmed up from the "vsvars32.bat missing" error - I went through every single line and there was too 'svcutil.exe' was missing.
I thought of fixing that and it worked. I got the following path in my machine for SvcUtil.exe:
C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin
I set the path in System Environment Variable and restarted my Visual Studio for just in case and it worked.
Hope this helps someone!
Edit:
Very Strange - it works when I have "Lightweight solution load" enabled. As soon I'ml disabling "Lightweight Solution Load" - it starts giving me same error!
In Visual Studio 2017 (inkl. C++ Build Tools installed) I do it in this manner in the post build events to check also for x86:
if not $(PlatformName) == x64 (
if exist "$(DevEnvDir)..\tools\vsdevcmd.bat" (
echo setting largeaddressaware to get 4gb access in 32 bit
call "$(DevEnvDir)..\tools\vsdevcmd.bat"
editbin /largeaddressaware "$(TargetPath)"
)
)
I have been using the trial version of VS 2012 Professional for about 1 month on my Windows 7 64-bit machine.
Today, I noticed that the Platform Toolset option (project properties) was set for Visual Studio 2010 (v100), which seemed odd, because I am running VS 2012. Changing the "Platform Toolset" to VS 2012 resulted in the error noted in the title of this question:
Cannot open include file: 'SDKDDKVer.h': No such file or directory
... while building stdafx.cpp (the error itself occurs in the file targetver.h).
A forum discussion I was browsing earlier hinted that the presence of VS 2010 during a VS 2012 install might have caused the problem. (I do not have links to those posts currently on hand.)
Because I have recently purchased VS 2012 Professional, I uninstalled the trial version of VS 2012, and then reinstalled a paid version VS 2012 (Professional) from a fresh download from the MSDN website. All told, the uninstall/reinstall required 2 hours or so.
During the reinstallation of VS 2012, I paid very close attention to all possible options, to see if any option might conceivably have caused the VS 2012 installer to "skip" the VS 2012 header files or other VS 2012 components, and use VS 2010 components instead. I could find no such option.
Reinstallation of VS 2012 was successful.
I created a new console project in a new workspace (note that my "recent projects list" still showed my recent VS 2012 projects, despite the uninstall/reinstall). The project settings for the new console project showed that the correct toolset was being used - Platform Toolset = Visual Studio 2012 (v110).
Unfortunately, building the out-of-the-box VS 2012 console application (including the precompiled header option, but no other option in the Create Project Wizard), results in exactly the same error:
Cannot open include file: 'SDKDDKVer.h': No such file or directory
What should I do?
.
ADDENDUM: Note for future readers; after changing path settings (see comments beneath answer, below) so that VS 2012 finds SDKDDKVer.h, it nonetheless fails to find stdio.h, a more serious problem because the VC11 version of stdio.h (as well as all the VC11 CRT headers) is not available on the machine anywhere.
Unfortunately, Microsoft has still not resolved these major bugs in their VS 2012 installation process. The only way I found to get a working VS 2012 installation including all VC11 CRT files is to:
Wipe your system completely clean of all MS products (this may be overkill, but I had to at least uninstall VS 2010 in addition to uninstalling VS 2012)
Remove the registry keys noted in the comments to the answer below (to be safe)
Delete residual directories (to be safe)
Restart (to be safe)
Install VS 2012 from scratch FROM THE .ISO, not the installer (assuming the installation files are downloaded from the MSDN site) (use a program like Power2Go to mount the .iso)
THEN, be absolutely sure to install VS 2012 Service Pack 1 (through "Windows Update" control panel) (without doing this step, the VC11 CRT headers are STILL not installed anywhere on the machine)
And finally, map the Windows SDK library directories as described in [this link](Link now points to a scam site, removed) (without doing this latter step, the linker fails to finde the path to the Windows kernel library)
... THEN there is a working installation of VS 2012.
Thanks alot, Microsoft.
After I set up Visual Studio 2013, I had same sdk error for a simple C++ code. I solve same problem with below steps:
Select Project Properties>Configuration>VC++ Directories>Include Directories and add that: c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Include
Select Project Properties>Configuration>VC++ Directories>Library Directories and add that: c:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Lib
After that configuration I had problem about rc.exe link error. For this problem one more thing is needed:
copy RC.exe and RcDll.dll files from C:\Program Files (x86)\Microsoft SDKs\Windows\v7.1A\Bin and past them to C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin
After all those configuration steps, you can build a simple "Hello World!" example and run if you are lucky.
from MSDN forum:
Looking at the Include Directories for this project, I see the following
$(WindowsSdkDir)include
"WindowsSdkDir" is defined to be "C:\Program Files (x86)\Windows Kits\8.0\"
Unfortunately, the folder
"C:\Program Files (x86)\Windows Kits\8.0\Include\" doesn't actually
have any header files in it. Instead it contains three sub-folders.
One of these is the folder called "shared" which happens to contain
the "SDKDDKVer.h" file shown in the error message.
If this is your situation, replace $(WindowsSdkDir)include by the three folder names (at least $(WindowsSdkDir)include\shared) in your include path in your project properties under VC++ Directories.
To add this path permanently to VS2012, you'll need to make changes to the Microsoft.Cpp.Win32.user.props file under the C:\Users\xxx\AppData\Local\Microsoft\MSBuild\v4.0 folder (where xxx is your user name).
I had this problem with VS2013. Turns out when I separately installed Windows SDK 8.1 first, then Visual Studio 2013, it fixed the problem.
I should also note that I was installing this on a Windows 7 w SP 1 VM and at no point during the installation did it have a connection to the internet (I have read elsewhere some folks think an internet connection during install will fix the problem, but I was personally unable to verify that, and now that I have it working I'm not going to backtrack and test it).
I'm trying to compile a visual studio C++ project and I can't get anywhere because of the compiler reporting "Cannot open include file: 'excpt.h': No such file or directory". The problem has been reported numerous times on the Internet but I can't find any help regarding my particular situation. The problem is not that the include path of the project are not correctly setup, the problem is that this include file (and probably a bunch of other files) are just missing from my computer. There is no such file on my hard drive. So I tried installing Windows SDK 7.1. The file is not inside the installed SDK (although it should be). I tried repairing the install, uninstall it, reinstall it... all numerous time. I also try to install, repair, uninstall, reinstall Visual Studio 2010 professional numerous time, with and without the Windows SDK installed. I even tried uninstalling the professional version to install the express VC++... nothing seems to work, no 'excpt.h' never get installed on my computer. I am clueless... someone has a hint of a solution? I'm on Windows 7.
As supplementary information, note that 'excpt.h' is included in by "windows.h". Also, the "excpt.h" file is normally installed with the Windows SDK under a path like "c:\program files (x86)\microsoft sdks\windows\v7.1\include\" and with Visual Studio under a path like "C:\Program Files\Microsoft Visual Studio 10.0\VC\include\".
EDIT: If it might help, I might add that the folder C:\Program Files\Microsoft Visual Studio 10.0\VC\include related my Visual Studio install has only two files... which is certainly not normal!!! However, I can't find any ways to get the installer to install all the .h files that should appear in this repertory.
See if you have it at C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\excpt.h Check to be sure that the system include-paths are correct in Visual Studio. If all else fails, uninstall everything, all SDK's, etc., and re-install Visual C++.
Third party search programs do a better job than the Windows one for finding things. Try Agent Ransack. It's free.
For those who have the same problem, here is the solution I found after about 10h of install/uninstall/cleaning cycles... I've uninstalled completely visual studio using this. After that, using the control panel, I've uninstalled the Windows SDK and everything that can be associated with it or with visual studio (e.g. .NET framework). Then, I've removed all the left overs by manually deleting the visual studio and the Windows SDK folders located in C:/Program files. Finally, I deleted all the entries related to the Windows SDK or to Visual Studio in the registry (they are located in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft). Then, I reinstalled Visual Studio... and it was finally working correctly. I should add that I restarted and cleaned the registry using CCleaner after any install or uninstall step.
I had this problem with a project that had been updated to VS2017 from VS2015.
This was a header included via windows.h. I knew this header should have no problems as I had other projects created directly in VS2017 that used windows.h.
Another symptom was that the intellisense was highlighting includes of standard headers (e.g string, vector etc), although these were not generating compile errors.
The fix for me was similar to VS 2010 Cannot open source file “string”.
Initially, I retargeted the project, hoping this would help (right-click the project, select retarget projects), but this did not in itself cure the problem.
I then took a working project and copied the include directories from project properties->Configuration Properties->VC++ Directories and used these to replace the same property for my broken project. This fixed the problem.
Initially, the value for this property was
$(VCInstallDir)include;$(VCInstallDir)atlmfc\include;$(WindowsSDK_IncludePath);
The replacement value was
$(VC_IncludePath);$(WindowsSDK_IncludePath);
I had the same problem, and tried the answer given by OP, but it did not work. However, copying the contents of C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC (specifically bin, lib, and include) from a machine that did work to this machine worked.
It seems the Visual Studio 2012 installer is buggy when it comes to installing into a different drive letter than C:. I have installed the VS2012 into the D: drive and got the same error. I found that for some unknown reason the installer put some of the files into the correct location at:
D:\Program Files (x86)\Microsoft Visual Studio 11.0
but the remaining files were at
C:\Program Files (x86)\Microsoft Visual Studio 11.0
so I have moved the files from the C: into the D: location and it fixed the problem.
Some situation cause such problem. If you have uninstalled vs2010. you lost platform C++ binaries for .net framework 4 forever. You have to delete all of VS 2010 2012 2013, clean system up and its accompany components and reinstall them from scratch.
Or you can download this package. Include them in your project that may solve your problem properly.
one simeple way,just copy vc directory(C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC) from other computer
Fixing your Visual Studio installation is a good idea, but you don't necessarily need to re-install the same old version of VS. I uninstalled VS 2015, then modified my VS 2017 installation to add the VC++ v140 build tools, and now my project builds.