I have a very similar problem as described here.
I also upgraded a mixed solution of C++/CLI and C# projects from Visual Studio 2008 to Visual Studio 2010. And now in Visual Studio 2010 one C++/CLI project always runs out of date.
Even if it has been compiled and linked just before and F5 is hit, the messagebox "The project is out of date. Would you like to build it?" appears. This is very annoying because the DLL file is very low-tiered and forces almost all projects of the solution to rebuild.
My pdb settings are set to the default value (suggested solution of this problem).
Is it possible the get the reason why Visual Studio 2010 forces a rebuild or thinks a project is up to date?
Any other ideas why Visual Studio 2010 behaves like that?
For Visual Studio/Express 2010 only. See other (easier) answers for VS2012, VS2013, etc
To find the missing file(s), use info from the article Enable C++ project system logging to enable debug logging in Visual Studio and let it just tell you what's causing the rebuild:
Open the devenv.exe.config file (found in %ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE\ or in %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\). For Express versions the config file is named V*Express.exe.config.
Add the following after the </configSections> line:
<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>
Restart Visual Studio
Open up DbgView and make sure it's capturing debug output
Try to debug (hit F5 in Visual Studio)
Search the debug log for any lines of the form:
devenv.exe Information: 0 : Project 'Bla\Bla\Dummy.vcxproj' not up to date because build input 'Bla\Bla\SomeFile.h' is missing.
(I just hit Ctrl+F and searched for not up to date) These will be the references causing the project to be perpetually "out of date".
To correct this, either remove any references to the missing files from your project, or update the references to indicate their actual locations.
Note: If using 2012 or later then the snippet should be:
<system.diagnostics>
<switches>
<add name="CPS" value="Verbose" />
</switches>
</system.diagnostics>
In Visual Studio 2012 I was able to achieve the same result easier than in the accepted solution.
I changed the option in menu Tools → Options → Projects and Solutions → Build and Run → *MSBuild project build output verbosity" from Minimal to Diagnostic.
Then in the build output I found the same lines by searching for "not up to date":
Project 'blabla' is not up to date. Project item 'c:\foo\bar.xml' has 'Copy to Output Directory' attribute set to 'Copy always'.
This happened to me today. I was able to track down the cause: The project included a header file which no longer existed on disk.
Removing the file from the project solved the problem.
We also ran into this issue and found out how to resolve it.
The issue was as stated above "The file no longer exists on the disk."
This is not quite correct. The file does exist on the disk, but the .VCPROJ file is referencing the file somewhere else.
You can 'discover' this by going to the "include file view" and clicking on each include file in turn until you find the one that Visual Studio can not find. You then ADD that file (as an existing item) and delete the reference that can not be found and everything is OK.
A valid question is: How can Visual Studio even build if it does not know where the include files are?
We think the .vcproj file has some relative path to the offending file somewhere that it does not show in the Visual Studio GUI, and this accounts for why the project will actually build even though the tree-view of the includes is incorrect.
The accepted answer helped me on the right path to figuring out how to solve this problem for the screwed up project I had to start working with. However, I had to deal with a very large number of bad include headers. With the verbose debug output, removing one caused the IDE to freeze for 30 seconds while outputting debug spew, which made the process go very slowly.
I got impatient and wrote a quick-and-dirty Python script to check the (Visual Studio 2010) project files for me and output all the missing files at once, along with the filters they're located in. You can find it as a Gist here: https://gist.github.com/antiuniverse/3825678 (or this fork that supports relative paths)
Example:
D:\...> check_inc.py sdk/src/game/client/swarm_sdk_client.vcxproj
[Header Files]:
fx_cs_blood.h (cstrike\fx_cs_blood.h)
hud_radar.h (cstrike\hud_radar.h)
[Game Shared Header Files]:
basecsgrenade_projectile.h (..\shared\cstrike\basecsgrenade_projectile.h)
fx_cs_shared.h (..\shared\cstrike\fx_cs_shared.h)
weapon_flashbang.h (..\shared\cstrike\weapon_flashbang.h)
weapon_hegrenade.h (..\shared\cstrike\weapon_hegrenade.h)
weapon_ifmsteadycam.h (..\shared\weapon_ifmsteadycam.h)
[Source Files\Swarm\GameUI - Embedded\Base GameUI\Headers]:
basepaenl.h (swarm\gameui\basepaenl.h)
...
Source code:
#!/c/Python32/python.exe
import sys
import os
import os.path
import xml.etree.ElementTree as ET
ns = '{http://schemas.microsoft.com/developer/msbuild/2003}'
#Works with relative path also
projectFileName = sys.argv[1]
if not os.path.isabs(projectFileName):
projectFileName = os.path.join(os.getcwd(), projectFileName)
filterTree = ET.parse(projectFileName+".filters")
filterRoot = filterTree.getroot()
filterDict = dict()
missingDict = dict()
for inc in filterRoot.iter(ns+'ClInclude'):
incFileRel = inc.get('Include')
incFilter = inc.find(ns+'Filter')
if incFileRel != None and incFilter != None:
filterDict[incFileRel] = incFilter.text
if incFilter.text not in missingDict:
missingDict[incFilter.text] = []
projTree = ET.parse(projectFileName)
projRoot = projTree.getroot()
for inc in projRoot.iter(ns+'ClInclude'):
incFileRel = inc.get('Include')
if incFileRel != None:
incFile = os.path.abspath(os.path.join(os.path.dirname(projectFileName), incFileRel))
if not os.path.exists(incFile):
missingDict[filterDict[incFileRel]].append(incFileRel)
for (missingGroup, missingList) in missingDict.items():
if len(missingList) > 0:
print("["+missingGroup+"]:")
for missing in missingList:
print(" " + os.path.basename(missing) + " (" + missing + ")")
I've deleted a cpp and some header files from the solution (and from the disk) but still had the problem.
Thing is, every file the compiler uses goes in a *.tlog file in your temp directory.
When you remove a file, this *.tlog file is not updated. That's the file used by incremental builds to check if your project is up to date.
Either edit this .tlog file manually or clean your project and rebuild.
I had a similar problem, but in my case there were no files missing, there was an error in how the pdb output file was defined: I forgot the suffix .pdb (I found out with the debug logging trick).
To solve the problem I changed, in the vxproj file, the following line:
<ProgramDataBaseFileName>MyName</ProgramDataBaseFileName>
to
<ProgramDataBaseFileName>MyName.pdb</ProgramDataBaseFileName>
I had this problem in VS2013 (Update 5) and there can be two reasons for that, both of which you can find by enabling "Detailed" build output under "Tools"->"Projects and Solutions"->"Build and Run".
"Forcing recompile of all source files due to missing PDB "..."
This happens when you disable debug information output in your compiler options (Under Project settings: „C/C++“->“Debug Information Format“ to „None“ and „Linker“->“Generate Debug Info“ to „No“: ). If you have left „C/C++“->“Program Database File Name“ at the default (which is „$(IntDir)vc$(PlatformToolsetVersion).pdb“), VS will not find the file due to a bug (https://connect.microsoft.com/VisualStudio/feedback/details/833494/project-with-debug-information-disabled-always-rebuilds).
To fix it, simply clear the file name to "" (empty field).
"Forcing rebuild of all source files due to a change in the command line since the last build."
This seems to be a known VS bug too (https://connect.microsoft.com/VisualStudio/feedback/details/833943/forcing-rebuild-of-all-source-files-due-to-a-change-in-the-command-line-since-the-last-build) and seems to be fixed in newer versions (but not VS2013). I known of no workaround, but if you do, by all means, post it here.
I don't know if anyone else has this same problem, but my project's properties had "Configuration Properties" -> C/C++ -> "Debug Information Format" set to "None", and when I switched it back to the default "Program Database (/Zi)", that stopped the project from recompiling every time.
Another simple solution referenced by Visual Studio Forum.
Changing configuration: menu Tools → Options → Projects and Solutions → VC++ Project Settings → Solution Explorer Mode to Show all files.
Then you can see all files in Solution Explorer.
Find the files marked by the yellow icon and remove them from the project.
It's OK.
Visual Studio 2013 -- "Forcing recompile of all source files due to missing PDB". I turned on detailed build output to locate the issue: I enabled "Detailed" build output under "Tools" → "Projects and Solutions" → "Build and Run".
I had several projects, all C++, I set the option for under project settings: (C/C++ → Debug Information Format) to Program Database (/Zi) for the problem project. However, this did not stop the problem for that project. The problem came from one of the other C++ projects in the solution.
I set all C++ projects to "Program Database (/Zi)". This fixed the problem.
Again, the project reporting the problem was not the problem project. Try setting all projects to "Program Database (/Zi)" to fix the problem.
I met this problem today, however it was a bit different. I had a CUDA DLL project in my solution. Compiling in a clean solution was OK, but otherwise it failed and the compiler always treated the CUDA DLL project as not up to date.
I tried the solution from this post.
But there is no missing header file in my solution. Then I found out the reason in my case.
I have changed the project's Intermediate Directory before, although it didn't cause trouble. And now when I changed the CUDA DLL Project's Intermediate Directory back to $(Configuration)\, everything works right again.
I guess there is some minor problem between CUDA Build Customization and non-default Intermediate Directory.
I had similar problem and followed the above instructions (the accepted answer) to locate the missing files, but not without scratching my head. Here is my summary of what I did. To be accurate these are not missing files since they are not required by the project to build (at least in my case), but they are references to files that don't exist on disk which are not really required.
Here is my story:
Under Windows 7 the file is located at %ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE\%. There are two similar files devenv.exe.config.config and devenv.exe.config. You want to change later one.
Under Windows 7, you don't have permission to edit this file being in program files. Just copy it somewhere else (desktop) change it and than copy it back to the program files location.
I was trying to figure out how to connect DebugView to the IDE to see the missing files. Well, you don't have to do anything. Just run it, and it will capture all the messages. Make sure Capture Events menu option is selected in Capture menu which by default should be selected.
DebugView will NOT display all the missing files at once (at least it didn't for me)! You would have DebugView running and than run the project in Visual Studio 2010. It will prompt the project out of date message, select Yes to build and DebugView will show the first file that is missing or causing the rebuild. Open the project file (not solution file) in Notepad and search for that file and delete it. You are better off closing your project and reopening it again while doing this delete. Repeat this process until DebugView no longer shows any files missing.
It's kind of helpful to set the message filter to not up to date from the DebugView toolbar button or Edit → Filter/Highlight option. That way the only messages it displays are the one that has `not up to date' string in it.
I had lots of files that were unnecessary references and removing them all fixed the issue following the above steps.
Second way to find all the missing files at once
There is a second way to find these files all at once, but it involves (a) source control and (b) integration of it with Visual Studio 2010. Using Visual Studio 2010, add your project to a desired location or dummy location in source control. It will try to add all the files, including those that don't exist on disk as well but referenced in the project file. Go to your source control software like Perforce, and it should mark these files which don't exist on disk in a different color scheme. Perforce shows them with a black lock on them. These are your missing references. Now you have a list of them all, and you can delete all of them from your project file using Notepad and your project would not complain about being out of date.
For me it was the presence of a non-existing header file on "Header Files" inside the project. After removing this entry (right-click > Exclude from Project) first time recompiled, then directly
========== Build: 0 succeeded, 0 failed, 5 up-to-date, 0 skipped ==========
and no attempt of rebuilding without modification was done. I think is a check-before-build implemented by VS2010 (not sure if documented, could be) which triggers the "AlwaysCreate" flag.
If you are using the command-line MSBuild command (not the Visual Studio IDE), for example if you are targetting AppVeyor or you just prefer the command line, you can add this option to your MSBuild command line:
/fileLoggerParameters:LogFile=MyLog.log;Append;Verbosity=diagnostic;Encoding=UTF-8
As documented here (warning: usual MSDN verbosity). When the build finishes, search for the string will be compiled in the log file created during the build, MyLog.log.
I'm using Visual Studio 2013 Professional with Update 4 but didn't find resolution with any of the other suggestions, however, I did manage to resolve the issue for my Team project.
Here's what I did to cause the problem -
Created a new class object (Project -> Add Class)
Renamed the file via Solution Explorer and clicked yes when asked if I wanted to automatically rename all references to match
Here's what I did to solve the problem -
Go to Team Explorer Home
Click Source Control Explorer
Drill into the folder where all of the class/project files are
Found the ORIGINAL filename in the list and deleted it via right-click
Build
If this is the case for you then just be extra sure that you're deleting the phantom file rather than the actual one you want to keep in the project.
I had this problem and found this:
http://curlybrace.blogspot.com/2005/11/visual-c-project-continually-out-of.html
Visual C++ Project continually out-of-date (winwlm.h macwin32.h rpcerr.h macname1.h missing)
Problem:
In Visual C++ .Net 2003, one of my projects always claimed to be out of date, even though nothing had changed and no errors had been reported in the last build.
Opening the BuildLog.htm file for the corresponding project showed a list of PRJ0041 errors for these files, none of which appear on my system anywhere:
winwlm.h macwin32.h rpcerr.h macname1.h
Each error looks something like this:
MyApplication : warning PRJ0041 : Cannot find missing dependency 'macwin32.h' for file 'MyApplication.rc'.
Your project may still build, but may continue to appear out of date until this file is found.
Solution:
Include afxres.h instead of resource.h inside the project's .rc file.
The project's .rc file contained "#include resource.h". Since the resource compiler does not honor preprocessor #ifdef blocks, it will tear through and try to find include files it should be ignoring. Windows.h contains many such blocks. Including afxres.h instead fixed the PRJ0041 warnings and eliminated the "Project is out-of-date" error dialog.
In my case one of the projects contains multiple IDL files. The MIDL compiler generates a DLL data file called 'dlldata.c' for each of them, regardless of the IDL file name. This caused Visual Studio to compile the IDL files on every build, even without changes to any of the IDL files.
The workaround is to configure a unique output file for each IDL file (the MIDL compiler always generates such a file, even if the /dlldata switch is omitted):
Right-click the IDL file
Select Properties - MIDL - Output
Enter a unique file name for the DllData File property
I spent many hours spent tearing out my hair over this. The build output wasn't consistent; different projects would be "not up to date" for different reasons from one build to the next consecutive build.
I eventually found that the culprit was DropBox (3.0.4). I junction my source folder from ...\DropBox into my projects folder (not sure if this is the reason), but DropBox somehow "touches" files during a build. Paused syncing and everything is consistently up-to-date.
There are quite a few potential reasons and - as noted - you need to first diagnose them by setting MSBuild verbosity to 'Diagnostic'. Most of the time the stated reason would be self explanatory and you'd be able to act on it immediatelly, BUT occasionally MSBuild would erroneously claim that some files are modified and need to be copied.
If that is the case, you'd need to either disable NTFS tunneling or duplicate your output folder to a new location. Here it is in more words.
This happened to me multiple times and then went away, before I could figure out why. In my case it was:
Wrong system time in the dual boot setup!
Turns out, my dual boot with Ubuntu was the root cause!! I've been too lazy to fix up Ubuntu to stop messing with my hardware clock. When I log into Ubuntu, the time jumps 5 hours forward.
Out of bad luck, I built the project once, with the wrong system time, then corrected the time. As a result, all the build files had wrong timestamps, and VS would think they are all out of date and would rebuild the project.
Most build systems use data time stamps to determine when rebuilds should happen - the date/time stamp of any output files is checked against the last modified time of the dependencies - if any of the dependencies are fresher, then the target is rebuilt.
This can cause problems if any of the dependencies somehow get an invalid data time stamp as it's difficult for the time stamp of any build output to ever exceed the timestamp of a file supposedly created in the future :P
For me, the problem arose in a WPF project where some files had their 'Build Action' property set to 'Resource' and their 'Copy to Output Directory' set to 'Copy if newer'. The solution seemed to be to change the 'Copy to Output Directory' property to 'Do not copy'.
msbuild knows not to copy 'Resource' files to the output - but still triggers a build if they're not there. Maybe that could be considered a bug?
It's hugely helpful with the answers here hinting how to get msbuild to spill the beans on why it keeps building everything!
If you change the Debugging Command arguments for the project, this will also trigger the project needs to be rebuilt message. Even though the target itself is not affected by the Debugging arguments, the project properties have changed. If you do rebuild though, the message should disappear.
I had a similar issue with Visual Studio 2005, and my solution consisted of five projects in the following dependency (first built at top):
Video_Codec depends on nothing
Generic_Graphics depends on Video_Codec
SpecificAPI_Graphics depends on Generic_Graphics
Engine depends on Specific_Graphics
Application depends on Engine.
I was finding that the Video_Codec project wanted a full build even after a full clean then rebuild of the solution.
I fixed this by ensuring the pdb output file of both the C/C++ and linker matched the location used by the other working projects. I also switched RTTI on.
Another one on Visual Studio 2015 SP3, but I have encountered a similar issue on Visual Studio 2013 a few years back.
My issue was that somehow a wrong cpp file was used for precompiled headers (so I had two cpp files that created the precompiled headers). Now why did Visual Studio change the flags on the wrong cpp to 'create precompiled headers' without my request I have no clue, but it did happen... maybe some plugin or something???
Anyway, the wrong cpp file includes the version.h file which is changed on every build. So Visual Studio rebuilds all headers and because of that the whole project.
Well, now it's back to normal behavior.
I had a VC++ project that was always compiling all files and had been previously upgraded from VS2005 to VS2010 (by other people). I found that all cpp files in the project except StdAfx.cpp were set to Create (/Yc) the precompiled header. I changed this so that only StdAfx.cpp was set to create the precompiled header and the rest were set to Use (/Yu) the precompiled header and this fixed the problem for me.
I'm on Visual Studio 2013 and just updated to the Windows 10 May 2019 update and compiling suddenly had to be redone every time, regardless of changes. Tried renaming the pch to ProjectName instead of TargetName, looked for missing files with the detailed log and that Python script, but in the end it was my time was not synced with MS's servers (by like milliseconds).
What resolved this for me was
"Adjust date and time" in the control panel
"Sync Now"
Now my projects don't need to be recompiled for no reason.
I think that you placed some newline or other whitespace. Remove it and press F5 again.
The .NET projects are always recompiled regardless. Part of this is to keep the IDE up to date (such as IntelliSense). I remember asking this question on an Microsoft forum years ago, and this was the answer I was given.
For a class at the university, the professor has provided us with some skeleton code that we are to modify. When I attempt to compile the code in Visual C++ 2010 Express (x86), I receive the following error:
C:\Users\[username]\AppData\Local\Temp\.NETFramework,Version=v4.0.AssemblyAttributes.cpp : fatal error C1083: Cannot open compiler generated file: 'Release\.NETFramework,Version=v4.0.AssemblyAttributes.obj': Permission denied
The account I am logged into has full read-write-modify permissions for the file in question, and I am using Windows 7 (x64). To make matters more confusing, the project compiles in Debug mode, but not in Release mode, which the professor instructed us to use.
Thank you in advance for any help.
So it turns out that the solution to this was simply to delete the .suo file in the project folder and rebuild the project. Why that worked, I don't know, but it seemed to do so.
This may not be a permission issue at all but may be a file lock issue. I believe this can happen, if you are:
Building the entire solution
Building in parallel
Not properly defining project dependencies
What happens is one project is writing to the object while another project is attempting to read that object and cannot because the write lock prevents it.
Please correct me if I am wrong.
I never had this specific error but as a general rule, I found that Visual Studio has a lot of issues with security. I can't register COM assemblies on my version for example... For that reason, I always run Visual Studio as Administrator (having an admin account is not enough, you want the shortcut to start as admin). This solves my COM issue and others I've encountered over the years. A long shot, but I hope that helps.
Visual Studio is a bit borked when it comes to generated file access rights on Windows 7 & Vista.
First, try running Visual Studio Express as an administrator, by right-clicking on its shortcut and selecting the yellow-blue shield option.
If that doesn't help, disable User Access Control altogether (you should be able to do that with an administrator account).
I have a solution with multiple projects which I inherited from previous developers. I also have this problem and I finally found out where it comes from, so maybe this is also what happens in the posters case as well.
In my project setup, there are lots of source files which are referenced in the project. When Visual Studio determines the build order, it builds projects, which are independent of each other, in parallel. So it can happen that a file which is compiled in two separate projects is built at the same time, which can cause the lock to happen.
In my opinion, referencing files in a project is evil. :) The proper way would be, to put shared files in a library and then set the dependencies accordingly. Theoretically one can resolve this issue as well, by setting the build dependencies for projects sharing files, but that is IMO arbitrary, because the projects may not have a meaningfull dependency (as it is in my case) they just happen to reuse the same code.
In my case I can sometimes build the whole solution without a problem and sometimes I have to restart it several times.
Another reason this can happen is, when the settings are such that some (intermediate) files are generated into the same folder, so the settings should be reviewed as well.
If your project compiles fine in one mode and not the other (e.g. Win32 vs x64, Debug vs Release), you should carefully compare build settings, especially Include Directories.
VS will misleadingly throw an "access denied" error instead of "file not found" if your build path contains for example a reference to D: drive which happens to be a DVD-RW drive with no disk inside.
Open Project's Properties > VC++ Directories > Include Directories, select "Configuration: All Configurations" and/or "Platform: All Platforms", if you then see <different options> then check carefully what the differences are. Or simply copy the Include Directories from a working configuration to the broken one.
Then repeat with Project's Properties > C/C++ > Additional Include Directories.
I had faced the same issue "Fatal Error: Permission Denied" with Visual Studio C++ 2017 under Windows 10.
The sollution was as mention above: To run Visual Studio as Administrator.
The permission error occurred for me when using cl.exe with the /Fo flag. Removing the file output option resolved it.
I created an empty 'Demo' project in Visual Studio 2008 and added some existing projects to my solution. Included "MyHeader.h" (other project's header) in main.cpp file which is in 'Demo'. Also added header files' path in "Tools/Option/VC++ Directories/Include files" section. But intellisense says: "File MyHeader.h not found in current source file's directory or in build system paths..."
How the problem can be fixed?
Delete the .sdf file that is in your solution directory. It's just the Intellisense database, and Visual Studio will recreate it the next time you open that solution. This db can get corrupted and cause the IDE to not be able to find things, and since the compiler generates this information for itself on the fly, it wouldn't be affected.
If you choose Project and then All Files in the menu, all files should be displayed in the Solution Explorer that are physically in your project map, but not (yet) included in your project. If you right click on the file you want to add in the Solution Explorer, you can include it.
This happened to me just now, after shutting down and restarting the computer. Eventually I realised that the architecture had somehow been changed to ARM from x64.
In Visual Studio 2019 in my case I copied a header file into the project directory, just near the other files. Intellisense could see it, but the build failed. Fair enough, it wasn't actually added to the project. I added it as existing item but this is the point that Visual Studio still didn't account for it.
Solution:
Close the project.
Delete the .vs directory.
Reopen the project.
Now Visual Studio recreates the directory with everything in it and it can now see the included file.
If it is the case that only the IDE indicates that it cannot find included files, but compiling is successful, the issue is simply that IntelliSense is not fully up to date with recent changes. This can happen specifically when including existing projects, in my own experience.
Deleting the .sdf file (= IntelliSense database) that is generated in your solution directory forces Visual Studio to regenerate it, so that it is up to date again. Just doing a "clean" will probably do the same thing, but takes more time since everything will be generated again then.
I know this is an older question, but none of the above answers worked for me. In my case, the issue turned out to be that I had absolute include paths but without drive letters. Compilation was fine, but Visual Studio couldn't find an include file when I right-clicked and tried to open it. Adding the drive letters to my include paths corrected the problem.
I would never recommend hard-coding drive letters in any aspect of your project files; either use relative paths, macros, environment variables, or some mix of the tree for any permanent situation. However, in this case, I'm working in some temporary projects where absolute paths were necessary in the short term. Not being able to right-click to open the files was extremely frustrating, and hopefully this will help others.
Had the same problem. Double check if you added the include files to Debug or Release Version of your project. If you only added it for one of them and compile for the other VS will just play dumb and not find them.
Try adding the header file to your project's files. (right click on project -> add existing file).
In my experience, with VS2010, when include files can't be found at compile time, doing a clean, then build usually fixes the problem. It's not that rare for the editor to be able to open an include file and then the compiler to announce that it can't find that very file, even when it is open on the screen!
If the visual studio says that you miss some file in the current source file folder, there is one solution that i used. Just right click the file you want to add and choose Open Document, if it really doesn't exist, then you should see something like cannot find file in the source file path = "somewhere in your computer", then what you could do is the add your source file into that path first and see if it works.
I had this issue after upgrading to Visual Studio 2019 from 2015. It would compile the project fine but Intellisense and the IDE couldn't find any header files.
The project only had valid configuration for Win32/Debug. Include paths were not setup correctly for other environments. Even though Visual Studio displayed the current environment as Win32/Debug, Intellisense must have been using something else.
Changing the current environment to x64/Release, and then back to Win32/Debug fixed it.
In Visual Studio, click on Project > Rescan Solution as shown below to rebuild the project database.
Here's how I solved this problem.
Go to Project --> Show All Files.
Right click all the files in Solutions Explorer and Click on Include in Project in all the files you want to include.
Done :)
I encountered this issue, but the solutions provided didn't directly help me, so I'm sharing how I got myself into a similar situation and temporarily resolved it.
I created a new project within an existing solution and copy & pasted the Header and CPP file from another project within that solution that I needed to include in my new project through the IDE. Intellisense displayed an error suggesting it could not resolve the reference to the header file and compiling the code failed with the same error too.
After reading the posts here, I checked the project folder with Windows File Explorer and only the main.cpp file was found. For some reason, my copy and paste of the header file and CPP file were just a reference? (I assume) and did not physically copy the file into the new project file.
I deleted the files from the Project view within Visual Studio and I used File Explorer to copy the files that I needed to the project folder/directory. I then referenced the other solutions posted here to "include files in project" by showing all files and this resolved the problem.
It boiled down to the files not being physically in the Project folder/directory even though they were shown correctly within the IDE.
Please Note I understand duplicating code is not best practice and my situation is purely a learning/hobby project. It's probably in my best interest and anyone else who ended up in a similar situation to use the IDE/project/Solution setup correctly when reusing code from other projects - I'm still learning and I'll figure this out one day!
If some soul has scrolled down to this bottom, what worked for me was disabling the Disable Database option i.e. set it to False under Tools|Options|Text Editor|C/C++|Advanced. For some reason, it was set to True for me.
As per docs, if it's set to True
All use of the code browsing database (SDF), all other
Browsing/Navigation options, and all IntelliSense features except for
#include Auto Complete are disabled.
None of the solutions worked for me. Here is what was the issue for me:
(Note discrepancy in build configuration and VC++ Directories (x86 vs x64)
To fix, just changed the build configuration to 'x86':