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.
Related
I am getting the error mentioned above when compiling a project on Visual Studio. What is strange and different about my situation is that this works on my personal laptop, but not at work.
I have the entire project saved in Dropbox, because I sometimes work on my projects from work and I like this automatic sync that way I don't worry about loosing anything. Having said that, I use relative paths for my libraries, that way the folder is the same for both computers, i.e. "..\cryptopp\x64\Output\Debug\cryptlib.lib"
My question is, why does it work at home, but not at work? I made sure the property sheet has the correct path as well. The linker and VC++ directories are both relative paths.
This cryptlib.lib has some namespaces like CryptoPP and variable types such as byte, it won't give me an error on this. It knows it exists (I get the correct font color)
Is there something that I am missing?
P.S. Added screenshots per request. Can't add more than 2 links, so I merged 2 screenshots into 1. That ECE427Projects is where the solution file is located. I don't want to go any further back than that.
Screenshot 1
Screenshot 2
You've put the directory for the library in the wrong field.
There's two places you could use to specify the directory where your libraries are supposed to be. I prefer to use the Library Directories section in Configuration Properties→VC++ Directories, but the alternate is Additional Library Directories in Configuration Properties→Linker→General. There's no need to specify it in both locations, though I doubt anything bad will happen if you do. Bear in mind that this is supposed to be a directory, not a file, so delete the trailing cryptlib.lib file name from this directory string.
If you haven't, in Configuration Properties→Linker→Input, for Additional Dependencies, you should be putting the name of the library object (cryptlib.lib), in your case.
For all of these, make sure the default values inherited by the project property pages are still there, after the stuff you add.
Let me know if this doesn't resolve the issue.
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.
I'm working with a very old and large VC6++ project and it's all messed up. There are unused files and folders everywhere, copies of folders and it's just a mess to clean it up by hand in its current state.
It will be done eventually, but is there any simple way to check what files and folders are used when it does a clean compile?
The project settings doesnt help me at all because it simply uses copies of folders and additional include directories.
Any suggestions?
Well, if you want to parse the compiler output you can get which files are actually used. I also find this when googling around, you might want to try (I haven't tried it myself). My way would be to clean the build, list all source files, build, and for each source find its corresponding .obj. The ones without .obj are not used. Note that this only works for source files, unused header files stay undetected.
VC6 will produce a makefile for you:
http://msdn.microsoft.com/en-us/library/aa233950%28v=vs.60%29.aspx
You can use the generated makefile (and the associated .dep file) as a starting point and edit it down to the list of files that get used in a build.
This will let you see the header files that the project depends on in addition to the .c/.cpp/.lib files that might show in the build log. One thing to keep in mind is that you'll probably also want to make sure you track the .dsw and .dsp workspace and project files.
If you're a bit adventurous, you might be able to convince the makefile to actually copy the source files to some other location for you with an appropriate override of the certain macros and/or dependencies. But that would probably be more trouble than it's worth for a one-time effort.
Finally, there's a commercial product, CopyWiz by Kinook Software, that seems to have features that might do what you're looking for (and it supports VC++ 6). Note: I'm not sure if it will do what you want, but it may be worth a look.
Yes. Run Process Monitor from SysInternals. It can capture all file system events and filter them based on the path and other factors.
So, set the filter to the root of your source tree, only succesfull file reads (VC looks for headers in many places), and build your project. You'll probably still see several thousand events. So, save them to file, sort by path, and remove duplicate paths (headers especially will have many duplicate entries)
I'm a beginner starting to use Microsoft Visual C++ Express 2010 for Windows Programming. I've created a new C++ application using native code, not managed or MFC. I had Visual Studio create for me the basic windows code to create one window with simple menus (chat.cpp). I modified this file and I was able to compile correctly and see my changes take effect.
Now I've added one more source file to the solution (intro.cpp) which I include in my header and call from within chat.cpp. This seems to work just fine, but with one problem. The compiler doesn't seem to be applying my code changes occasionally: I make various edits, recompile, and the "old" code seems to be running. Then, after a while, after I make only a tiny modification, the compiler seems to "catch up" and it runs the new code including all the previous changes I had made.
Is there some kind of cache? Do I need to tell the compiler which files to compile and which ones to just link from object files? Did I make a mistake when I added the file to the solution?
Does intro.cpp have a header file? is that in your solution too?
It's hard for me to imagine that this area of such a mature IDE has a bug here, so I would examine your file list first. Make sure that the Solution Explorer shows all the files you have added and are editing. This is the list that VS uses to determine rebuild is needed.
EDIT: I admit it's not clear to me from your description why it would fail right now. However, typically header files do not include code, it works the other way around (except for class template header files, such as the STL headers). There is some discussion about pros and cons here. The most compelling argument to me in favour of code including headers rather than vice versa is that the header file contains the interface, while the code file contains the implementation.
I would try restructuring your code to a more traditional structure where intro.cpp includes intro.h and any others it needs, and the same with chat.cpp. Then your compilation units are intro.cpp and chat.cpp, and they depend on the associated header files, so provided they are properly listed in the SOlution Explorer, all should work. You can clean up the build dependencies to avoid dups and reduce build time once you have it working as you wish.
In a single solution, if I have the same source file present in multiple projects (with different project settings, e.g. different #defines), Intellisense and all the features depending on it seems to arbitrary pick one of the project settings when I edit the source file.
How do I get Intellisense to switch which project settings it uses for that file ?
If that is not possible, it would be at least useful to know which project Intellisense picks ?
I have exactly the same problem using VS2005. I read a while back that Microsoft found this to be 'intended functionality' and would not sort this out.
It seems that intellisense uses the first loaded project of the solution to apply the #defines for.