What's the purpose of defining a Cl task in msbuild like this?
<ItemGroup>
<ClInclude Include="Something.h" />
</ItemGroup>
Is this necessary? It seems like just have #include "Something.h" in the source file should be sufficient. What purpose does the ClInclude task then fulfill?0
It's basically just for use in the Visual Studio user interface: if you view projects in Solution Explorer and 'Show All Files' is turned off, it shows only what is defined in the different Items which serve as input for the build (ClInclude/ClCompile/Resource/...). So even when the compiler happily finds the include file, the IDE won't list it in Solution Explorer. Also functions like 'Go To Files' won't consider the file.
With 'Show All Files' turned on you get to see the whole directory structure, usually a better experience in my opinion, though it still shows files which aren't listed in the project explicitly with a red sign to incidate that. But then at least you can right-click on them and choose 'Include in Project' instead of finding them manually.
Related
I am just beginning my journey in C++ programming (coming from many other languages). Because I am learning the basics, I would like to store many simple C++ programs in a single project. Each of these simple console type applications will contain a main function.
When creating an empty C++ project, Visual Studio creates 15 files which comes to 546KB. To save room on my computer, it would be best to have sub-folders within this single project for each small C++ program for learning purposes.
Is it possible to break different console based programs up into separate folders within the same Visual Studio C++ project? I am using VS 2017 Community Edition.
Edit:
I understand that you can create a VS Solution with multiple projects within. The reason why I don't want to do this is explained above. 546KB is a lot of space to allocate just for running a small console application. It would be best to have many programs that can run independently within a single project. Is there a way in VS to choose which main function to call out of all of the main C++ files?
You can use separate project Configuration for each main function that you've got in your project (e.g. create project Configurations named Main1 and Main2). Then you can conditionally include the .cpp file that implements the relevant main function by editing your .vcxproj file, e.g.:
<ClCompile Include="main1.cpp" Condition="'$(Configuration)' == 'Main1'" />
<ClCompile Include="main2.cpp" Condition="'$(Configuration)' == 'Main2'" />
That will include main1.cpp only for a Configuration named Main1 and main2.cpp only for a Configuration named Main2.
I'd not recommend that though because Visual Studio 2017 does not update the Solution Explorer correctly when you switch the current configuration and you'll need to reload the project to see the current files.
Instead of conditional inclusion use the Excluded from build property to exclude files that shouldn't be compiled as part of the current configuration. This will show all files in solution explorer but only include the appropriate files when the build is actually performed. This is a bit backwards but works nicely with the UI. It has the additional benefit of being something the VS property editor can do without needing to open and manually edit the vcproj file.
The Excluded from build property is found on the file properties Configuration properties -> General. Open solution explorer (View->Solution explorer) right click on the file and that pane should be the default.
When I go to debug my C++ project in Visual Studio, up pops a little warning dialogue box that tells me:
A copy of datum.h was found in
c:/users/brad/desktop/source/binary/datum.h, but the current
source code is different from the version built into
c:/users/brad/desktop/source/binary/datum.h.
I'm having trouble understanding what this is even trying to tell me, let alone how to fix it. At first I thought it might be complaining that I'd accidentally duplicated a file in the directory, which I checked, and found nothing of the sort, which leaves me pretty stumped. I also tried excluding the file from the solution and adding it again, which didn't fix the problem either.
The warning doesn't appear to actually hinder the development of my project, but I suppose warnings exist for a reason, so if anyone knows what's gone wrong, any advice would be greatly appreciated. To my knowledge, I didn't change anything to cause the message to appear, it just popped up one time I went to debug the solution and has kept on appearing ever since.
Also, more copies of the same warning have started popping up, pertaining to other header files in my solution (I haven't recieved any about .cpp files yet, but it could be a coincidence, because it's only been going on for about 20 minutes).
Try removing breakpoints from the file in question.
This worked for me when it occurred with Visual Studio 2013 for a header file in debug build.
Source: Release mode file sync issue - current source code different from the version built
Additional notes: Clean / Rebuild also works, but that is painful for regularly changing code. Enabling the break point after starting debugger merely delays the message.
I solved it:
Close the window of the .h file in Visual Studio if it's open.
Close Visual Studio.
CUT the .h file from its normal location and paste it into a temporary folder that VS doesn't know about.
Restart VS and compile. It'll complain about the missing .h file. Good -- Make the bastard beg for it!
Paste the .h file back into its original location.
Compile. VS will gratefully accept the missing file. (Damn I hate Microsoft!)
This occurs if you rename an implementation file (*.c, *.cpp, etc.) to a header file.
This is because the Item Type still remains as C/C++ Source File, making it get compiled as a separate translation unit rather than as an actual header, preventing Visual Studio from recognizing its inclusion as a header elsewhere.
It took me quite a while to figure this out.
To fix this:
Right-click your header file in Solution Explorer and select Properties.
Select All Configurations, All Platforms.
Under General, change Item Type to C/C++ Header.
Press OK.
Force-recompile any file that #includes your header (or just Rebuild the solution).
The problem is that the debugger thinks that the checksum of the source file is different from what the compiler calculated and put in there. The debugger will then refuse to apply breakpoints in the files that mis-match, to prevent you from seeing data it can't guarantee is correct.
I have had this keep happening even after a clean rebuild. This is with VS 2015. My guess is perhaps the debugger and the compiler disagree on how to hash newlines or something like that? The fix is to turn off "require source files to exactly match the original version" in Debug -> Options -> Debugging -> General
Could you by any chance be debugging another executable (not the one actually built?). This is a common issue in scenarios where Visual Studio builds the binaries in one directory but then they are copied over to some other directory for debugging. I'd suggest you compare the target path under the debugging settings and the output directory under the general settings in Visual Studio.
This would explain the issue, since you are actually debugging some older version of the binary (not the one built currently) and thus the warning, since Visual Studio can't find the version of the source files for that version of the binary.
The reason may be circular header dependencies. datum.h may includes another_header.h (directly or indirectly), which includes datum.h.
I see the real reason of this question is not answered. So for someone still looking, here it goes...
The most common reason of this problem is that the source files used to build the existing obj files are different than the existing ones. In other words the
particular project did not build after new modifications to source. The solution to this problem is to rebuild the project after modifying.
This happened to me in situation where I had modified my static library projects files and then without building that project I started my application project which was using this static library project.
this worked for me:
close VS
delete *.vcxproj.filters file
restart VS
problem should be gone.
this worked for me:
clean project
debug/delete all breakpoints :)
This worked for me (as of March 2019):
Click the 'Build' drop-down menu in the top left of your Visual Studio window
Select 'Rebuild Solution'
I've changed the file name and it works now.
Just encountered this. In my case, one of my .h files contained implementation (a class with static methods), which was #included by one of my .cpp files, but the Project Settings were also telling Visual Studio to compile the .h file.
I manually edited both the .vcxproj and .vcxproj.filters project files, moving the .h file from the <ClCompile> ItemGroup to the <ClInclude> ItemGroup.
This did the trick for me; I never saw the "A copy of...is different from..." pop-up again.(Note that this was after I had thoroughly failed in attempts to get <DependentUpon> to work.)
My solutiion:
Build -> Configuration manager
Switch to another configuration (any, example Releas or Debug)
Switch to previous configuration
It is possible to have multiple projects, each with their own entry point within a solution. Make sure that the correct project is being run.
The source code is different message can appear in a project A's source when you are running project B. In this case, the message can mean This breakpoint won't be hit because you're running a project that doesn't include it
I've been trying to get Visual C++ working, but I'm getting this error when building every project: "This project is out of date" "Would you like to build it?" It fails to build every time.
When I rebuild, the build still fails, although in the logger I don't notice any error messages, which makes me think its not logging properly (I'm using a third party program to log).
I've followed some of the instructions here: http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx and enabled logging.
I'm getting this error: project not up to date because "insert file name here".lastbuildstate is missing. Note that in actual visual studio, there is nothing logged. I was unable to find anything on this in google. It may be that I incorrectly enabled logging, but I feel that this is the error.
You should let Visual Studio tell you why it needs to rebuild. Visual Studio 2015 has built in support for this:
Tools (menu)
Options
Project and Solution
Build and Run
Change MSBuild project build output verbosity to Detailed or Diagnostics.
In my case it printed a message like this:
1>------ Up-To-Date check: Project: xyz, Configuration: xyz ------
1>Project not up to date because build input 'C:\ws\Missing.h' is missing.
... and removing that header from the project fixed the problem.
To get this information in older Visual Studio versions, you need to use DebugView and modify devenv.exe.config (see Colin Smith's answer: https://stackoverflow.com/a/21759835/1941779). Note that this solution does NOT work for Visual Studio 2015.
What are "tlog" files?
"tlog" files are created by the "Tracker.exe" process which runs while you do a build, and records some information about the build.
That information is used and updated the next time you start a build to help detect "out of date" files, and thus enable the build system to only build the bits that need to be rebuilt (rather than building everything again).
File Tracker Log file format
https://social.msdn.microsoft.com/Forums/vstudio/en-US/67705333-a425-4d6e-9881-9077f044f87a/how-do-i-prevent-msbuild-from-creating-tlog-files-during-my-c-builds?forum=msbuild
https://dickyjim.wordpress.com/tag/tlog-files/
What causes the "out of date" problem?
The problem can be caused by incorrect or stale information in the *.tlog files.
There are 3 main ways that can happen:
1) You built a project on your hard disk, and then moved the directory to another location...the "tlog" files recorded the paths of the old location, yet because you moved the files, they are no longer there, thus you get "out of date".
2) Your "Project" has references to files (usually header files), which do not exist at the location specified. This might occur if you deleted a file from your source control system, but forgot to remove it from your project, or because you refer to header files of a library which might be "installed"/present at a different location. Often, Developers assume files are located at the same "place" on everyones machine....not always the case!
3) You have done some "refactoring" of your project, and moved files around to different subdirectories, or even renamed them - so the paths/names of the files recorded in the "tlog" do not match what exists on your disk i.e. stale.
What is the way to fix it?
Doing a "Clean+Build" or "Rebuild" does not always fix it...as those operations do not delete the "tlog" files. So:
delete any "tlog" files that you can find in your solution/project directories and rebuild.
make sure your Project does not refer to non-existent files
How do I work out which files are non-existent?
If you want to know/find out exactly which files Visual Studio is thinking are out of date, then you can turn on some diagnostic information in Visual Studio....and watch the messages in DebugView...showing the full path of the files it is probing.
http://blogs.msdn.com/b/vsproject/archive/2009/07/21/enable-c-project-system-logging.aspx
In devenv.exe.config you put:
<system.diagnostics>
<switches>
<add name="CPS" value="4" />
</switches>
</system.diagnostics>
More Details
Lets say you created a Solution and a set of Projects in a particular directory e.g. S:\MYPROJECTS, and you compile and run/debug it, etc.
You then decide to move that whole directory to somewhere else on your drive, or you re-factor your Projects e.g. change their directory names, etc.
Now when you do a "Start Debugging/F5", Visual Studio does the depending checking, and thinks you have "out of date files".
Even if you do a "Clean Solution", or a "Rebuild Solution"....you still get the "out of date files" message.
See here:
http://connect.microsoft.com/VisualStudio/feedback/details/653355/suggestion-help-me-diagnose-issues-causing-this-project-is-out-of-date-message
The problem is caused by the ".tlog" files which are being consulted during the dependency checks...when you moved the solutions/projects (along with a builds intermediate files) they cause confusion to the Visual Studio builder.
The solution is to delete all the .tlog files.....they will then be re-generated the next time you do a build...and from that point on you won't get a bogus "out of date files" message....unless they truly are out of date.
I too kept getting "The project out-of-date" error, even though there were no changes. I traced it to a header file listed in Solution Explorer that was no longer being used and had been deleted from the project's directory. Removing it from the SE list fixed the extraneous error message from popping up.
I had this problem, too.
In my case the reason was the references to files (usually header files), which do not exist at the location specified.
I ran into this problem and, using the diagnostics trick that colinsmith posted about, was able to trace the problem back to the fact that my .vcxproj was referencing a file that didn't actually exist anywhere (It had been deleted a long time ago, but never removed from the project file).
Just for posterity, I was getting this problem, and then realized my computer clock had somehow jumped approximately 48 hours into the past. After I set it back to current time, the warning went away.
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...
;) Yeah. I also have C++ in my solution.
How do I add a custom dictionary there? There is no tool for an includes file, as well as no way to tell it the type is CustomDictionary.
THe advice and approach shown in http://msdn.microsoft.com/en-us/library/bb514188(v=VS.100).aspx is not usable for C++ projects.
For VS2010, you can set the dictionary by editing your .vcxproj file and pasting this:
<ItemGroup>
<CodeAnalysisDictionary Include="c:\temp\mydictionary.xml" />
</ItemGroup>
Modify the path to your dictionary.
To make this a permanent setting for all your C++ projects, navigate to c:\program files\msbuild\microsoft.cpp\v4.0 and edit Microsoft.Cpp.props, pasting the above (make a backup please).
To verify that the change is effective, use Tools + Options, Projects and Solutions, Build and Run, MSBuild project build log file verbosity = Diagnostic. Rebuild your project, look in the .log file and verify that fxcopcmd.exe got started with the /dictionary option.
Both approaches worked well on my machine.
To get a CustomDictionary working with C++ you will have to edit the project file manually as described here.