61

Visual Studio drives me crazy and I am suspecting I am doing something wrong.

This is what I do: I installed Visual Studio (Pro '08) a long time ago, I installed the Windows SDK (Win 7 x64), someone emails me a project, it fails to build.

Invariably, it can not find windows.h. While it is easy enough to include C:\Program Files\Microsoft SDKs\Windows\v7.0\Include in the project settings of every single project, I feel that this may not be the proper way to do it. Is there a way to somehow make Visual Studio globally aware of these files?
I also tried to include the above directory in the path variable but that didn't change anything.

Also, it will randomly find windows.h but not winresrc.h in the same directory.

Edit:
It was a problem with my machine. Somehow, Visual Studio thought that my Windows SDK was in the wrong place. See accepted answer and comments for the fix.

bastibe
  • 16,551
  • 28
  • 95
  • 126

7 Answers7

80

@RichieHindle solution is now deprecated as of Visual Studio 2012. As the VS studio prompt now states:

VC++ Directories are now available as a user property sheet that is added by default to all projects.

To set an include path you now must right-click a project and go to:

Properties/VC++ Directories/General/Include Directories

Screenshot: enter image description here

Mona Jalal
  • 34,860
  • 64
  • 239
  • 408
stackunderflow
  • 10,122
  • 4
  • 20
  • 29
  • 44
    That works for individual projects. How do you set a default path for all projects in a solution? – Jay Elston Apr 07 '15 at 17:38
  • 6
    It is absurd that this useful feature has been removed in favor of something so complicated it's a nightmare... – TheSHEEEP May 17 '16 at 13:08
  • 16
    @TheSHEEEP: It's only absurd, if you don't understand the problem that needed to be solved. Prior to VS 2012 every developer on a team had to set up **their** IDE to compile any given solution. Moving the include directories into the project configurations solves this issue for everyone on the team. And frankly, [property sheets](https://msdn.microsoft.com/en-us/library/669zx6zc.aspx) are a pretty darn flexible and manageable way to set up shared project configurations. – IInspectable Aug 30 '16 at 17:30
  • I can't find it in VS2015. Maybe a screenshot would help. – gdelfino Sep 07 '16 at 17:04
  • 2
    @IInspectable I don't say it does not have its uses or validity. But the fact of development is that when you work on a project, you do so for quite a long while. Possibly years. So you need to set up your IDE once in what... a year? How horrible. Besides, you will be working on projects with very similar requirements and library needs. So, you do it once and it affects all projects needing that include. And in addition to that, a project-specific include path can only work if the path is valid on a user's machine. Which it possibly isn't so it has to be done manually anyway. – TheSHEEEP Sep 23 '16 at 09:50
  • In the end, you simply have less options. – TheSHEEEP Sep 23 '16 at 09:54
  • @TheSHEEEP: *"So you need to set up your IDE once in what... a year?"* - **Every** developer needs to set up their IDE on **every** machine they are using. Plus, you need to set up your build and integration environment (commonly a VM). A project configuration is set **once**, and works for **everyone**, **any time**, and **everywhere**. *"So, you do it once and it affects all projects needing that include."* - Right. And it affects (read: breaks) all project configurations that do not need that version of that library, or are incompatible with it. – IInspectable Sep 23 '16 at 09:57
  • @TheSHEEEP: *"a project-specific include path can only work if the path is valid on a user's machine"* - Environment variables were invented precisely for this. And since you're going to ask: Yes, Visual Studio's build system **can** consume environment variables. *"In the end, you simply have less options."* - Those who understand the change call it *"less redundancy"*. An option that has been replaced by a better alternative does not need to be carried around for any longer. – IInspectable Sep 23 '16 at 09:59
  • 2
    @IInspectable Well, since the latest Windows 10, managing environment variables is no longer a fugly mess, so I'll give you that. However, I won't even continue to argue with you since anyone disagreeing with your opinion must be an idiot for "not understanding". – TheSHEEEP Sep 23 '16 at 10:09
  • 5
    @TheSHEEEP: Let's assume that you work on a project, that uses a 3rd party library. While you work on new features, using the latest version of that library, you also need to maintain previous releases, that use previous versions of that library. If you use a global setting for that library location, you have to change it, every time you switch back and forth. And your build environment can never build 2 different releases at the same time. And you cannot ever open 2 different releases side-by-side. And now you're using tens of libraries. This does not scale (a fact, not an opinion). – IInspectable Sep 23 '16 at 10:19
  • I did this and still I get this error: 3>replay\replay_renderer.cpp(62): fatal error C1083: Cannot open include file: 'ImfOutputFile.h': No such file or directory – Mona Jalal Dec 16 '16 at 21:02
  • @IInspectable: if you compile your code from IDE, then the project is busted already. All project must start with setup a 1 line compiling tool from shell. You compile from command line, not from IDE (if your project is more than a "hello world"). So MS is propagating a wrong practice :( – Zoli Nov 02 '17 at 10:43
  • 1
    My solution contains (at this moment) 87 projects. So, to be able to add a new include folder to work with IDE (for example open a resource editor which uses a special include folder in rc file), I have to edit 87 project properties one by one. Brilliant. – Zoli Nov 02 '17 at 10:46
  • @Zotyi: Visual Studio has *native* CMake support. There's also no inherent difference between building from within the IDE and building from the command line. MS isn't propagating anything. They just provide the option to use the most efficient solution. I don't see anything wrong with that. Do you? – IInspectable Nov 02 '17 at 11:01
  • @IInspectable: For example we use "jam", not CMake. VS IDE is just used to make source edit simpler (by somebody, others use vi, others Code, etc). The product has (among others) >100 VC++ projects. VS Project files are not maintained, as not used during the build. So in prev VS I could just specify include folders centrally in IDE, and they worked fine when I edited the source. Now I lost this. Instead, I should add those include folders for >100 (unmaintained) project files. I am not against to be able to specify VC++ dirs in project files, but against that the central option is removed. – Zoli Nov 02 '17 at 11:29
  • @Zotyi: Choosing an inappropriate build system and/or failing to configure it properly is hardly the tool's fault. To fix this for you, hire quality DevOps-engineers. Besides, Visual Studio project files have supported Property Sheets for quite a while now. That is your central configuration point if you opt to use Visual Studio project files. – IInspectable Nov 02 '17 at 11:50
  • 2
    It's a very appropriate build system, works perfectly for more than 15 years (same project!!). And no, you did not seem to understand what I wrote. For me, using VS IDE is optionally, not mandatory. Now with this removal, it became simple worse and less useful. Instead, leaving this central option NEXT TO the new project specified one could have been a win-win. That is a mistake from MS. – Zoli Nov 02 '17 at 12:14
  • Double check the configuration that you update in `Property pages` so that you do not get caught in updating `Release` and building as `Debug` (with no such file errors). – dmytro.poliarush Dec 17 '19 at 10:18
29

This answer only applies to ancient versions of Visual Studio - see the more recent answers for modern versions.

You can set Visual Studio's global include path here:

Tools / Options / Projects and Solutions / VC++ Directories / Include files

RichieHindle
  • 272,464
  • 47
  • 358
  • 399
  • It lists `$(WindowsSdkDir)\include`, so I guess that `$(WindowsSdkDir)` is wrong. How can I check or change it? – bastibe Apr 20 '10 at 15:46
  • 1
    It references a registry key `CurrentInstallFolder` in `HKEY_CURRENT_USER\Software\Microsoft\Microsoft SDKs\Windows`, which lists a nonexistent directory. Fixing that fixed my problem. – bastibe Apr 20 '10 at 15:53
  • @Paperflyer: Right-click My Computer and choose Properties (or choose System from Control Panel). From the Advanced tab, select Environment Variables. There you can set your user and system-wide environment variables, like $(WindowsSdkDir). – Adrian McCarthy Apr 20 '10 at 15:58
  • I know path is there but there is no entry there for WindowsSkdDir – bastibe Apr 20 '10 at 18:41
  • 1
    @BastiBechtold It's not there because it's being set by vcvarsall.bat or by Visual Studio during project's build. – Piotr Dobrogost Mar 04 '11 at 20:50
  • 24
    See my response, this menu has now been deprecated as of VS 2012. – stackunderflow Apr 12 '13 at 15:48
  • To fix this with versions of VS later than 2012, you can find the include paths: (right-click on the project) --> properties --> configuration properties --> VC++ Directories --> Include Directories. – Elliott Apr 26 '19 at 08:26
  • 2
    @ChristianSeverin: There are still people using ancient versions of Visual Studio, and this answer is relevant to them. The correct fix is for bastibe to accept one of the other answers, which I've asked them to do. – RichieHindle Nov 21 '19 at 10:30
27

To resume the working solutions in VisualStudio 2013 and 2015 too:

Add an include-path to the current project only

In Solution Explorer (a palette-window of the VisualStudio-mainwindow), open the shortcut menu for the project and choose Properties, and then in the left pane of the Property Pages dialog box, expand Configuration Properties and select VC++ Directories. Additional include- or lib-paths are specifyable there.

Its the what Stackunderflow and user1741137 say in the answers above. Its the what Microsoft explains in MSDN too.

Add an include-path to every new project automatically

Its the question, what Jay Elston is asking in a comment above and what is a very obvious and burning question in my eyes, what seems to be nonanswered here yet.

There exist regular ways to do it in VisualStudio (see CurlyBrace.com), what in my experience are not working properly. In the sense, that it works only once, and thereafter, it is no more expandable and nomore removable. The approach of Steve Wilkinson in another close related thread of StackOverflow, editing the Microsoft-Factory-XML-file in the ‘program files’ - directory is probably a risky hack, as it isnt expected by Microsoft to meet there something foreign. The effect is potentally unpredictable. Well, I like rather to judge it risky not much, but anyway the best way to make VisualStudio work incomprehensible at least for someone else.

The what is working fine compared to, is the editing the corresponding User-XML-file:

C:\Users\UserName\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props

or/and

C:\Users\UserName\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.x64.user.props

For example:

<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <ImportGroup Label="PropertySheets">
  </ImportGroup>
  <PropertyGroup Label="UserMacros" />
  <PropertyGroup>
    <IncludePath>C:\any-name\include;$(IncludePath)</IncludePath>
    <LibraryPath>C:\any-name\lib;$(LibraryPath)</LibraryPath>
  </PropertyGroup>
  <ItemDefinitionGroup />
  <ItemGroup />
</Project>

Where the directory ‘C:\any-name\include’ will get prepended to the present include-path and the directory ‘C:\any-name\lib’ to the library-path. Here, we can edit it ago in an extending and removing sense and remove it all, removing thewhole content of the tag .

Its the what makes VisualStudio itself, doing it in the regular way what CurlyBrace describes. As said, it isnt editable in the CurlyBrace-way thereafter nomore, but in the XML-editing-way it is.

For more insight, see Brian Tyler@MSDN-Blog 2009, what is admittedly not very fresh, but always the what Microsoft is linking to.

mirh
  • 514
  • 8
  • 14
Pablo el Puro
  • 357
  • 4
  • 5
  • I tried this solution and got an issue: `$(VC_IncludePath)` and `$(WindowsSDK_IncludePath)` disappeared from include directories. – Michael Lukin Jun 15 '18 at 10:25
  • 2
    This issue could be partially solved by adding `$(VC_IncludePath);$(WindowsSDK_IncludePath)` into `IncludePath` tag but this solution looks like dirt hack. – Michael Lukin Jun 15 '18 at 11:21
2

If you are only trying to change the include paths for a project and not for all solutions then in Visual Studio 2008 do this: Right-click on the name of the project in the Solution Navigator. From the popup menu select Properties. In the property pages dialog select Configuration Properties->C/C++/General. Click in the text box next to the "Additional Include Files" label and browse for the appropriate directory. Select OK.

What annoys me is that some of the answers to the original question asked do not apply to the version of Visual Studio that was mentioned.

user1741137
  • 4,949
  • 2
  • 19
  • 28
2

To use Windows SDK successfully you need not only make include files available to your projects but also library files and executables (tools). To set all these directories you should use WinSDK Configuration Tool.

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
Piotr Dobrogost
  • 41,292
  • 40
  • 236
  • 366
1

This answer will be useful for those who use a non-standard IDE (i.e. Qt Creator).

There are at least two non-intrusive ways to pass additional include paths to Visual Studio's cl.exe via environment variables:

  • Set INCLUDE environment variable to ;-separated list of all include paths. It overrides all includes, inclusive standard library ones. Not recommended.
  • Set CL environment variable to the following value: /I C:\Lib\VulkanMemoryAllocator\src /I C:\Lib\gli /I C:\Lib\gli\external, where each argument of /I key is additional include path.

I successfully use the last one.

Tomilov Anatoliy
  • 15,657
  • 10
  • 64
  • 169
  • Using the `INCLUDE` environment variable does not work with Visual Studio. At [Remarks to #include](https://learn.microsoft.com/en-us/cpp/preprocessor/hash-include-directive-c-cpp?view=msvc-160#remarks) you will find: "*Within the Visual Studio development environment, the INCLUDE environment variable is ignored. The values specified in the project properties for include directories are used instead.*" – Ingo Sep 13 '21 at 22:07
  • What's the exact command I should put in a .bat to "Set CL "? – KcFnMi Mar 31 '22 at 03:34
  • @KcFnMi Take a look [here](https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/set_1) – Tomilov Anatoliy Mar 31 '22 at 07:25
-9

You need to make sure and have the following:

#include <windows.h>

and not this:

#include "windows.h"

If that's not the problem, then check RichieHindle's response.

Community
  • 1
  • 1
Sam Harwell
  • 97,721
  • 20
  • 209
  • 280