33

I have been in this situation quite a few times where visual studio does not honor the Additional Include Directories when it comes to lib and header source files. For example, I just downloaded MyGUI source code and made sure the include directories were correct. I even put them to absolute paths, Visual Studio still complained that it could not find specific header files.

Does anybody experience the same thing with projects, and if so, is there a solution to this problem?Blockquote

EDIT: My apologies for not being able to explain fully. I know that the library and source files have different include directories. The project that I received had correct directory paths for the Additional Include Directories and Additional Library Directories but Visual Studio still failed to recognize them properly. I can right click and open the header file within Visual Studio but when compiling it still complains it cannot find the required header files. I regularly make projects relying on a framework I myself programmed, so I am quite familiar with how to set up dependencies. This is however the second time this seems to be happening. I don't recall which 3rd party project I was trying to compile last time, but Visual Studio simply refused to believe that the Additional Include Directories paths is where it should look for the header files. I am not sure how to give the complete details of this particular library (MyGUI) but I can point you to the website where you can download it to try and see if it is able to find the header files that are included in the project (if it doesn't compile, that is fine, and it is probably because of additional dependencies, but it should at least be able to find files in the common folder, especially when I put absolute paths in Additional Include Directories)

Samaursa
  • 16,527
  • 21
  • 89
  • 160
  • 4
    I have never (since version 6) been unable to correctly configure Visual Studio to accept header and/or library files. Please post the directory structure of your library and how you configure your project in Visual Studio. – Jim Brissom Sep 24 '10 at 20:35
  • 2
    I've been wasting hours trying to get Visual Studio to recognize a header file in another directory. It's obviously there; I can right-click it in Solution Explorer and open it. But my #include is red-underlined, and it says "cannot open source file". The directory is included both in VC++ Directories AND in Additional Include Directories, with a full, unambiguous path. What a buggy implementation! What a waste of my time! – UserX Aug 19 '19 at 15:25
  • 1
    Got the main file to compile by including the WHOLE PATH in the #include statement, but now it's complaining about the header files included by the first header file. It's not feasible to alter dozens of header files to use full paths! Damn, I hate Microsoft! – UserX Aug 19 '19 at 15:43
  • 1
    Finally came up with a workaround: Changed from x86 to x64 and the #include statements started working. This is a violation of the laws of the language!! The word length should have no effect whatsoever on a correct program. Words alone can't express my disgust. – UserX Aug 19 '19 at 15:54
  • 5
    Ok, my bad: The properties configuration was set to x64, but my program's configuration was x86, so my changes weren't seen. I still think it's another gotcha that the properties configuration doesn't default to the same configuration as the program. – UserX Aug 20 '19 at 21:55

12 Answers12

60

This happened to me once. It turned out the inconsistency of the Debug vs Release builds. When I modified one build, the other build was being compiled. Please set both builds with same include folders and see if it works. Good luck.

sam
  • 601
  • 5
  • 2
  • 14
    Also happened to me with Win32/x64 platform! – Francesco Dondi Mar 06 '17 at 16:03
  • 1
    Actually, fix this error depend on set both Win32/x64 platform like Francesco Dondi said, not Debug vs Release builds - tested in Visual Studio 2015 – 123iamking Jul 29 '17 at 14:03
  • Also if you have other projects in the same solution, making the "Additional Include Directories" consistent may help. That's what worked for me in Visual Studio 2015. I had two projects(one for DLL and one for static lib) under the same solution, DLL is the main project. Merely changing the include directory in static lib project was not enough, I had to change the main project's setting as well to make it work, even if I was only trying to build the static lib project. – San Zhang May 14 '20 at 19:59
  • Also happened to me even in VS2022! And this worked to me! Thanks for saving my time and I'm surprised this bug existed in 2015 has not been fixed even in 2023! – C.K. Aug 31 '23 at 03:23
6

I've just spent some hours battling with failing #include paths in the compiler, inconsistencies between the compiler and intellisense.

What I finally discovered was that in the properties of the *.cpp file -- not the project, but the individual *.cpp file -- the "Additional Include Directories" property was blank. I had to explicitly set it to "inherit from from parent or project defaults" -- there's a checkbox near the lower-left corner of the dialog for editing the directory path.

I had copied this file from another project and used "Add > Existing Item..." to add it to the current project. My hypothesis was that maybe the "Existing Item" procedure skipped a property initialization step that "New Item" would normally perform. But I just tested that hypothesis by Adding another Existing and a New. Both of these files had their property set to inherit from the project, so I don't have an explanation for why my problem file was not initially set to inherit.

Anyway ... after much frustration, found and fixed that one.

Theodore Hall
  • 91
  • 1
  • 6
5

I have found (stumbled) on the solution (I think). It has something to do with the character limit imposed by the OS. Although the limit should be 260, for me it falls in the below 150, see this discussion and links to it. I downloaded and unzipped the file to C:\Users\MyUserName\My Documents\Downloads\Downloads From Chrome\MyGui3.0...[and so on]. I learned quite some time ago not to try to compile projects under such long paths, but this time it completely slipped my mind as VS did not give me a warning at all and pointed me in the wrong direction. Anyway, cutting and pasting the project to D:\ fixed the issue. I am not going to checkmark the answer however until someone confirms this.

Samaursa
  • 16,527
  • 21
  • 89
  • 160
  • 1
    Does anyone know if VS imposes a limit on the length of these paths to ensure that, when invoking `cl.exe`, the command line is not too long? – André Caron Sep 26 '10 at 17:33
5

I have the same problem : Can't find .lib file even though I've added the additional include directory.

From an answer of Additional include directory in Visual studio 2015 doesn't work, I tried:

delete the .suo file and restart VS

Then it works for me.

Rick
  • 7,007
  • 2
  • 49
  • 79
3

I had this issue too. Just like sam said - this string value containing path to your framework includes has to be the same for the Debug and Release configurations. So the best way is to choose "Configuration:All Configurations" and "Platform:All Platforms" from the two context checklists on the top of the project properties window before typing it in, or copying from windows explorer adress bar.

2

Can you elaborate on this? If I recall, there are at least two places in Visual Studio where you can configure this:

  1. Per-installation: Tools/Options/Projects and Solutions/VC++ Directories)
  2. Per-project: Project/Properties/Configuration Properties/"C/C++"/General/Additional Include Directories

If you're adding the include directories per-project (#1), which I think you are, and then trying to include from another project, this will obviously not work. Try adding them at the per-installation level and see if it works.

Also, this may sound stupid/simplistic, but make sure the path is right (i.e. copy-paste into Explorer's path bar and see if the header files are in that folder).

André Caron
  • 44,541
  • 12
  • 67
  • 125
  • Actually, I would advise against adding random libraries to the whole environment. A cleaner solution is to just add the needed directories to both projects - you don't really want each and every library lingering around in your environment. – Jim Brissom Sep 24 '10 at 20:49
  • It really depends on a number of factors. If you're talking about say, adding Qt - then globally would be wise as chances are you're using that in many projects on the same machine. – Lee Sep 24 '10 at 21:42
  • Please see the Edit in my original question for clarification – Samaursa Sep 24 '10 at 21:54
  • You shouldn't be using absolute file paths in projects anyway - we use relative file paths + Visual Studio macros that expand to local paths which can be configured for client setups. @Lee: As for Qt and similar libraries, I do agree. But this discussion is digressing the subject of this question. – Jim Brissom Sep 24 '10 at 23:29
  • I always avoid absolute paths unless I fail to come up with one properly, in which case I give VS absolute paths then convert them all to relative paths, each time making sure the program compiles. I have found the solution however, which is more of a mistake on my part. Although I would have appreciate a lot if VS warned me about it instead of throwing me off completely. – Samaursa Sep 26 '10 at 01:53
  • @AndréCaron I am having same issue using 'Additional Include directories' to add directory to a library project but the project still can't find that file. It seems like VS2010 doesn't honor to include this directory as pointed by the OP. Any ideas? – zar Dec 11 '12 at 21:29
  • @zadane: You'll have to be more specific. Can you provide the exact paths to the library on disk, the values you entered in Visual Studio, etc.? – André Caron Dec 11 '12 at 21:43
  • 1
    @AndréCaron I just posted new post if you wanna look http://stackoverflow.com/questions/13829163/additional-include-directories-in-visual-studio-2010-doesnt-work . I have spend hours to figure this out... – zar Dec 11 '12 at 21:58
1

If by lib files you mean library (.lib) files, the directory location is not specified through C/C++/General/Additional Include Directories but rather through Linker/General/Additional Library Directories.

It's logical if you think about it. C/C++ options are all compilation options, settings involved with compiling .cpp and .h files. Linker options are all linking options, settings involved with linking up .obj and .lib files.

Marc Bernier
  • 2,928
  • 27
  • 45
  • My apologies for not being able to explain fully. I know that the library and source files have different include directories. The project that I received had correct directory paths for the Additional Include Directories and Additional Library Directories but Visual Studio still failed to recognize them properly. I can right click and open the header file within Visual Studio but when compiling it still complains it cannot find the required header files. – Samaursa Sep 24 '10 at 21:41
  • I've seen that before - Visual Studio's right-click opens a different include than what is used in the compile. This usually happens when the build fails. After a successful build, this usually doesn't happen. I'd look for same-named include files throughout your include paths, even ones other than the one giving you your problem (could be an include of an include). Also try putting the full path in the #include statement and see if that gets you a little further. – Marc Bernier Sep 29 '10 at 17:47
1

I had the same symptoms in my c++ project. Navigating from header to header went fine, but after toggling to the source file of a header (let's say foo.cpp), then the navigation to an #include <bar.cpp> in that source file failed. I got the following error:

File 'bar.cpp' not found in the current source file's directory or in build system paths.

After research I noticed that the system build path given in the error where not extended with the include paths of the project. In other words: IntelliSense didn't know that the source file (foo.cpp) was part of the project, and therefore it didn't use the include paths of the project to search for the #include <bar.cpp>.

The fix for me was creating a file intelliSense.cpp (file name doesn't matter) that is part of the project, but excluded from the build. This file contains an include for each source file. ex:

#include <foo.cpp>
#include <bar.cpp>
...

This way IntelliSense knows that these source files are part of the project, and will therefore use the include paths of the project to resolve the #includes in those source files.

Floris Devreese
  • 3,127
  • 2
  • 21
  • 31
0

For me the issue was that .vcxproj Project file was read-only and after I added my directory to "Additional directories", the project file did not actually change. I was surprised that VS did not complain about this file being read-only.

So after I made that file write-able I could compile my project.

abovady
  • 85
  • 8
0

I realize this question is over 10 years old at this point, but I also just ran into this issue and none of the answers fit my scenario. After some playing with my IDE (VS 2019) for a few minutes I realized that the cpp file I was using had it's platform set to Win32, but the libs I was trying to use were built for x64.

As others have stated, make sure your project's configuration is set to -"All Configurations" when you add the necessary paths to your project as that can also be an issue. I imagine my issue will not be as common, but I figured it was worth sharing. I hope this helps someone else in the future.

Larry
  • 365
  • 4
  • 12
0

One more possible reason not mentioned earlier: make sure you are configuring properties of the correct project in a multi-project solution.

My problem was that I had a solution of two projects each using the same file with includes. Turns out that I correctly configured 'Additional Include Directories' only for one of two projects and totally forgot about another one. Of course error message was stating that only the second project and not the first one had problems.

Artyom
  • 36
  • 4
-1

Here is another 'I had the same...' in vs2015.

For me it turned out that the active setting is also depending on the 'solution configuration' and 'solution platform'. That makes 4 settings which all should be identical.

That solved the problem in my case.

PapaAtHome
  • 575
  • 8
  • 25