8

I started working as a research fellow at my university and was instructed to develop a component for an already existing application written in C++ using an in-house framework, also developed in C++.

Currently I am struggling with properly setting up the project in Visual Studio 2017. Whenever I try to include a file from the framework, IntelliSense complains about not being able to open the file.

However, following things add to the oddness of the problem:

  • The solutions properties are set correctly; the project DOES build without any complaints.

  • Writing the '#include'-directive, IntelliSense DOES suggest the correct relative path to the header files (i.e. #include <framework/class.h>).

  • I can open the header file from within the source file referencing it, using the 'Open Document "class.h"' dialog.

I have already came across this:

So far, nothing solved my issue. Did someone come across this issue yet?

TL;DR

  • Everything compiles fine.
  • "C/C++ -> General -> Additional Include Directories" is set properly.
  • "VC++ Directories -> Include Directories" is set as well.
  • IntelliSense properly suggests header file, when writing include directive.
  • BUT IntelliSense reportedly fails to open the file, thus not indexing it.
  • I am stuck with a fancy but resource hungry text editor.

EDIT:

I am working on a MacBook "13 2016; installed Windows 10 Pro 64-bit via Bootcamp.

Julian Kirsch
  • 539
  • 4
  • 17
  • Are you setting the project properties for the currently active configuration and platform? Are there any error messages in the error list window? – Alan Birtles Dec 17 '18 at 15:16
  • Excuse the late reply. I made sure to configure it properly for each "flavor". What do you mean by "error messages in the error list window"? If it is the dialog, that lists all compilation errors, then no, no messages. The project compiles fine and as expected (i.e. correctly). – Julian Kirsch Dec 20 '18 at 09:53
  • Do you use Windows Subsystem for Linux? – yothsoggoth Jan 30 '19 at 22:15
  • On this particular device I do not use WSL. It's is a clean install of Windows 10 (via Bootcamp) and Visual Studio 2017 Community. – Julian Kirsch Jan 30 '19 at 22:29
  • 1
    I did have a similar issue (but if you don't use WSL it's potentially unrelated, hence not suggesting it as an answer). In my case, it was caused by case-sensitive folder names, which is apparantly now possible on Windows. Intellisense was trying to open C:\WORKSPACEPATH\PROJECTDIR\MYFILE.cpp (i.e. all uppercase) and was reporting the file didn't exist, because C:\WORKSPACEPATH was set as case sensitive and was actually C:\workspacepath. In my case it was because I created the folder via WSL. See [here](https://www.auslogics.com/en/articles/enable-case-sensitive-file-and-folder-names/) – yothsoggoth Jan 31 '19 at 19:05
  • @yothsoggoth, thank you for posting that, even though it wasn't his problem. That was exactly my problem! – cylus Mar 17 '19 at 21:12
  • @yothsoggoth It turns out: the tool I used to checkout the repository uses WSL under the hood; which got installed without me recognizing it. I was toying around with it and recognized that I suddenly had WSL installed. After using a different (non-proprietary) tool for that job, everything seems to work now. Additionally I tried to check it out directly via WSL, which leads to the strange behavior described above. It is indeed the WSL, which was bugging me. I suggest you post your comment as an answer :) – Julian Kirsch Apr 22 '19 at 12:24
  • @JulianKirsch done! Thanks for reporting back! – yothsoggoth Jun 07 '19 at 18:20

3 Answers3

5

This issue occurs because Windows now has the option for making folders case-sensitive and intellisense has a habit of changing the case of files that it tries to open.

Intellisense tries to use a path like C:\WORKSPACEPATH\PROJECTDIR\MYFILE.cpp (i.e. all uppercase), but if C:\workspace (or any of the other directories in the path) are set to be case-sensitive and don't exactly match, it won't be found.

In my case it was because I created the folder via WSL which enables case sensitivity by default on any new directories it creates (including via things like git clone). See here

Easy Fix

This can be fixed by running the following:

fsutil file setCaseSensitiveInfo <directory> disable

More Commands

You can check whether a folder has case sensitivity enabled by running

fsutil file queryCaseSensitiveInfo <directory>

and Finally, a handy one-liner to disable this recursively:

for /r /d %f in (.) do (fsutil file setCaseSensitiveInfo %f disable)

(This info was originally posted as a comment to the original question, before it turned out it was in fact the same problem. See the comments for input from a couple of other people)

yothsoggoth
  • 393
  • 3
  • 10
  • I will stress the "or any of the other directories in the path", as I couldn't get this working until I realized it's not only cloned project directories set to case sensitive, but also the directory the project was in. So if Intellisense doesn't see ALL-CAPS version of a file, check all parent folders up to the root. – stoper Dec 25 '19 at 13:07
  • 1
    Note, people seem to struggle with this even with Visual Studio Code: https://github.com/microsoft/vscode-cpptools/issues/1994, though in Visual Studio C++ I was getting error E1696 from Intellisense (with path given as ALL CAPS as mentioned in answer). – stoper Dec 25 '19 at 13:15
  • Need disable parent too. Ex `D:\A` `D:\A\B` .... `D:\A\B\C\D\E` – Trương Quốc Khánh Sep 17 '22 at 19:30
0

For a Linux project open in Visual Studio 2022, I tried the accepted answer from @yothsoggoth, , which makes sense to me, but unfortunately didn't work.
I realized that visual studio couldn't even open the C++ file from the standard library using F12 but it could open others from other libraries.
So in my case the solution was to close visual studio, backup the folder working as a cache. C:\Users\[user]\AppData\Local\Microsoft\Linux to C:\Users\[user]\AppData\Local\Microsoft\Linux.bak
Then I reopened Visual Studio and let CMake to regenerate the cache.
The errors now are gone and I can now even open <string> and others from the C++ std library with F12.
I hope this workaround helps others

dabinsi
  • 766
  • 6
  • 9
0

I had a similar problem with Visual Studio Code and its Intellisense C++ extension working in a cross-compile environment (using SysGCC).

The VS code IntelliSense plugin didn't find the source files. I had 'fsutil'-ed the 'C:\SysGCC...' and the checkout source directory to be 'case sensitive' (to avoid naming conflicts with Linux case-sensitive files). So, it may help to turn off the case-sensitiveness for your directories with the 'fsutils', too.

(According to VSCode-CppTools and the checkout to 'case sensitive', they have an option C_Cpp.caseSensitiveFileSupport for that, too.)

  • 1
    If you think this doesn't answer the question, please delete this. However, the last sentence does appear to contain an answer, or at least the start of one. If you could [edit] this post according to [answer], that'd be great! – Adriaan Feb 28 '23 at 12:35
  • I deleted that you consider this a comment. If you still do, please delete the post. I want to avoid giving the impression to others that posting comments as answers is OK. – Yunnosch Feb 28 '23 at 12:42