I am getting a strange Intellisense error in VS 2010. I searched the Internet with no luck. It seem that no one else got this error before.
IntelliSense: PCH warning: header stop needs to be at global scope.
An intellisense PCH file was not generated.
Following this many other errors as it stops indexing. This happens to the recent files that I have added. I have many files in my project (278) and this happens to the most recent 5-6 of them. May be I did something it doesn't like or may be there is a limitation.
Since I couldn't found this error even in the documentation, I would like to learn the reason as well as a possible solution. Note that, I have tried to delete ipch folder and sdf file to get them generated a new. The error is given to the last line of a file. My code heavily uses templates.
EDIT:
I noticed my ipch folder is mostly empty. This probably means that entire precompiled header generation fails, rather for those files. Still, intellisense partially works, but not for those files.
This error is generated when you forget a ";" after a class declaration, for example:
#ifndef _MYCLASS_H
class MyClass {
...
public:
...
}
#endif <--- VS2010 report here the error PCH: warning...
If you put a ";" after the closing "}" the error go away. I'm not saying this is the only cause, I'm just saying that I found that error with the missing ";" in the mentioned place.
PCH stand for "pre-compiled header" - you'll need to make sure you have these configured correctly.
The error message seems to be saying that the header configured as the 'stop' for precompiled headers is being included in a nested fashion (ie., some other header is including it). By default, a solution will use stdafx.h as the 'stop' header and the idiom is that stdafx.h will be the first header included in any .cpp or .c file. Don't include stdafx.h in any other header.
The best information about how Intellisense works and how to troubleshoot it come from the Visual C++ Team Blog.
A few articles that might be helpful:
Troubleshooting Tips for IntelliSense Slowness
Precompiled Header Files in Visual Studio 2010
IntelliSense History, Part 1
IntelliSense, Part 2 (The Future)
My initial feeling is that it could be a file encoding problem, but anyway here's how I would approach figuring it out...
Create a brand new solution, does the intellisense work? If not then a VS reinstall might be in order.
If intellisense works in a different solution then there are 2 possibilities: something in your solution is screwy, or something in your folder hierarchy is screwy (permissions maybe?)
I'd delete the entire solution folder and get the latest from source control.
If it still occurs after that and you really want to find the cause, then you could remove a load of files from the project, see if the intellisense now works, remove some more... until a) you run out of files or b) you find the file that causes the error.
If a) then make a brand new solution and add your files and projects to it. If that works then compare your new solution/project files with the old ones to see what's different.
If b) then add the files back in and start pruning until you find the offending line.
Related
I'm using Microsoft Visual Studio Professional 2017 to build a project that uses the Poco libraries.
Background:
Don't know if this is pertinent, but I'll just mention that I manually downloaded and built Poco (and all the other libs needed), and everything went fine for years. Now I switched to using Miniconda3 to manage my libraries, installing Poco via conda install -c conda-forge poco and changing the relevant include paths from
$(POCO_DIR)/Foundation/include
$(POCO_DIR)/Util/include
...
to just
$(CONDA_LIBS)/include
with the system variable $(CONDA_LIBS) = D:\CodeLibraries\conda_libs\Library. This CONDA_LIBS directory exists and contains an include/Poco/ subdirectory with all the Poco header files and subdirs.
Problem:
The project compiled fine. I got a linker error, and while digging into this I found some odd behavior of Visual Studio 2017:
When I'm moving the cursor to an #include directive using any Poco header file, e.g.
#include "Poco/DateTime.h"
I can usually type CTRL+SHIFT+G to open and jump to the file in question.
This doesn't work anymore, and I get a popup telling me
D:\CodeLibraries\conda_libs\Library\include\oco\atetime.h
Cannot open file.
Note the missing letters in \(P)oco\(D)atetime.h. Note, also, that a file is found, but cannot be opened.
When I try this with a header file in a subdirectory like
#include "Poco/JSON/Parser.h"
I get the message
D:\CodeLibraries\conda_libs\Library\include\oco\son\rser.h
Cannot open file.
Note the missing letters "P", "J", and "Pa"(?!) in (P)oco\(J)SON\(Pa)rser.h.
Additional information:
The same error pops up when I drag-and-drop a Poco header file from the Windows Explorer into Visual Studio (!)
I can open these files from the Open File dialog (CTRL+O)
I can still use the CTRL+SHIFT+G shortcut to open my own header files in my project, and to open other library header files like gdal.h or boost headers
if I #include "oco/ateTime.h" (note the missing letters) and attempt to open it via CTRL+SHIFT+G I get the expected message "File 'oco/ateTime.h' not found in current source file's directory or in build system paths", with the paths listed below including D:\CodeLibraries\conda_libs\Library/include.
Question:
Any idea why both the CTRL+SHIFT+G shortcut and the drag-and-drop operation fail for Poco header files?
EDIT:
Please note:
I'm not asking about generic "File not found" errors: I can usually handle my include and lib paths quite well, thank you
slashes and backslashes can be used pretty much interchangedly in Visual Studio for the last couple of years at least
"Cannot open File" error could be due to a misconfiguration in your project include and source paths or due to a third-party extension or maybe even due to a corrupt/buggy IDE, but it has nothing to do with linker errors as you have also mentioned. You have also confirmed that the files are getting compiled, so this is surely some issue with the IDE's built-in code navigator or an extension.
With respect to linker errors, the project Configurations, lib target, library & header file versions you are referring to should match while linking against third-party libraries.
These are some general checklists for linking third-party libraries:
Runtime library: MT, MTd, MD, MDd, etc
Character set: Unicode or Multibyte
Target compiler
Target Machine
Subsystem
Whether the third-party library being used has additional dependencies, and you are properly linking the exact version of them.
These are checklists specific to POCO:
POCO version you are referring to in header files vs linker path
configurations.
OpenSSL version you are linking your project against, if you are
using SSL, Crypto and NET modules of POCO.
The same setup on my machine (but with VisualStudio 2019 configured for VisualStudio 2017 target) works just fine.
Odd.
When I returned to the office today, I wanted to look into this again to see if I could find out more about IntelliSense not finding POCO headers and about the odd dropping-characters thing in the error message, but it works now:
yes, I can once more jump to a POCO header file by moving my cursor to the #include line and hitting CTRL+SHIFT+G.
No idea if it was restarting VS that fixed this, or fixing the linker error -- which was trivial, BTW, and I might even have done at the side that while writing this question. Unfortunately I either didn't recheck for broken IntelliSense behaviour after the linker fix, or didn't bother recording that IntelliSense still was broken afterwards.
So: no real closure, I'm afraid.
EDIT: Ramesh Kambadaasan's answer suggests that a workaround might be to delete the IntelliSense DB file(s) and to restart VS to force a project re-parse. I'll try that next time.
In Windows you should use "\" as a directory seperator, not "/".
My guess is that VS replaces your "/" with "\", then the first letter of every word is an unescaped character.
Try to replace your "/" with "\\".
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)
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.
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.
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.
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.
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.
Can you elaborate on this? If I recall, there are at least two places in Visual Studio where you can configure this:
Per-installation: Tools/Options/Projects and Solutions/VC++ Directories)
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).
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.
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.
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.
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.
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.
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.
Sorry for what seems like a silly question: But I've never, ever worked with boost, until tonight, and I'm finding that getting it configured seems to be harder to use than it should be.
I wanted experiment with it tonight. So I downloaded the zip file, and unzipped it to a directory here:
F:/boost_1_44_0
Then I created an empty c++ project in visual studio 2010 (not using pch either). So all I wanted to do was to include a header file. But not even a silly thing like that seems to work. Now I've been using visual studio for years, though at work we are still stuck on vs 2008 (That is another story). So usually what you do is set an include directory, and then you can include files in at will right?
So I set the global include directory to include the boost root. i.e. Property Manager -> My configuration (debug|win32) -> Microsoft.Cpp.Win32.user -> Common Properties -> C++ Directories -> Include Directories. There I added my path to f:/boost_1_44_0.
I also went to the project properties and set the C++ include directory for the project to point to the boost root like in vs 2008.
I then added a silly include declaration like so:
#include <boost/lambda/lambda.hpp>
But, amazingly it fails to compile!!! with the following error:
Error 1 error C1083: Cannot open include file: 'boost/type_traits/transform_traits.hpp': No such file or directory f:\boost_1_44_0\boost\lambda\core.hpp 25 1 test_boost
Which when I double click it, it opens up in f:\boost_1_44_0\boost\lambda\core.hpp, and takes me to this line:
#include "boost/type_traits/transform_traits.hpp"
So I have no idea what's happening. Is visual studio just not delivering up my global include paths that I set? It seems also that the include directive in core.hpp should be using angle brackets and not quotes.
If I'm doing something wrong what?
EDIT:
!! SOLVED !!
Before I didn't have all the files unzipped. I don't know what happened. So I re-downloaded the zip file, and unzipped it again. This time the zip file took much longer to unzip, and it extracted much more files: Including the missing files.
Problem solved, my hello world app compiles just fine now.
The behaviour of compilers in locating header files is implementation defined for both the <> and "" variants.
However, based on this page for VC2010, it appears the quoted form searches a superset of the angle bracket form so I'm not sure that's the problem.
I suppose it would be a silly question to ask if the following file actually existed?
f:\boost_1_44_0\boost\type_traits\transform_traits.hpp
So, a couple of investigative jobs:
Make sure that f:\boost_1_44_0\boost\type_traits\transform_traits.hpp exists.
Try changing your top-level include to use quotes.
Try changing the include in f:\boost_1_44_0\boost\lambda\core.hpp to use angle brackets.
Make sure you try all four possibilities for those last two.
Is f: a network-mounted drive? What happens if you put it all on c:?
That last one is just in case Windows is doing some shenanigans under the covers :-)
While it's a bit overkill for this, learning to use SysInternals' Process Monitor will pay off over time. It will show you what files are actually opened, and which attempts failed. Look where Visual Studio tries to read transform_traits.hpp from, and you'll probably have the answer.
I'm having a problem compiling files in Visual Studio 2008 (Express edition).
I have two folders with an Entity.cpp file in them, they're both added to the solution but only the first is compiled.
If I change the name of either one of them it compiles correctly, but if both have the same name they're ignored. (Though changing included headers does make it try to recompile.. but it says no relevant changes are detected and linking errors still happen)
Thanks in advance!
The problem with Visual Studio is that Folders and Filters are not related.
You say that they are in different Folders (physically, on your disk), but are they in different Filters in your solution?
I don't remember having any problem of this kind, but I sure got kicked more than once because I had not put the file in the solution...
I'm trying to build a small VS 2005 solution I've just checked out of source control, and I'm getting this easy to understand error:
...\AssemblyInfo.cs' could not be
opened ('The system cannot find the
file specified. ') (The file is fairly
obviously missing)
Because this file's automatically generated, I've never paid it much heed before, and in VS 2003 (which I still work with day to day - pity me) it never seems to matter if it's missing.
So 2 questions:
1. How can I get VS 2005 to regenerate the file.
2. Could anyone explain to me in a couple of sentences what the assembly info file is all about, why it's generated, why it's a good idea to have an automatically generated file critical to my solution building etc etc.
Thanks - Andrew.
Edit: OK, I've googling some more, and it's probably significant that this is in an Nunit Test Project.
Update: Deleting the reference in solution explorer an Alex suggested did the trick, and the project now builds, but I'm not entirely happy with that as a solution. If the file is so unimportant, why is it generated in the first place? And if the file does perform a vital task, what am I missing out on by just deleting it?
Also, is it even possible to get it back? Either by getting VS to regenerate it, or by manually hacking one up (possibly using another as a template)?
This file contains assembly-wide settings like assembly version, name, etc. It is automatically generated when you change those settings using properties pages of the project. You should have this file in the project with sort of transparent icon (I think it is in resource folder or something like this by default). Locate it in the project tree and delete it. Visual studio will stop looking for it during build.
PS: assuming the path starts with .. and not ... then this file should be located one folder up from the project in the source control. So you can try looking there.