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 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.
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.
I'm working on a medium-sized project which uses qmake to generate Visual Studio 2005 project files. I'm trying to get it built under Visual Studio 2010 Ultimate. Since qmake doesn't support this IDE yet i had the provided conversion assistant convert my solution.
When trying to build I get the following error in one of the subprojects:
CVTRES : fatal error CVT1100: duplicate resource. type:VERSION,name:1,language:0x0407
After what Google's results told me it seems that this error is likely to occur when migrating to a newer version of Visual Studio but I don't know why and the hacks recommended there don't work for me.
What I already tried is to rename the ressources to random numbers, even a different "name" at every occurence of the version information.
When I build the project again after reading the error and deleting the corresponding .RC-file it works once. But that's too much of a hack.
Any ideas anyone?
Thanks in advance.
I resolved that problem when moving from VC++ 2010 to 2012 by changing the setting under Configuration Properties>Manifest Tool>Input and Output>Embed Manifest to NO. I have no idea what that is all about, but I looked at the contents of the .manifest file, and it sure looks like I can live without it being embedded.
I recently solved the similar problem with Qt 4.8.2 and Visual Studio 2012. Qt 4.8.2 does not support VS2012 as mkspec, so I copied win32-msvc2010 mkspec to win32-msvc2012 (changing _MSC_VER to 1700) and used some other workarounds (QtWebKit fix, etc. — you can find them over the internet) to build Qt 4.8.2 with VS2012. But qmake was not aware of VS2012 .vcxproj project files, so it continued to generate VS2010 projects. After conversion of these project files to the new 2012 format in the VS the above error arose.
The solution was to exclude generated .res files from build in all configurations (both Debug and Release). To do this, open 'Generated Files' folder in Solution Explorer, right click the .res file, open Properties, select 'All Configurations' from drop-down list and set 'Excluded From Build' property of 'General' section to 'Yes'.
It is quite tedious to repeat these actions by hands every time, so I wrote Python script to automate this. You can use it (at your own risk!) to update qmake-generated .vcxproj files.
import sys
import os
from xml.etree import ElementTree
def updateProject(filename):
def getXmlns(tag):
return tag[1:].split('}')[0]
tree = ElementTree.parse(filename)
root = tree.getroot()
xmlns = getXmlns(root.tag)
for cb in root.iter('{' + xmlns + '}CustomBuild'):
if(not 'Include' in cb.attrib):
continue
if(not cb.attrib['Include'].endswith('.res')):
continue
for excl in cb.iter('{' + xmlns + '}ExcludedFromBuild'):
if('Condition' in excl.attrib):
del excl.attrib['Condition'] # delete ExcludedFromBuild condition
ElementTree.register_namespace('', xmlns)
tree.write(filename)
if(len(sys.argv)>=2): # use project files specified in command line:
for i in range(1, len(sys.argv)):
updateProject(sys.argv[i])
else: # update all project files in current directory:
for filename in os.listdir(os.getcwd()):
if(filename.endswith('.vcxproj')):
updateProject(filename)
Thanks to Xandy for pointing out that you'll need to pass working directory to listdir() for script to work in Python 2.
If you ever encounter this error while compiling (usually a downloaded project from internet), then remove the manifest file and remove the reference to the manifest file in the .rc file.
Reference
I recently ran into this problem, and by accident ended up with a project file that didn't have the resource conflict. In my case I was importing a QT qmake generated project for VS2008 into VS2010. After using VcprojFormatter and a lot of diffs, I found the difference (for me). I think it is a bug in either the import wizard, or the core of VS 2010.
http://www.codeproject.com/KB/macros/vcproj_formatter.aspx
My resource file was called win32_resources.rc You'll need to edit each intermediate data folder corresponding to your build configurations (release, debug, etc)
Look for a section like the following in your vcxproj file:
<ItemGroup>
<Resource Include="debug\win32_resources.res">
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">true</ExcludedFromBuild>
</Resource>
<Resource Include="release\win32_resources.res">
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">true</ExcludedFromBuild>
</Resource>
</ItemGroup>
All the "Resource" text should be replaced with "CustomBuildStep":
<ItemGroup>
<CustomBuildStep Include="debug\win32_resources.res">
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Release|Win32'">true</ExcludedFromBuild>
</CustomBuildStep>
<CustomBuildStep Include="release\win32_resources.res">
<ExcludedFromBuild Condition="'$(Configuration)|$(Platform)'=='Debug|Win32'">true</ExcludedFromBuild>
</CustomBuildStep>
</ItemGroup>
The problem in the VS2008 file is that the default(?) setting was not explicit:
<File RelativePath="release\win32_resources.res">
<FileConfiguration
Name="Debug|Win32"
ExcludedFromBuild="true"
>
<Tool Name="VCCustomBuildTool"/>
</FileConfiguration>
</File>
The "Tool Name" field was missing.
If you ever encounter this error while compiling (usually a downloaded
project from internet), then remove the manifest file and remove the
reference to the manifest file in the .rc file.
This answer by hB0 was 100% correct for the case I encountered.
This was very useful to me and I would like others to benefit from knowing this, rather than assuming hB0's answer should be ignored because others have votes and hB0's has zero votes. I have to say it in a separate answer because I the system will not let an unregistered user vote. I even registered so as to be able to vote on this answer but the system still will not let me vote till I am a more mature user.
This is a stretch, but I had a similar problem under Visual Studio 2005. It might help, or be totally off base:
I was linking with a static library (.lib) that has its own version resource - very reasonable, it shows the library's version. On some stations, my app would link. On other stations, I'd get the same duplicate resource message you got.
It turned out to be related to a linker optimization setting: "Use Library Dependency Inputs" (UseLibraryDependencyInputs=), possibly combined with "Link Library Dependencies". When "Use Library Dependency Inputs" was enabled, the linker was being fed the .obj and .res files that were used to build the .lib, instead of just searching the .lib.
The problem is that you don't want the .lib's .res file as an input file to the linker. My project has its own version resource. If you bring in the .lib's resources, you now have two version resources, hence the error. If the linker simply searches the .lib, it has no reason to bring in the .lib's resource, and all is well.
My project's configuration didn't force the setting of "Use Library Dependency Inputs", it inherited it. On some stations, it inherited "No", and I could link. On some stations, it inherited "Yes", and we got the error.
If Visual Studio 2010 still has this setting, try forcing it off.
I had this problem and it was resolved by ensuring any included .rc files were excluded from the build, except the main .rc that was #including the rest.
I had this problem and it was resolved by ensuring any included .rc files were excluded from the build, except the main .rc that was #including the rest.
by Richard Hein worked for me. I was compiling with VS2013.
I had similar problem in Visual Studio C++ 2010. I did not installed any Service packs or updates of VS and this problem arises when I had two rc files which tried to use ICONs. So I just taken content of one file and cut it into the main file. So only one file contains the ICONS and the second file is empty. Works like sharm :-).
Replace else block in Dmitry Markin answer to recursively update all project files
else: # recursively update all project files in current directory:
rootdir = os.getcwd()
for root, subFolders, files in os.walk(rootdir):
for filename in files:
if(filename.endswith('.vcxproj')):
filePath = os.path.join(root, filename)
print "file: %s" % (filePath)
updateProject(filePath)
I came here looking for an answer for this error. I am sorry to burst the bubble. None of the answers worked out for me.
My mistake was I had defined 3 MACRO's with same id. That is the reason I was getting the error mentioned in the question.
my code before when the error was showing:
#define IDB_MARKER_NORMAL_LINE 21**6**
#define IDB_MARKER_ARROW_LINE 21**6**
#define IDB_MARKER_DOTTED_LINE 21**6**
i changed it to:
#define IDB_MARKER_NORMAL_LINE 21**6**
#define IDB_MARKER_ARROW_LINE 21**7**
#define IDB_MARKER_DOTTED_LINE 21**8**
Errors were GONE!!!!!!!!!!
I had this and I did the following in resource.h
#undef VS_VERSION_INFO
#define VS_VERSION_INFO 310
As VS_VERSION_INFO is given resource id 1 in WinRes.h just making it something else fixed my issue.
If you ever encounter this error while compiling (usually a downloaded project from internet), then remove the manifest file and
remove the reference to the manifest file in the .rc file.
This answer by hB0 was 100% correct for the case I encountered.
This was very useful to me and I would like others to benefit from
knowing this, rather than assuming hB0's answer should be ignored
because others have votes and hB0's has zero votes. I have to say it
in a separate answer because I the system will not let an unregistered
user vote. I even registered so as to be able to vote on this answer
but the system still will not let me vote till I am a more mature
user.
This answer point a way to find the problem that I encounted. In my senario, the import props has this code:
<ResourceCompile Include="$(VersioningDir)**Version.rc" />
When I delete it, all work is done.
If you ever encounters CVT1100 (duplicate resource) & LNK1123 (failure during conversion to COFF) resource errors in Visual Studio 20XX, then do below steps to resolve it.
Open .rc file & comment / remove below MACRO
MOVEABLE PURE "res\.manifest"
2 Rename / Delete Manifest file from Resource folder from Project directory.
Now Re-build the solution & Enjoy...
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.