MSVC handling lot of Include Paths - c++

old time computer programmer having a new problem :-)
I'm moving a CMake file project over to Visual Studio and there are hundreds of include paths in the CMake project.
I can of course patch them in once and for all but this is going to happen often and on different machines where CMake have to be run again, using different parameters like library locations, also by different people so I'd like to have a neat way to treat this.
So my question is, can you in some way, paste those paths in a text file and add that to a visual studio project?
Any help greatly appreciated!

The Visual Studio build files are XML, so it's almost-text.
What I'd do is create a single property sheet (.vsprops) inside Visual Studio, add it to your existing project(s), and then add two include directories to the .vsprops file. Close Visual Studio, open the .vsprops file in a text editor, check how the two paths are represented, and then add the several hundred paths in the same format.
Two remarks: Did you try the CMake MSVC generator? It might be able to do this for you. Secondly, have you considered this as a good moment to clean up the mess? Your builds will be slowed down quite a bit by the need to look up every header in hundreds of directories.

So it seems it can't be done. As MSalters pointed out, most project files are in xml format so you have to update those manually.
I use MSVC 2012 (version 11.0.6...) so I opened the .vcxproj file in notepad++ and pasted the path accordingly in the tags of the concerned build variants for example "Debug|x64" and Release|x64".

Related

Visual Studio 2015 C++ solution can't see svn exe in system PATH

Our team has two separate Visual Studio 2015 C++ projects, which are very similar in terms of project layout, Pre-Build Events etc.
In the Pre-Build Events of the startup project in each solution, an attempt is made to call an exe (svn) in the system PATH.
In solution 1, this works fine, and can execute the svn command.
In solution 2 however, it can't see svn on the PATH.
I've checked and found the following:
the Pre-Build Event is identical in each solution
i've compared the .vcxproj files for each Solution and there's nothing apparent
the full path to the VS Solution that works is longer than the one that doesn't work (so no max file path length issues)
there are no spaces in the full path names
So my question is, why might one Visual Studio solution be able to see an exe on the PATH, while another with similar layout, can't?
Thanks
#Lightness Races in Orbit was correct - I had missed something.
My vcxproj files had different entries for the Project that could see SVN compared to the Project that couldn't see it.
The culprit was the ExecutablePath Property.
Copying the entry from the vcxproj file for the working Project to the non-working Project allowed the latter to finally find SVN in the PATH.

visual studio not seeing my include files

This may be a very simple question but I haven't been able to figure it out so any help is appreciated.
I have a header that is located in a general folder because I want to use it in several projects for example:
C:\user\geninclude\program\header.h
I created a new empty project with a very simple main, in the main I put
#include <program/header.h>
I then went to the project properties and in VC++ in include directories added C:\user\geninclude\
but when I tried to build the program the program tells me it cannot find header.h because is not in the current directory or in the build system path.
I also tried in the project properties in C/C++ general Additional Include Directories adding C:\user\geninclude\ but still the same error.
I know is something simple I am missing, but I don't know what, I am very new to this just learning.
For reference I am using Visual Studio 2013.
Thank you in advance for your help.
UPDATE: Thank you all for your kind responses, I have tried everything you have told me (check release vs debug in both instances, change / for \ and <> for "", and double checking the header and still the system does not see it. It really is very weird. I'll keep trying...
Please check if your file is really an header file otherwise it won't appear on include.
What you can also do (as a workaround if you need that method fast) is to put your header file (or folder with header files) on the visual studio "include" folder. The path should look like this "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include"
PS: You should also check the properties configuration when you're adding the path to VC++ include directories. You could be adding the path to debug configuration and trying to run it in release mode.
You do indeed want
Project Properties -> Configuration Properties -> C/C++ -> Additional Include Directories
(or something close to that; I'm using VS 2008). Make sure the configuration you're editing in the top left (debug/release) matches the configuration you're building with (typically visible up top in the main window). So it sounds like you may have done it correctly; I'd double-check for the file's existence in that location. You could also try program\header.h instead of program/header.h. If none of those work, try adding C:\user\geninclude\program to the include directories (no \ at the end) and change it to #include "header.h". If that doesn't work either, you've almost surely got the header file in the wrong spot.
Another thing that can cause include files not being picked up is a difference between the platform set in your c++ project's Property Pages and your "Active Solution Platform" in configuration manager. Can just check if one is set to x64 and the other x86
check if you have specified the path correctly. for example I had written cpp instead of c++ and therefore suffered a lot and wasted like an hour searching here and there.
For Visual Studio 2019 users:
Project(P) > yours_project_name properties(P) > Platform Toolset Visual Studio 2019(V###)
Reasoning: You might download the project from Online and they used other version of Visual Studio as Platform.
Project(P) > yours_project_name properties(P) > Windows SDK Version ##.#(latest installed version).
Reasoning: You might download the project from Online and they used version SDK 8.0 while you have SDK 10.0
ntucvhw

git and visual studio 2010 express

I have used visual studio 2010 express for a while and have played with some extensive projects for quite some time. Since i'm nearing 50-60 files and thousands of lines of code, i've decided to do some source control for everything so that the project is more easily updated and accessible between all my devices, while also being back up.
I have used git before and am comfortable with it, but now when i made the commit and pushed it to a remote repository on bitbucket.org, i found that the .vcxproj files, while still retaining their correct file structure, also retained the include and lib directories for the device it was pushed from, meaning that when pulled down to another computer, those include/lib directories would be looking in the wrong directories, meaning i have to revise all of them every time i pull/push.
My question, Is there anyway i can push files to the repository such that the solution keeps the folder setup, but not the include and lib directory settings?
Edit:
After some research, i went looking into these so called property sheets in visual studio which are files that can be added to your project. The settings you set their take precedence over the settings of the project, but then the snag there is, if you add the individual property file to the project and then push the the .sln file, and the various .vcxproj files without that .props file, and then someone else clones from the repository, it won't open because it apparently requires that props file.
What i would like along these lines is a default .props file in the remote repository that, when cloned over, is no longer tracked, and then that user can just edit it for themselves. I don't know enough about git thought to make this happen. Does anybody have an idea?
I'm not sure what your problem is exactly, but here's my understanding:
Your project files contain absolute paths (e.g. "C:\myproj\include"). Replace these with relative paths (e.g. ".\include"). The "$(SolutionDir)" variable helps: if your solution file is C:\myproj\myproj.sln, then "$(SolutionDir)include" is the same as "C:\myproj\include". You can change the include and library directories in Project Properties > Configuration Properties > C/C++ and Linker, respectively.
Your project requires third party libaries - such as boost - and these are outside your project, say C:\boost. Unfortunately Windows/VS doesn't have a standard location for third party libraries, so you can either:
Include the library in your project. This is perfectly fine for small libraries, but it's not something you'd want to do with something like boost, which is both big and tends to be used widely.
Mandate that all devices set up these libraries in the same location, e.g. C:\sdk
Use an environment variable, like $(SDK_DIR) in the project, and all devices must set this environment variable.
Let me know if this helps.
What you're after are git's smudge and clean filters. You'll have to write a script for the cleaning, but sed'll probably do the job just fine, you won't need real xml parsing.

Visual Studio can't 'see' my included header files

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':

Parsing VS2010 MSBuild vcxproj file

I'm currently working on a console application that will pass a vcxproj file and compile it using GCC. Unfortunately, I've come up against a whole load of problems pretty much instantly.
I notice a bunch of directory shortcuts such as:
VCTargetsPath
VCInstallDir
SolutionDir
ProjectDir
UserRootDir
and so on.
Where does MSBuild get these values from? I assumed they were environment variables set up for the MSBuild process (afterall known environment variables are addressed the same way, ie "$(...)"). This was a bad assumption so I'm left wondering exactly how I get at these. Has anyone any idea on this?
Any info would be much appreciated :)
The MSBuild executable (and dependent DLLs) processes those properties the same way it processes any other property in the build file. In this case, they're simply predefined properties that it looks for explicitly.
If you really want to dig into it, open up the Microsoft.Build.dll in Reflector and look for the Microsoft.Build.Construction.SolutionProjectGenerator.AddGlobalProperties(...) method to get an idea of how it's handling some of the well known properties.
As an additional note, make sure you fully navigate down Import directives and handle overwriting of property and item values with each Import. There's a number of properties and items that are part of a Visual Studio build that are not always necessary for your code to compile correctly.
I believe that these are tied to Visual Studio macros: MSDN
Some of them are defined by the location of your files
SolutionDir - the directory containing the solution (.sln) file including this project
ProjectDir - the directory containing the project file (.vcproj, .vcxproj)
Others are defined by the location of the MSVC install
VCInstallDir - where the Visual C portion of Visual Studio is installed. ie. C:\Program Files\Microsoft Visual Studio 8\VC
and so on, and would be internal to msbuild based on what you loaded.