I recently tried to install boost libraries in C++ 14, and I added it's include paths like:
Solution Explorer > Project Name > Property Pages > VC++ Directories > "C:\Program Files (x86)\Microsoft Visual Studio 14.0\boost\boost"
I tried to compile after adding this:
#include <boost\variant.hpp>
In Error List window, I can see E1696 - cannot open source file "boost\variant.hpp" and I can't compile like before.
Then I tried with adding a backslash like "C:\Program Files (x86)\Microsoft Visual Studio 14.0\boost\boost\", still didn't work.
I also read this post and explicitly specified it's directory, but even didn't work.
Again, I read this post and did exactly same what is in given answer (as I already built project several times) , but still no success.
However, if I include a library like:
#include "C:\Program Files (x86)\Microsoft Visual Studio 14.0\boost\boost\variant.hpp"
Now compiler recognizes it, but now I can see more than 100 errors in Error List window, those errors are pointed to header files of boost libraries, not in my project file which has variant.hpp included.
All those errors are E1696 - cannot open source file "boost\<libraryname.hpp>" or E1696 - cannot open source file "boost\<subdirs>\<some other files included in libraryname.hpp>"
So, if I remove the line #include "C:\Program Files (x86)\Microsoft Visual Studio 14.0\boost\boost\variant.hpp" from my project's header file, all errors disappear suddenly and project compiles fine! no any single error now!
I want boost to work anyway, so I can use it in projects, but I can't manually edit all those header files and change <boost\... to original locations.
Please help me to get rid of this issue.
make sure you download and install the correct boost version. Installing it in the visual studio directories is possible, but not advised. I suggest you use one of the packages from here. Assuming you use visual studio 2017 and you are developing for 64bit, this could perhaps be the correct package for you.
make sure you do both: adding the include search path and the library search path to your visual studio.
The include search path should point to the boost-installation root directory (the one that contains the Jamroot file and a boost subdirectory). The library search path should point to the correct library subfolder within the boost installation. This is one of the subfolders that start with lib64-msvc-**.* (or lib32-msvc-* if you're developing for 32bit).
The default install path of the binary boost package above will install it into C:\local\boost_<boost version>. Make sure you use the paths from this installation directory and follow the instructions here.
Example:
Include search path: C:\local\boost_1_64_0
Library search path: C:\local\boost_1_64_0\lib64-msvc-14.1
Here is the code I am using.
#include "stdafx.h"
#include <iostream>
int main() {
std::cout << "hi";
return 0;
}
When I create simple c++ console application and try to build it, this error occurs:
cannot open include file 'stdio.h': No such file or directory
Why? Shouldn't stdio.h be included as a standard library? What can I do to get it back?
edit: I have just looked into C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include directory. There is no stdio.h or stdafx.h . I really am not sure why. How can I get them back?
That's because Visual studio changed the path to C headers.
There you have the info about that: https://blogs.msdn.microsoft.com/vcblog/2015/03/03/introducing-the-universal-crt/
What i did to solve this is:
Go to Project->Properties->. In Configuraton Properties->VC++ Diretories->Library Directories add a path to C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10150.0\ucrt\(Choose your architecture)
And in C/C++->General->Additional include directories add a path to:
C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt
Note: The 10.0.10150.0 may vary depending on your version.
I had a similar problem upgrading an existing C project from Visual Studio 2013 to VS2017 (I'd skipped VS2015); none of the standard headers were found there either.
The accepted answer (by Cezar Azevedo de Faveri) did work for me, but it's inelegant to just jam an absolute path in the settings, especially considering someone can change the install path of both Visual Studio and the SDKs; I'd like to write code that "just works" where possible.
So I spent a little time studying how VS2017 generates a new project, and I eventually found an answer, which is that when VS2017 upgrades an existing C project, it forgets to upgrade one critical project value, and that incorrect value — the Windows SDK Version — makes the headers unable to be found:
By default, VS2017 installs the headers only for the Windows 10 UWP SDK, but it doesn't change the "Windows SDK Version" in any projects it upgrades to a version of the SDK that was actually installed! Mine were set to "8.1" after the upgrade, and there are no headers installed for Windows 8.1
So if you're upgrading an existing project, you'll have to change this setting manually to whichever version of the headers you actually have: In my case, that was by explicitly adding 10.0.14393.0 to the list (that's the version number for the Windows 10 UWP SDK headers that come with VS2017).
(The list of installed versions can be found in the C:\Program Files (x86)\Windows Kits\10\Include folder, and in the similar folders near it.)
I know I am a bit late to this but instead of messing with the path settings, in Visual Studio 2017 you can
right-click the project
select retarget projects
select the latest or any new version of windows SDK and click OK
This will automatically take care of all include paths and libraries.
#include "stdafx.h"
There is a well-known difference between the <...> and "..." includes: briefly, that the former is for library includes and the latter is for local includes.
You mention that you were looking around for stdafx.h but couldn't find it in the compiler installation. This suggests that:
You think stdafx.h is a library file (it is not, unless it's some MS-specific extension, which I doubt, although it is traditionally used as a default filename for precompiled headers by the same--if you have made one, which you almost certainly haven't).
Because of 1., you haven't made a local file stdafx.h, and therefore this include directive should fail. If it hasn't, then something fishy is happening.
As to your actual problem, I have some notes:
<stdio.h> is the C header, not the C++ one. If you're including from a C++ file (extension .cpp, probably, for MSVC), then you should use the C++ header <cstdio>. However, this shouldn't actually cause the problem.
You aren't using the stdio anyway (at least not directly). You're using iostream, which you're properly including. If that include is the one that's causing the error, then iostream is trying to include it, can't, and your compiler installation is borked.
Try the similar program:
#include <iostream>
int main() {
std::cout << "hi" << std::endl;
return 0;
}
I have just checked myself that this compiles and executes properly under Visual Studio 2015 Professional.
If this program does not compile, I suggest reinstalling Visual Studio. In my experience, this often fixes these tricky setup issues.
I faced the same issue , it got resolved when I ran vcvarsall.bat which is present at C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC
Above there is provided solution is per project.
But if you don't want to reinstall VS from scratch or set the include directories and libraries on every solution you can modify Toolset.props found in:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\Win32\PlatformToolsets\v140\Toolset.props
<PropertyGroup>
....................
<IncludePath Condition="'$(IncludePath)' == ''">$(VC_IncludePath);$(WindowsSDK_IncludePath);**C:\Program Files (x86)\Windows Kits\10\Include\10.0.10150.0\ucrt**</IncludePath>
.......................
<LibraryPath Condition="'$(LibraryPath)' == ''">$(VC_LibraryPath_x86);$(WindowsSDK_LibraryPath_x86);$(NETFXKitsDir)Lib\um\x86;**C:\Program Files (x86)\Windows Kits\10\Lib\10.0.10150.0\ucrt\**</LibraryPath>
...........................
</PropertyGroup>
I had this error on VS2017 after upgrading from VS2015. I tried a clean + reinstall and it did not fix the error. The problem that I found was two-fold:
$(VC_IncludePath);$(WindowsSDK_IncludePath); was not in the default include path.
$(VC_IncludePath);$(WindowsSDK_IncludePath); was actually EXCLUDED in the default properties (how did this happen?!)
To fix for new projects:
Manually edit the following files:
%LOCALAPPDATA%\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props
%LOCALAPPDATA%\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props
Make sure that $(VC_IncludePath);$(WindowsSDK_IncludePath); is in the IncludePath and NOT in the ExcludePath.
To fix for old projects (that don't just inherit from the above files):
Manually edit your project properties in the Solution Explorer and make sure that $(VC_IncludePath);$(WindowsSDK_IncludePath); is in the IncludePath and NOT in the ExcludePath.
I had the same problem in Visual Studio Community 2015 after installing the current Windows SDK and as Signa already wrote earlier, this can be fixed for all projects within a "Toolset.props" file (at least for VS2015) and I find this to be the most convenient solution, because this has to be done only once. I've got a few side notes, because there is something to watch out for.
For each build platform there is an own "Toolset.props" file, so both need to be modified if you want to build for 32 and 64 bit targets:
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\Win32\PlatformToolsets\v140\Toolset.props
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Platforms\x64\PlatformToolsets\v140\Toolset.props
The files are write-protected and you need to remove the write protection before you can change those files (remember to put it back on after you're done).
As of now the current SDK version is "10.0.15063.0" and you need to adjust that to the version you want to use (or to the SDK version you have installed).
Look out for the IncludePath and LibraryPath lines in those props files and add the following paths to them:
IncludePath: $(ProgramFiles)\Windows Kits\10\Include\10.0.15063.0\ucrt
LibraryPath: $(ProgramFiles)\Windows Kits\10\Lib\10.0.15063.0\ucrt\$(PlatformTarget)
Here a sample how this looks like for the 32 bit version:
// ... some XML before that ...
<PropertyGroup>
// ... executable path .....
<IncludePath Condition="'$(IncludePath)' == ''">$(VC_IncludePath);$(WindowsSDK_IncludePath);$(ProgramFiles)\Windows Kits\10\Include\10.0.15063.0\ucrt;</IncludePath>
// ... reference path ...
<LibraryPath Condition="'$(LibraryPath)' == ''">$(VC_LibraryPath_x86);$(WindowsSDK_LibraryPath_x86);$(NETFXKitsDir)Lib\um\x86;$(ProgramFiles)\Windows Kits\10\Lib\10.0.15063.0\ucrt\$(PlatformTarget);</LibraryPath>
// ... more XML ...
</PropertyGroup>
// ... even more XML ....
After running in similar problems once more with VS2017 I took a closer look at what caused all this. And the main reason was that I was still using modified user.props files. Which was for a while a solution to add global include and library paths to all projects. But this feature is deprecated by Microsoft and the content of those files should be reset.
The files I'm talking about are the user.props files in C:\Users\your_name\AppData\Local\Microsoft\MSBuild\v4.0
For testing you can simply rename (or delete if you like risks) them and restart VS. It will create empty files for those now. And if you are on Windows 10 then in most cases this is already enough to fix all your problems. Even in older VS versions (I tested with VS2010-VS2017, for even older VS versions the troubles tend to involve registry keys and don't involve this props files). Windows/VS has become now really good at finding all the system libraries (including DirectX which was the main reason we had to modify those files in the past) and adding them in the correct include order.
Also a warning as I've seen other people recomment that. Do not change any .prop installed by the SDK. If you really need to work with props then create and add your own property sheets (which can overwrite any defaults) to your project. And don't worry, those will not be checked in to source-control so you can still distribute your project to others.
If you are still on an older Windows it might not be as easy as in Windows 10, but I'll try to give some hints:
What you are missing for that concrete error is the new $UniversalCRT_IncludePath. No need to hardcode that path, that macro should contain the correct one. So add $(UniversalCRT_IncludePath); to the IncludePath in your own property which you add then to the project.
And for LibraryPath add the correct path per platform-file, like $(UniversalCRT_LibraryPath_x64); for .x64. and $(UniversalCRT_LibraryPath_x86); for .Win32.
What also might be useful when trying to fix this: You can find out the values of all the $(MACRO) variables used in the build system inside VisualStudio. They are just very well hidden: Go in properties - custom build steps - click on command line - then don't type anything but click the down button to get "edit..." - you click that - you get a dialog which has a "Macros>>" button. And that contains a list with all macro values.
Installing Visual Studio 2015 Update 3 solves this issue, both for new projects and for existing projects created before the update.
https://www.visualstudio.com/news/releasenotes/vs2015-update3-vs
Edit: Of course, immediately after working on it for an hour then posting here, I found the stupid mistake...
I'm getting compiler errors when trying to #include <d3dx9.h> in a project. I'm receiving "fatal error C1083: Cannot open include file: 'd3dx9.h': No such file or directory".
I do have the DirectX SDK installed (I also just tried reinstalling it to no avail).
In the Project Properties:
VC++ Directories are set to "$(DXSDK_DIR)Include;$(IncludePath)" and "$(DXSDK_DIR)Lib\x86;$(LibraryPath)" for Include and Library directories respectively for all configurations—and the environment variable %DXSDK_DIR% points to C:\Program Files (x86)\Microsoft DirectX SDK (June 2010)\ as expected.
C/C++ > General settings has $(DXSDK_DIR)include listed in the Additional Include Directories
Linker > Input > Additional Dependencies has d3dx9d.lib included for Debug and d3dx9.lib included for Release configuration.
I am able to successfully compile and run tutorial projects from the DirectX Sample Browser.
Visual Studio's Intellisense/autocomplete will find d3dx9.h and suggest type and function names that are within the file (and not included through anything else I'm #includeing) so it seems that Intellisense can find it.
Any suggestions on what I'm forgetting or what else to try?
Thanks
you forgot one thing:
Go to VC++ Directories -> Library Directories
add $(DXSDK_DIR)LIB\x86
apply.
Done. Hope this helps
You should make sure you have ALL paths sorounded by quotes (").
Instead of $(DXSDK_DIR)include you should have "$(DXSDK_DIR)include"
I didn't realize that one of the other projects in the solution was #includeing a file that was #includeing a file that was #includeing d3dx9.h and I hadn't added those paths to that project.
/facepalm
Find the file on your computer, and add it's folder to the properties of your project.
Assuming you have visual studio: Properties/C/C++/General/Additional Include Libraries.
I tried all of these suggestions and none worked.
Turns out the $(DXSDK_DIR) variable doesn't work if you install DirectX while Visual Studio is still running. The solution for me was to restart Visual Studio (+ adding the paths in the solutions listed above, of course).
I'm working on adding some openCV features to a couple projects that use the Kinect and openGL/freeGLUT. I have downloaded and installed OpenCV using the pre-built libraries and successfully run a simple sample. Now I want to work with the Kinect Bridge with OpenCV Basics sample from the Kinect for Windows Developer Toolkit to get a better idea of how to use OpenCV with the Kinect. I downloaded the sample into my projects folder, opened the solution in visual studio and built it. I got the following errors:
Error 1 error C1083: Cannot open include file:
'opencv2/core/core.hpp': No such file or
directory c:\users\justin\documents\visual studio
2010\projects\kinectbridgewithopencvbasics-d2d\OpenCVHelper.h 17
and
Error 2 error C1083: Cannot open include file:
'opencv2/core/core.hpp': No such file or
directory c:\users\justin\documents\visual studio
2010\projects\kinectbridgewithopencvbasics-d2d\OpenCVFrameHelper.h 13
Initially I thought these errors were due to forgetting to specify the additional include directories. I added the same property sheet that my other OpenCV projects use to this one, but the errors remained. I tired copying the header files into the project folder: same thing. It seems like the only thing that works is specifying the full absolute file paths in the #include statements. I want to avoid doing this because visual studio wants me to change every #include in every file used in the project, including the openCV header files. I also tried shortening the name of my project folder in case the file path was too long (though I'm pretty sure that's more of an issue for the header file paths), but again no change.
The include directories and #includes that I'm trying to use are the same as in my other projects. I'm using Visual Studio 2010 on Windows 7 x64 based system.
Why would the additional include directory work for other projects, but not this one?
Usually when I see something like this it turns out to be a bad character in one of the prior include paths or other options that's messing everything up after it. I would take a look at your the command line page in the project configuration and see if you can spot anything amiss.
This could be a very silly question to any long time C++, visual studio or live555 users but I am having problems building the live555 source code with visual studio 2005. I have found a good walk through guide for creating the projects manually because .mak files are no longer supported by newer versions of visual studio but am still having problems. It seems that visual studio cannot open the .hh files that come in the include folders and I have added to the header folders of each seperate project.
Is there something special you have to do to the compilier or a plugin for the IDE to allow VS2005 to open .hh header files?
This is the error I am getting:
fatal error C1083: Cannot open include file
'BasicUsageEnvironment.hh': No such file or directory.
It seems to me that Visual studios cannot find the file, rather than it not being able to open that file type. If you right click on your project and go to
Properties->C/C++->General->Additional Include Directories
Now browse to the location of the .hh file and add it to the path. Visual studios should now be able to find the file in question. You may also have to add library paths to your solution. Please let me know if there are additional errors.