I am new to VS Code and, coming from VS, I'm struggling to understand how to set up different configurations using the Microsoft C/C++ extension. I followed the documentation, but it seems to me that the content in c_cpp_properties.json is only affecting Intellisense and has no correlation to the actual build, which is set up in tasks.json. The configurations I enter are showing up and selectable at the lower right of the editor window: Intellisense reflects this by apparent knowledge about include folders, etc. However, when I build or run, they don't have any effect, I get errors such as "No such file or directory" for included files. As far as I see it, this is not mentioned in the documentation at all.
How can I make use of the actual selected configuration for the build system?
Background
I'm running Visual Studio Community 2015 on Windows 10, writing C++ code.
I have been handed a solution with two projects in it. I need to create a duplicate of one of the projects, but using different source and header files (containing roughly identical code, but located in another place in the file system).
The project that I want to duplicate uses a lot of libraries, and I don't know how that was set up. All I know is that it works for that project, and I need it to work for the duplicate project too.
Problem
The problem I'm having is that at least one of the libraries does not seem to be recognized. This results in code with a red squiggly line under it, no auto-complete, etc. etc.. (This is not relevant anymore, see Edit 1)
Attempted solutions
I have tried creating a new project with the new source files, adding it to the solution, and manually copying project settings by right-clicking on the existing project, selecting Properties, and copying anything that is not set to its default value. This did not work.
I have tried copying the existing .vcxproj files, adding them to the solution, removing old and re-adding new source and header files. This did not work.
In both cases, when expanding External Dependencies in the Solution Explorer, the old project has a much longer list than the duplicate.
I am aware of this question, but the accepted answer relies on knowing which settings need to be changed. I don't know that, and I don't know how to find out.
Questions
So, is there a way to copy the entire set of settings that controls this?
Alternatively, is there a way I can check in the existing project precisely why it is able to resolve a particular external reference, so that I can find out which setting I need to change in the duplicate?
Edit 1
Well, now I feel stupid. I've been fighting this issue for a few days now, but I've made a few incorrect assumptions about the files I have.
It turns out, the second set of header files (located at a new place in the file system) are similar, but not identical, to the old ones. So at first glance, they look identical, and I never bothered to check.
The new header files has #if defined(WIN64) before the relevant #include statements, which of course is why the library wasn't being included.
So, my new question is, what's a sensible way to #define WIN64 without modifying the header file? Where can I put that definition so that it's valid in that header file, without changing that header file?
The correct way to use the same project properties for multiple projects would be not copy-pasting properties between them but to use Property Manager. You should figure out how exactly you original project is configured (note that properties for particular file can differ from project properties) and create a corresponding property sheet(s). Then apply this sheet for the new project.
I am currently using Visual Studio 2013 (Update 4) for building Qt5.4.0 projects. I use the express version so I don't use the VS plugin. My .vcxproj files a generated from .pro files using build scripts and qmake.
When debugging my projects I sometimes try to step into Qt library code. To do this I added the path to the Qt source codes to the solution properties->Debug Source Files setting like described in a former post (VS2013 debugger can not find Qt sources).
Because I have many different projects and it would be a pain to update all of them in case of a Qt update I used a system environment variable "QTSRC" pointing to that path and added the following line to the solution:
$(QTSRC)
This worked like charm some time ago (with an older update of VS and a former Qt version 5.x).
But unfortunately it does not work anymore. It seems that VS now totally ignores the system environment variable (it also does not show any errors when I check the "check entries" button in the dialog).
Does anybody know what changed here lately and what must be done to fix this? It would be very annoying to add the path hardcoded to every project (which still works) and have to do this over and over again after Qt updates.
I'd look at the Property Pages which will allow you to set user defined values that you can share across different projects:
http://msdn.microsoft.com/en-us/library/675f1588.aspx
I use them to set global include paths, but it looks like you can set almost anything there. Set things in the .User pages if you want them used for all your projects but not included in the solution or project file itself.
A good, short, guide is here:
http://www.curlybrace.com/words/2012/12/17/setting-global-c-include-paths-in-visual-studio-2012-and-2011-and-2010/
Background
Our build uses ant and a custom task to build Visual Studio projects/solutions as well as some Java projects. There structure is basically a large tree and artifacts from the projects are typically copied upwards to a common build directory.
This was previously a complete mess and I've greatly simplified the ant scripts and now I'm most of the way through the Visual Studio projects/solutions. These projects are extremely old and have been upgraded through every version of Visual Studio up to 2013. Part the changes I have done was to use as many of the default project properties and macros as possible. Most of these used to be hard coded.
Although I have modified the projects to use the $(Configuration) macro to separate the artifacts from different configurations these still get copied to a common location for other dependent projects in other solutions. So to avoid confusion and actually make sure our debug builds link to all the debug libraries (which wasn't happening previously) I have been adding suffixes to the Target Name. E.g. The Target Name of a Debug Unicode build will be $(ProjectName)DU.
Problem
This has been great so far but now I'm not sure how to complete these changes for one of our COM libraries. This library has an IDL file and the MIDL compiler generates a TLB file. Maybe this isn't a good way to do it but for now I wanted the TLB file to also have a different suffix depending on the build. The problem is, when I change the Type Library property for the MIDL configuration then this breaks the Compile-time directives in the RC file. I figured it might be possible to use #ifdefs in the TEXTINCLUDE block depending on whether _UNICODE or _DEBUG are set (provided I do it via the Resource Includes dialog so I don't break the RC file). It also means that there are other importlib attributes that will also need #ifdef checks.
At the moment it kinda works without renaming the TLB files but that's only because they are currently only being used within this solution.
Has anyone ever done anything like this or know a better solution?
Update
I guess what I really need to know here is what is the best way to use types from one COM DLL in another one? Should I even be using importlib? The MSDN documentation says that in most cases you should be using the import instead. I tried this but broke a whole bunch of stuff.
I am trying to import an existing c++ application's source into visual studio to take advantage of some specific MS tools. However, after searching online and playing with visual studio, I cannot seem to find an easy way to import existing c++ source code into visual studio and keep it structurally intact.
The import capacity I did find flattens out the directories and puts them all into one project. Am I missing something?
(This is all unmanaged C++, and contains specific builds for win/unix)
With no project/solution loaded, in Visual Studio 2005 I see this menu item:
File > New Project From Existing Code...
After following the wizard, my problem is solved!
Switching the "Show All Files" button shows the complete hierarchy with all directories and files within.
If the New Project From Existing Code... option isn't available, you'll need to add it in Tools > Customize...
I am not aware of any general solution under the constraints given - specifically having to create many projects from a source tree.
The best option I see is actually creating the project files by some script.
Creating a single project manually (create empty project, then add the files),
Configure it as close as possible as desired (i.e. with precompiled headers, build configurations, etc.)
Use the .vcproj created as skeleton for the project files to be created
A very simple method would file list, project name etc. with "strange tokens", and fill them in with your generator. If you want to be the good guy, you can of course use some XML handling library.
Our experience: We actually don't store the .vcproj and .sln in the repository (git) anymore, but a python script that re-genrates them from the source tree, together with VS 2008 "property sheet templates" (or whatever they are called). This helps a lot making general adjustments.
The project generation script contains information about all the projects specialties (e.g. do they use MFC/ATL, will it create DLL or an EXE, files to exclude).
In addition, this script also contains dependencies, which feeds the actual build script.
This works quite well, the problems are minor: python requried in build systems, not forgetting to re-gen the project files, me having to learn some python to make adjustments to some projects.
#Michael Burr "How complex are the python scripts and whatever supporting 'templates' you might need?"
I honestly can't tell, since I gave the task to another dev (who picked python). The original task was to provide a build script, as the VS2008 solution build was not good enough for our needs, and the old batch file didn't support parallelization. .vcproj generation was added later. As I understand his script generates the .vcproj and .sln files from scratch, but pulls in all the settings from separate property sheets.
Pros:
Adding new configurations on the fly. Some of the projects already had six configurations, and planning for unicode support meant considering doubling them for a while. Some awkward tools still build as MBCS, so some libs do have 8 configs now. Configuring that from hand is a pain, now it just doesn't bother me anymore.
Global changes, e.g. moving around relative project paths, the folder for temp files and for final binaries until we found a solution we were happy with
Build Stability. Merging VC6 project files was a notable source of errors for various reasons, and VC9 project files didn't look better. Now things seem isolated better: compile/link settings in the property sheets, file handling in the script. Also, the script mostly lists variations from our default, ending up easier to read than a project file.
Generally: I don't see a big benefit when your projects are already set up, they are rather stable, and you don't have real issues. However, when moving into the unknown (for us: mostly VC6 -> VC9 and Unicode builds), the flexibility reduced the risk of experiments greatly.
Create a new empty solution and add your source code to it.
For example,
File>New>Project...
Visual C++>Win32>Win32 Console Application
Application Settings>
- Uncheck "Precompiled Header"
- Check "Empty Project"
Project is then created. To add existing code:
Project>Add Existing Item...>
- Select file(s) to add
Recompile, done!
In the "Solution Explorer" you can click on the "Show All Files" button to have Visual Studio display the files as they exist on the file system (directories and all).
In my opinion this is an imperfect workaround, but I believe it's the best available. I'm unaware of a plug-in, macro or other tool that'll import a directory into an actual project with folders that mirror the file system's.
I know this question is already marked correct, but I was able to import existing code into a project with Visual Studio 2008 by doing "File" -> "New Project from existing code". The directory structure of my code was retained.
You can always switch view from project menu
For eg. Project->Show All Files
The above will display the files in unformated raw file system order
Not sure of older versions but it works on VS 2010
I understand you, I have the same problem: many .cpp and .h files organized in many folders and subfolders with include paths written for this folder structure. The only way you can do to import this folder structure together with the source files is to use "Show All Files" and then right-click on folders and select "Import in Project". This works for me when I am using C-Sharp projects. But it does not work for my C++ Projects. I am still searching for a solution...