I am working with a large console application. The solution contains 5 projects.
I am adding a 6th project to replace one of the existing projects to allow for the use of a GUI.
I am getting many compiler C2011 errors regarding type redefinition. In particular, they are 'struct' type redefinitions or '[function]: redefinition; different linkage. They come from the header files ws2def.h and winsock2.h.
I've been searching the entire project and the entire solution for where these are included, but I don't see any #include <ws2def.h> or #include <winsock2.h> statements, nor anything to indicate they are used.
However, there are External Dependencies folders/filters included in both the project I'm replacing, and my new project. Both ws2def.h and WinSock2.h exist in those filters. I wouldn't think that having the same file included in separate projects under one solution would cause these issues. Also, I'm getting these errors when building just my new project, meaning it shouldn't see the old project anyway.
Based on the information I've given, are you able to see where my problem may lie? Is it the case that these header files must be #included somewhere within the project and I'm just not seeing it? I've considered deleting both the header files from the External Dependencies filter because it seems I don't need them. Is there a different, common header file that also includes these header files so that they wouldn't show up in a CTRL-Find?
Thank you.
The issue seems to have mostly been based on the horrible file structure of the original large project.
Trying to create a new project within the solution to replicate another project as a GUI instead of Console project meant that the compilation of the project was doubling up on many files.
I found another post (can't find it right now) that stated that when a Visual Studio solution compiles, all of the project files are combined, much like all the #include statements in a .c/.cpp/.h file really just copy all of those files into the file which #included them.
My solution was to create a copy of the large project (for backup purposes), and in the copied project, remove the original Console project and only include the UI Project. Files are not longer doubling up because they don't exist in both projects anymore, just the one still existing in the solution.
Related
I started a project from the DirectX and XAML template and made some small edits to the Direct3D-only portion of the project.
Now I get a number of errors in the xamltypeinfo.g.cpp file, stating that the Common::NavigationHelper class doesn't exist. Hovever I can validate that it's definitely a class included in the template, but it looks like whatever generated these files didn't include it.
I don't want to go messing around with generated files, and I haven't touched any of the XAML code at all in the template.
I created another project walking through the steps I had performed, and ran a diff on the two projects. The entire Common directory (and namespace, which included NavigationHelper) was unique to the original project.
I then remembered that at one point I had accidentally added a XAML page. I promptly removed it, which seems to have left these files included but they weren't included by another other file. Visual Studio still generated references to them, thus the errors.
It looks like if you add any XAML pages that require navigation, pulling them out is not as simple as removing the file. You must also remove the navigation infrastructure as well, by removing all references to the Common folder that were added to your project.
Visual Studio C++ lib project
Project is set to use precompiled headers
stdafx.cpp is set to create precompiled header
I have a header file, MyClass.h
If I build, then make a change to MyClass.h that should fail to compile, compile still succeeds.
If I do a rebuild, or if I make a change to a cpp file that includes "MyClass.h", then the compile fails as expected.
Is this expected because I'm using precompiled headers? Is there any way to fix it so a 2nds buid picks up header changes without turning off precompiled headers?
Make sure that the header file you are altering is referenced by your project in Solution Explorer. If this is the case, the full build should trigger when it is changed.
In the project properties, set "Enable Minimal Rebuild" to No
Are you sure that stdafx.cpp includes the header in question?
VisualStudio can often get pretty damn stupid over changes. It can go either way, but usually it goes the way you're running into.
I've had it catch onto changes in a header used by one file, but not the fact that it's used in others. So it compiles the one but not the others. Then I get really weird linker errors.
It could of course still be your own damn fault, but VS is, in fact, notoriously stupid. Sometimes a complete rebuild will fix the issue permanently, until next time. Other times you have somehow hosed the project file and hopefully you can get back to the original (like a source server revert). "Undo" most usually does not undo this kind of fubar.
I've noted this several times not needing to be a header that's in the precompiled header. It seems to be somewhat random but one more common correlation is that the header is full of templates. VS is just plain retarded wrt templates.
i am new to windows c++ i have created an application in visual studio 2008 and i have created new win32 console and i have compiled an sample c++ program it asked me to add the stdafx header and is it is compulsory to add this header ??? i dont need any windows library....
No, just create an EMPTY project, and add a main .cpp. This will be fine for any very small win32 projects. stdafx is absolutely unnessacery, and to be honest, I don't use it or even know what it is (I have only about a month experience with MSVC).
However, to make win32 applications, you need #include <Windows.h>, which is the windows header file.
To be able to remove the file you have to disable Precompiled headers in project settings. This might increase compilation time, so I'd recommend you just familiarize yourself with the mechanism. Its described on Wikipedia and at MSDN
The wizard will assume that you want something called Precompiled Headers and generate your project based on this assumption. In the new project wizard, make sure that you click "next" rather than "finish" (or similar) and ask for an empty project. With that done, add a new .cpp file and write your code in it. You should no longer need to include stdafx.h in every source file.
Precompiled headers are quite useful in large C++ projects, in that they can significantly reduce compile time. However, for most small to mid-sized projects they are mostly an annoyance. I personally tend to create empty projects -- if I want PCH, I'll add them myself.
This file is not mandatory.
It is created by the Visual Studio Wizard, and has for purpose to be the general include file, that you'll include in all your cpp files, and that'll include all the header files you need. It will serve as being the precompiled header source.
You don't need it, but compilation might break if you selected "use precompiled header" when you created your project and you don't turn off the corresponding "create/use precompiled header" compiler option.
A precompiled header is one that, as the name suggests, is partially pre-processed or compiled, so as to speed up the rest of compilation. Typically, if you were to use this feature, you'd put a bunch of #include statements in stdafx.h, for system headers that (virtually) all of the files in your project use. Things like <windows.h> are commonly put here, as are MFC or ATL GUI libraries. You can also put your own headers in there, but they should be ones that change only quite rarely.
I am right now reorganizing my project and what recently was a simple application now became a pair of C++ projects - static library and real application.
I would like to share one precompiled header between two projects, but face some troubles with setting up the .pdb file paths.
Assume my first project is called Library and builds it's .lib file with a corresponding Library.pdb file. Now, the second project is called Application and builds everything into the same folder (.exe and another Application.pdb file).
Right now my both projects create their own precompiled headers file (Library.pch and Application.pch) based on one actual header file. It works, but I think it's a waste of time and I also think there should be a way to share one precompiled header between two projects.
If in my Application project I try to set the Use Precompiled Header (/Yu) option and set it to Library.pch, it wouldn't work, because of the following error:
error C2858: command-line option 'program database name "Application.pdb" inconsistent with precompiled header, which used "Library.pdb".
So, does anyone know some trick or way to share one precompiled header between two projects preserving proper debug information?
The question is, why do you want to share the precompiled header (PCH) files. Generally I woul d say, that does not make sense. PCH are used to speed up compiling not to share any information between different projects.
Since you also write about the PDB file, you probably want to debug the library code with your applications. This can be achieved by setting the /Fd parameter when compiling the library. When you link the library in your application and the linker finds the corresponding PDB file, you get full debug support.
This sounds complicated and cumbersome to set up. More than that, it may not be possible at all.
Instead, you can include the precompiled header from one application into the second. It will still be compiled once for the second project, but maintenance becomes easy and you do not have to redefine the dependencies in the second project (just include them).
In some of my VS 2005 projects, when I change an include file some of the cpp files are not rebuilt, even though they have a simple #include line in them.
Is this a known bug, or something strange about the projects? Is there any information about how VS works out the dependencies and can I view the files for that?
btw I did try some googling but couldn't find anything about this. I probably need the right search term...
I've experienced this problem from time to time, and with other IDEs too, not just VS. It seems thatv their internal dependency tree sometimes gets out of whack with reality. In these cases, I've found deleting pre-compiled headers (this is important) and doing a complete rebuild always solves the problem. Luckily, it doesn't happen often.
To be honest I never faced such a problem using Visual Studio. Your CPP should be rebuild as well if it includes the header. The only reason I can come up with: same include file is taken from 2 different sources.
You can try do debug this at compile time, by enabling the preprocessor to output preprocessed files. Click on the CPP file go to properties and then to C/C++->Preprocessor and select in "Generate Preprocessed File" the item with or without line numbers.
Go to you include file put the pragmas around your newly added definitions like:
#pragma starting_definition_X
...
#pragma ending_definition_X
Now compile everything. There will be a newly created file with the same name as CPP but with extension .I (or .i).
Make a search if your pragmas are there. If not, your include come from another place.
If you use pre-compiled headers, you cpp should rebuild. There is also a pragma once statement in MS VC, which parses the include file only once, but that should still recompiler you cpp-file.
Hope that helps,
Ovanes
Do you have the "Minimal rebuild" option turned on?
Visual studio compares the timestamps on the files. So you might want to check that your system clock is set correctly and also that none of the files has a funny timestamp on it. Look at the include files, the cpp files, the pch files and obj files and make sure all the timestamps look reasonable. In particular, make sure none of them are in the future.
Was the .h files added in the project? If not, then vs maybe unable to find out the dependency.
Thanks for all the answers they have helped point me in the right direction.
I have discovered that deleting the idb file and rebuilding will then allow subsequent modifications of .h files to cause the correct .cpp files to be built. However this causes the entire project to be rebuilt which just brings me back to Neil Butterworth's suggestion of doing a full rebuild. I don't think there is much else I can do about it.
As an aside, looking at the bad and good idb files I can see that the cpp file that was not being built is not in the bad idb, whereas it is in the good idb. The header file that is being changed is mentioned several times in both files.
win_pdbx (download) can extract the idb file and moyix has published some information about the streams in these files.
Stream 4 contains the file paths of the cpp files but I have not been able to determine the format.