While migrating an old C++ project from Visual Studio 6 up to Visual Studio 2012, we came across an odd set of warnings from inside the standard Microsoft platform headers:
warning C4005: '__useHeader' : macro redefinition
warning C4005: '__on_failure' : macro redefinition
An online search only found a few other people running into this error. In some cases, it was people trying to use VS2012 to compile legacy DirectX code - which I am not doing. In other cases, it was people trying to use VS2012 to target Windows XP (using the new option from Update 1) - which I am doing.
The DirectX question was answered that the warning will always be there to tell you that you're compiling with an out-of-date (pre-Win8) version of DirectX, and you'll just have to live with it.
The Windows XP question was not answered. Other people simply said that they couldn't reproduce the problem.
I reproduced it, and found the cause, which I am writing up here to help anybody else who encounters this.
Go into the project properties, and find the "Preprocessor Definitions" field.
In addition to the default and added definition constants, you should see a macro:
%(PreprocessorDefinitions)
This macro apparently brings in some additional compiler-provided preprocessor definitions. I am not sure what version of Visual Studio introduced this macro, but it was not there in Visual Studio 6.
In Visual Studio 2012, this macro is required to be present in your project's Preprocessor Definitions field. It may also be required in earlier versions of Visual Studio, but I have not tested these.
If this macro is missing, you will see the error messages as shown above.
UPDATE:
See Edmund's answer to this same question first -- give that a try. If it works, great! If not... try the following:
ORIGINAL:
Use the workaround mentioned on the "Workarounds" tab of this web page:
http://connect.microsoft.com/VisualStudio/feedback/details/789965/resource-editor-warning-rc4005-on-toolset-visual-studio-2012-windows-xp-v110-xp
Namely, add:
#define _USING_V110_SDK71_ 1
...directly in the .rc file before it includes anything that would include the system headers that cause this warning.
Haven't found a solution to this published anywhere online, so here's what worked for me.
I'm building a project with 110_xp tools
I get these warnings ...
c:\program files (x86)\microsoft sdks\windows\v7.1a\include\sal_supp.h(57): warning C4005: '__useHeader' : macro redefinition
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\sal.h(2872) : see previous definition of '__useHeader'
c:\program files (x86)\microsoft sdks\windows\v7.1a\include\specstrings_supp.h(77): warning C4005: '__on_failure' : macro redefinition
C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\sal.h(2882) : see previous definition of '__on_failure'
Clearly an inconsistency between the VC 11 headers and 7.1a sdk headers.
In my stdafx.cpp I did this ...
#define _USING_V110_SDK71_
#include "stdafx.h"
... the build problem has gone away.
This is a resource compiler warning. The solution is easy. Right click on the .rc file in the solution explorer and choose Properties. Now go to Resources > General > Preprocessor Definitions, and add
%(PreprocessorDefinitions)
Adding #define _USING_V110_SDK71_ in Stdafx.cpp or Stdafx.h would not work if your cpp files do not have precompiled headers.
To solve this problem, the following works.
Right-click project in Solution Explorer* → Properties → C/C++ → Preprocessor → Preprocessor definition → edit → Add _USING_V110_SDK71_
For me another solution worked.
In project Properties → Configuration properties → C/C++ → General, I changed the field Addition Include Directories path to SDK with this macro:
$(WindowsSDK_IncludePath)
Before that, this field had the path to my SDK v7.1, and I had the same warnings.
It is still simpler.
Just check the checkbox "Inherit from parent or project defaults" in Configuration Properties → C/C++ → Preprocessor / Preprocessor Definitions → Edit.
I had this problem in some projects that originated with VC++ 2003 and have been incrementally upgraded over the years. I found that while the project settings had %(PreprocessorDefinitions) in Preprocessor Definitions, a few of the .cpp files didn't (The oldest ones). After changing them to "Inherit from parent or project defaults" it got rid of the warnings.
For me this happened with Visual Studio 2017 (both fresh and repaired installation). Obviously the Windows 7.1 SDK had been installed before VS2017 and had been integrated into a Visual Studio 2005 installation.
In my case the two files:
%LOCALAPPDATA%\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props
%LOCALAPPDATA%\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props
contained references to the include directories and libraries of the Windows 7.1 SDK. Removing these references did the job.
Keep in mind that every single C++ project for Win32 and x64 respectively inherits from these property sheets.
Although this answer is for VS10, it's of interest as might provide some clues as to what's going on viz the VC++ directories macros:
The warning appeared when these statements were added in the header file of a project, MyApp:
#ifndef NTDDI_WINXPSP3
#define NTDDI_WINXPSP3 0x05010300
#endif
#ifndef NTDDI_VISTA
#define NTDDI_VISTA 0x06000000
#endif
#ifndef NTDDI_VISTASP1
#define NTDDI_VISTASP1 0x06000100
#endif
#ifndef NTDDI_WS08
#define NTDDI_WS08 0x06000100
#endif
Warnings like the following popped up for all but the XPSP3 def.:
Warning RC4005: 'NTDDI_VISTASP1' : redefinition C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\include\sdkddkver.h.., MyApp
MyApp was a WinDebug 32 build, noting Windows7.1SDK appeared in the X64 section of the proj file:
<PropertyGroup Condition="'$(Configuration)|$(Platform)'=='Debug|x64'" Label="Configuration">
<PlatformToolset>Windows7.1SDK</PlatformToolset>
The inherited value for Preprocessor Definitions was _VC80_UPGRADE=0x0600. Having used the SDK toolset prior to reverting to V100, the SDK libraries were found as inherited_from in Include directories and Library Directories in the VC++ Directories section, as noted here.
Looks like the warning is generated as a result of a combination of upgrading, migration, or toolset changes.
Edit: An unrelated issue in VS2017 (MBCS) is opting to use
LoadCursorW(nullptr, IDC_ARROW)
instead of the default LoadCursorA(...) in a WNDCLASSEXW structure. A possible solution is to redefine like so:
#define IDC_ARROW MAKEINTRESOURCEW(32512)
Here the warning can be suppressed by using the #undef procedure prior to the #define:
#ifdef IDC_ARROW
#undef IDC_ARROW
#endif
#define IDC_ARROW MAKEINTRESOURCEW(32512)
I know this is old question, but... "sometimes they come back" :)
Faced same warnings after install VS 2012 Express at fresh OS. After some investigation i decided to compare my current Program Files (x86)\Microsoft Visual Studio 11.0\VC\include folder with the same folder with VS 2012 Update 4.
Here is comparison result:
And sal.h diffs:
So simple copying __useHeader's checks fixed all warnings.
Related
I checked out a copy of a C++ application from SourceForge (HoboCopy, if you're curious) and tried to compile it.
Visual Studio tells me that it can't find a particular header file. I found the file in the source tree, but where do I need to put it, so that it will be found when compiling?
Are there special directories?
Visual Studio looks for headers in this order:
In the current source directory.
In the Additional Include Directories in the project properties (Project -> [project name] Properties, under C/C++ | General).
In the Visual Studio C++ Include directories under Tools → Options → Projects and Solutions → VC++ Directories.
In new versions of Visual Studio (2015+) the above option is deprecated and a list of default include directories is available at Project Properties → Configuration → VC++ Directories
In your case, add the directory that the header is to the project properties (Project Properties → Configuration → C/C++ → General → Additional Include Directories).
Actually, on my windows 10 with visual studio 2017 community, the path of the C++ header are:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17134.0\ucrt
The 1st contains standard C++ headers such as <iostream>, <algorithm>. The 2nd contains old C headers such as <stdio.h>, <string.h>. The version number can be different based on your software.
If the project came with a Visual Studio project file, then that should already be configured to find the headers for you. If not, you'll have to add the include file directory to the project settings by right-clicking the project and selecting Properties, clicking on "C/C++", and adding the directory containing the include files to the "Additional Include Directories" edit box.
There seems to be a bug in Visual Studio 2015 community. For a 64-bit project, the include folder isn't found unless it's in the win32 bit configuration Additional Include Folders list.
There exists a newer question what is hitting the problem better asking How do include paths work in Visual Studio?
There is getting revealed the way to do it in the newer versions of VisualStudio
in the current project only (as the question is set here too) as well as
for every new project as default
The second is the what the answer of Steve Wilkinson above explains, what is, as he supposed himself, not the what Microsoft would recommend.
To say it the shortway here: do it, but do it in the User-Directory at
C:\Users\UserName\AppData\Local\Microsoft\MSBuild\v4.0
in the XML-file
Microsoft.Cpp.Win32.user.props
and/or
Microsoft.Cpp.x64.user.props
and not in the C:\program files - directory, where the unmodified Factory-File of Microsoft is expected to reside.
Then you do it the way as VisualStudio is doing it too and everything is regular.
For more info why to do it alike, see my answer there.
Tried to add this as a comment to Rob Prouse's posting, but the lack of formatting made it unintelligible.
In Visual Studio 2010, the "Tools | Options | Projects and Solutions | VC++ Directories" dialog reports that "VC++ Directories editing in Tools > Options has been deprecated", proposing that you use the rather counter-intuitive Property Manager.
If you really, really want to update the default $(IncludePath), you have to hack the appropriate entry in one of the XML files:
\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\v100\Microsoft.Cpp.Win32.v100.props
or
\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64\PlatformToolsets\v100\Microsoft.Cpp.X64.v100.props
(Probably not Microsoft-recommended.)
It looks for files in the directory mentioned in options" cwd, you can include all sub directory under a path as shown below.
it will create a single output file.
it will compile all files together in the directory specified in cwd
project Structure:
moduelTest
-header_files
- util.h
-source_files
- util.c
- main.c
I got issue with includes in visual studio. I want to compile the project both for windows and linux.
In visual studio, I got a tiny class in .hpp file, which uses std::exception and std::is_pod<T> but I did not include type_traits nor stdexcept!! And the file compiles just fine with Visual Studio! Why?
Doing so on linux gives me error
In file included from Packet.hpp:3:0,
from AbstractPacketFactory.hpp:2,
from AuthenticationPacketFactory.hpp:2,
from AuthenticationPacketFactory.cpp:1:
ByteSerializer.hpp: In member function ‘byte_serializer& byte_serializer::operator>>(T&)’:
linux g++ is correct - why does visual studio not warn me? Is there something I can do about it? I am using VS as my primary IDE and I would like to avoid such surprise in future (currently there are 50 errors like that...)
I got a function where i made a mistake:
static_assert(std::is_pod<T>, "T must be a POD");
You have to use it with ::value or () - yet visual studio compiles std::is_pod<T> it without any warning. And that was the reason of error avalanche...
Your Visual Studio Projects might be configured to use Precompiled Headers to use. stdafx.h is there when you use Precompiled Header.
Just remove stdafx.h from Precompiled Headers and see if Compilation succeeds on windows.
You can find Precompiled Headers in Project Properties > C++ > Precompiled Header.
If you want to make cross platform projects you should remove that Precompiled setting.
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
xxx\vc\atlmfc\include\atlcore.h(638): error C2039: “SetDefaultDllDirectories”: is not a member of "global namespace"
#ifndef _USING_V110_SDK71_
// the LOAD_LIBRARY_SEARCH_SYSTEM32 flag for LoadLibraryExW is only supported if the DLL-preload fixes are installed, so
// use LoadLibraryExW only if SetDefaultDllDirectories is available (only on Win8, or with KB2533623 on Vista and Win7)...
IFDYNAMICGETCACHEDFUNCTION(L"kernel32.dll", SetDefaultDllDirectories, pfSetDefaultDllDirectories)
{
return(::LoadLibraryExW(pszLibrary, NULL, LOAD_LIBRARY_SEARCH_SYSTEM32));
}
#endif
the functions in it are all not realized by VS
so how do I solve this problem?
is there something wrong with the libray?I run this program in VS2012
You have to make sure "_USING_V110_SDK71_" is defined in your project properties. Visual Studio automatically defines this for you. It normally doesn't "show up" because "Inherit from parent or project defaults" is un-ticked.
I've found this common when upgrade from old atl projects that the stdafx.cpp has "Inherit from parent or project defaults" un-ticked for some reason.
You should check both the project settings as well as the individual stdafx.cpp file settings to determine that in the Preprocessor Definitions the "Inherit from parent or project defaults" check box is checked. In some cases the Preprocessor Definitions dialog of the Project file is checked however the Preprocessor Definitions dialog of the specific stdafx.cpp file is NOT checked.
Changing the order of Include Directories and included SDK folder works for me:
$(IncludePath);C:\Program Files x86\Microsoft SDKs\Windows\v7.1A\Include
If I put folder C:\Program Files %28x86%29\Microsoft SDKs\Windows\v7.1A\Include before $(IncludePath), I will get this error.
I also met this issue on VS 2012.
This is caused because you are using the Windows SDK 7.1 which lacks of SetDefaultDllDirectories function call in VS 2012 (VC11). You may notice there is #ifndef _USING_V110_SDK71_ guarded flag to avoid using undefined SetDefaultDllDirectories.
Just define _USING_V110_SDK71_ in your project to let SDK knows you are in this toolset or upgrade to higher version of SDK.
I have had similar problem using VS2008, it was not recognizing a function. I solved it by adding DDX_Control to the DoDataExchange(CDataExchange* pDX).
Put following lines in include above all
$(VC_IncludePath)
$(WindowsSDK_IncludePath)
Uncheck check box "inherit from parent or project defaults"
I copy _USING_V110_SDK71_ in part C/C++ in sub branch preprocessor / preprocessor definition and once unchech inherit from parent ... and do build project and then recheck this option and solved problem
I had the same issue . this trick work for me. this issue comes when visual studio can't load development environment properly . can't load environment variables. so I have tried this and it works fine.
Step #1
Start command prompt of visual studio which you are using
Step #2
run this command .
devenv /useenv
this command will open visual studio and then open your project and compile.
I checked out a copy of a C++ application from SourceForge (HoboCopy, if you're curious) and tried to compile it.
Visual Studio tells me that it can't find a particular header file. I found the file in the source tree, but where do I need to put it, so that it will be found when compiling?
Are there special directories?
Visual Studio looks for headers in this order:
In the current source directory.
In the Additional Include Directories in the project properties (Project -> [project name] Properties, under C/C++ | General).
In the Visual Studio C++ Include directories under Tools → Options → Projects and Solutions → VC++ Directories.
In new versions of Visual Studio (2015+) the above option is deprecated and a list of default include directories is available at Project Properties → Configuration → VC++ Directories
In your case, add the directory that the header is to the project properties (Project Properties → Configuration → C/C++ → General → Additional Include Directories).
Actually, on my windows 10 with visual studio 2017 community, the path of the C++ header are:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.15.26726\include
C:\Program Files (x86)\Windows Kits\10\Include\10.0.17134.0\ucrt
The 1st contains standard C++ headers such as <iostream>, <algorithm>. The 2nd contains old C headers such as <stdio.h>, <string.h>. The version number can be different based on your software.
If the project came with a Visual Studio project file, then that should already be configured to find the headers for you. If not, you'll have to add the include file directory to the project settings by right-clicking the project and selecting Properties, clicking on "C/C++", and adding the directory containing the include files to the "Additional Include Directories" edit box.
There seems to be a bug in Visual Studio 2015 community. For a 64-bit project, the include folder isn't found unless it's in the win32 bit configuration Additional Include Folders list.
There exists a newer question what is hitting the problem better asking How do include paths work in Visual Studio?
There is getting revealed the way to do it in the newer versions of VisualStudio
in the current project only (as the question is set here too) as well as
for every new project as default
The second is the what the answer of Steve Wilkinson above explains, what is, as he supposed himself, not the what Microsoft would recommend.
To say it the shortway here: do it, but do it in the User-Directory at
C:\Users\UserName\AppData\Local\Microsoft\MSBuild\v4.0
in the XML-file
Microsoft.Cpp.Win32.user.props
and/or
Microsoft.Cpp.x64.user.props
and not in the C:\program files - directory, where the unmodified Factory-File of Microsoft is expected to reside.
Then you do it the way as VisualStudio is doing it too and everything is regular.
For more info why to do it alike, see my answer there.
Tried to add this as a comment to Rob Prouse's posting, but the lack of formatting made it unintelligible.
In Visual Studio 2010, the "Tools | Options | Projects and Solutions | VC++ Directories" dialog reports that "VC++ Directories editing in Tools > Options has been deprecated", proposing that you use the rather counter-intuitive Property Manager.
If you really, really want to update the default $(IncludePath), you have to hack the appropriate entry in one of the XML files:
\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\v100\Microsoft.Cpp.Win32.v100.props
or
\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64\PlatformToolsets\v100\Microsoft.Cpp.X64.v100.props
(Probably not Microsoft-recommended.)
It looks for files in the directory mentioned in options" cwd, you can include all sub directory under a path as shown below.
it will create a single output file.
it will compile all files together in the directory specified in cwd
project Structure:
moduelTest
-header_files
- util.h
-source_files
- util.c
- main.c