I want to remove some files from the project and the project browser.
I can exclude the files in Project->Project Options->Files by selecting the file and unchecking boxes ("Include in compilation" and "Include in linking").
That works for compiling, but I'd rather not see the files cluttering up the browser. How can I actually remove them from the project?
I tried deleting them from the project folder, then compiling, hoping I'd get a prompt asking me if I want to remove the files, but instead I got an error message.
I've right- and left-clicked (both single and double) every symbol in the project browser. The menu that comes up doesn't have a "delete" or "remove" option. I've checked every section and tab under Project.
I looked through the Dev C++ manual, and GCC documentation. I must have missed it. It must be possible to remove a file.
What am I missing?
Project->Remove From Project
This question provides good answers to the question of excluding files from indexing that are also excluded from a build. An open question remains: how does one prevent files that are part of the build from populating the code-completion or code-insight functions?
My use-case is a TrueSTUDIO (was System Workbench, was bare Eclipse) project which includes some modules from another project. They are wrapped in safe-to-use stubs and wrappers and should never be called directly. The external modules cannot be edited because they must stay in sync with the other project, so their filenames and other symbols clash confusingly with the current project's. When using code completion to include a header or complete a function name, the filenames and function names of the modules that are not to be used directly appear in the completion lists.
I wish to continue to include the modules in my builds, but not have any of their contents appear in the code-complete/insight features.
I see in Project Properties -> C/C++ General -> Indexer there are options to configure the indexer to use a different build configuration. This is promising, but will probably quickly lead to a indexer that is sorely out of sync with the primary build configuration.
Any advice on a practical method?
The only way I found to exclude files from Eclipse indexing is using the abovementioned Indexer-specific build configuration. In my case, it helped with the annoying problem of indexer freezing on .cu (NVidia CUDA) files.
This is how it works:
Prepare a new (Indexer-specific) build configuration.
Exclude unwanted source files from this configuration using the
Source Location exclude filter.
Let Indexer use this particular build configuration.
Eclipse configuration is a bit tricky with Indexer, so this is a step-by-step guide (as for Eclipse 2021-09):
Preparing a new build configuration:
Project->Build Configurations->Manage->New:
Give it a name, e.g., "4indexer".
Select "Copy settings from" with your preferred configuration. In my case, "Debug" worked just fine.
Excluding unwanted source files:
Project->Properties->Paths and Symbols->Source Location:
Select "4indexer" as the configuration to be managed on the top of the properties window.
Apply an exclusion pattern of your choice. In my case, I added "*.cu" at the end of the "Source Folder Exclusion Patterns" list by clicking Add... button and typing *.cu in the "Add Exclusion Pattern" text field.
Reconfiguring Indexer:
Window->Preferences->C/C++->Indexer:
Allow any Indexer to work with a project-specific build configuration (it was tricky to figure it out): check the "Use the build configuration specified in the project's indexer settings" radio button.
Project->Properties->C/C++ General->Indexer:
Check the "Enable project specific settings".
Select the new build configuration for your project Indexer: check the "Use a fixed build configuration" and select "4indexer" from the drop-down list below.
I also unchecked the "Index source files not included in the build", but I'm not sure if it is necessary.
Sometimes Indexer is trying to reindex a project as you try to reconfigure it, freezing Eclipse. So, I turned it on and off and restarted Eclipse a few times.
Is it possible to automatically read version data (major/minor/revision) from a resource script file (.rc) or an include file (.h) and add it to $(TargetName) / OUTPUT FILE property so that the resulting built executable contains the version info in its name?
The version data is incrementally generated at each build, so the build script will have to resolve the version contents and use it to name the output file.
You can use Property Macros. So if you were to bring up Property Manager (View > Property Manager) and right-click a configuration and choose Add New Property Sheet... then edit that property sheet by right-clicking on it and choosing properties. Then under Common Properties and then User Macros make a new macro with the Add Macro button.
Say you called it Version with value 1.0.0 then you can OK out of the dialogs and go to the project properties and for the Target Name have it be $(ProjectName)_$(Version) and build your project and that will work.
The property sheet is plain text so your automated script could edit this file on each build. You might need to delete a hidden file, the .suo file, if VS isn't picking up the changes from one build to the next.
Though if I may suggest a few other approaches.
Perhaps your build script could rename the output file?
Within VS you could have a post-build step that can read the version information from the executable and rename the file. Here is a function call that can be used to read the version information: http://msdn.microsoft.com/en-us/library/windows/desktop/ms647003%28v=vs.85%29.aspx It could be done all from a script instead.
Try CMake. CMake allows you to generate your VS solution and project files and can do some extraordinary things.
Hope that was helpful!
Changing the working directory inside the debugging project options dialog results in an entry added to the "Project User Options File". This file is not 'checked in' to our source control repository because it is supposed to be user specific. I need to change the default setting for the Debugging Working Directory option so users who check out this project don't have to continually change it before they can launch the debugger.
I had thought that moving that generated setting entry from the 'Project User Options File' to the 'Project File' would be sufficient. It does work - as in the default working directory changes - BUT then I can no longer debug the project from inside VS. When trying to run the debugger, all I get is a dialog box saying that VS is unable to start the debugger. (Looking at the debugging settings they seem fine and unchanged).
So what is the correct way to set a default debugging working directory for a VS project?
NOTE: The dialog box only appears if you 'MOVE' the setting entry from the User Options File to the Project File. If you just copy the entry - so that it is in both files - there is no problems running the debugger. Unfortunately this means, again, the user still has to add the setting manually.
I would create a post checkout script to manually add this line to the file.
if the file is not stored you can't go away of manually editing it before usage.
How many times the users are checking out your project? think about the amount of time you will spend on this activity versus the actual usage of 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':