I'm working on a VS2012 solution. This solution has a C++ project as a main project. The main project references several external libraries, and I might add a couple of extra libraries as well in the future.
The solution also has a C++ unit test project to test the code. I have a reference in the unit test project to the main project.
However, unlike with C# or other CLR-type projects, this somehow doesn't mean that the references in that project are copied. (might be that in those projects a .dll reference is all that seems to be necessary to get the job done)
I'm currently unable to include files from the main project, nor are the libraries that the main project has included or which it is linking to included in the test project.
I'd like to know if there's a way to access all the main project's files, include search directories and library references without editing the unit test project's properties all the time. Is there a way to do that? I've tried setting Use Library Dependency Includes to true in the unit test project's settings, but it keeps getting reset to false.
Will enabling copy local or copy local sattelite assemblies help solve this?
Copying output of native project referred in other projects does not work like in .NET because the mechanisms are different. The one solution that comes to my mind now is adding a post-build event action to copy the output to the desired folder.
Related
I am trying to write unit tests for a larger, old project using GTest. The project compiles as a dll. Here is what the setup looks like: There are several projects inside the solution, and I am trying to add a Test Project to unit test on of the several projects.
As a proof of concept, I created a HelloWorld project, and a HelloWorldTest project in a different solution. To emulate my larger project, I changed the Configuration Type from .exe to .dll and ran into some errors. But these errors were resolved exporting classes/functions using __declspec(dllexport) along with including .lib in the project, and I am able to build and run the exe of the HelloWorldTest project.
I am trying to follow the same approach for my larger project by painstakingly adding EXPORT statements before classes/functions. However, I run into errors when I include required header files in the Test Project since the header file has other include statements which the Test Project does not understand about. For example, if I include "..\larger_project\custom_math.h" but custom_math.h has something like include "..\..\algo\somefile.h". (I've seen posts about referencing one project to another and have already done the same for my project.)
How do I resolve the issue of chained header file includes? I believe if I can resolve this, I should be able to create objects and start testing in my Test Project.
is there a better way to do this than adding EXPORT statements before every class/function?
I am quite used to Linux development and Makefiles, and started using (Windows and) Visual Studio not so long ago.
What I want to do is (I think) quite simple, but I can't seem to find how to do it using Visual Studio.
I have to write an application, which I can divide into several independent sub-parts. I want to work incrementally, and create several projects that together with a main file will end up with my full project.
What I basically want is to be able to write a small project, have a main for it so that I can fully test it, and use it as a dependency for the next project. In this case, the smaller main would be deactivated (or I can comment it), and I would just change the startup project.
If I find a bug in a subset while writing my bigger software, I could just change the startup project and solve it at a smaller scale.
Well, that's what I do all day long in Python and Java.
I tried to create new projects into my project, but I always end up having linking problems, where my main projects knows about the files in the sub projects, but not the smaller ones, etc. . .
So, is there a guide somewhere I can find to work this way ?
Thank you
For individual projects:
Every individual project property sheet has a C++ options page. Here you can specify the 'Addional Include Directories' in a comma separated form.
Similarly, there should be a property sheet for Linker where you can specify the 'Addional Include Dependencies' and the names of the libraries it depends on.
For linker dependencies of the main executable:
Go to that main project, go to its properties, go to common properties and select 'Framework and References'. This should give you a list of all the projecs that are in your solution. Keep adding them and Visual Studio should add the right linker flags automatically for you.
Sorry, have no access to the computer now else would have provided exact steps. Visual Studio can get tricky sometimes but once you use it, you'll be amazed by what it can do for you. Personally, I love it.
Hope this helps.
Thanks to Vaibhav, I was able to find a solution:
I had to :
change subproject type to lib instead of exe
Add the subprojects as project dependencies in the main project (this just sets the build order)
Comment out the main of my subprojects, to keep only one active.
Add each subproject include directory in the include repos of the main project, so that the compiler can find the header files
Add the general directory as a dependency for the linker (in this case, it is not the debug/release folder of the subprojects, but the output directory of the complete project).
Add the names of the lib files of the subprojects in additional dependencies of the linker of the main project.
To make it simple, the project dependencies capability of VS2010 just changes the order in which the projects are built. . . I miss Eclipse.
If I find a bug and want to test on of the subprojects, I have to :
change the startup project to be the subproject I want to change.
uncomment the corresponding main
change the project type to be exe instead of lib to be able to compile it.
Debug, and do everything back again to continue working on my main project.
Quite boring, don't you think ?
Looks like you trying to do manual unit testing. Use something like Google.Test. You need to make test project for every lib.
We have directory with static libs projects. Another directory with tests projects. Every test solution contains one exe project and few existing lib projects. Every project have configured dependencies. You dont need to set additional dependencies of the linker manually (paths are evil, out dir for the lib file will be taken from project settings), open project properties with right mouse button, Common properties, Add new reference and select lib project. You only need to set additional include dirs.
When you find new bug - just open test project for the library with bug, add code which cause the bug, fix it, and be happy (and sometimes run all test). And even better - use TDD.
say I have a sln which contains 10 projects(named proj1 to proj10), and proj1 is the default project which generate the EXE file.
My problem is: how to place the 'include' folder?
I mean if proj2 uses proj3(that is including its header file and linking its lib file), how to place the 'include' folder?
there are two approaches:
place all header files and lib files in a different root folder which is in the same level of the project
make every project self-close, and the other projects who want to use this project should take care of the include-path and link-path. Of cause we should give a rule to the layout of every project(e.x. every project MUST have a 'include' folder and 'lib' folder in the root folder)
any suggestion?
thanks
When it comes to Visual Studio, I don't like either of the two approaches you suggested, although mine is most closely related to your Option #2. The way I like to organise it is like this:
<SolutionRoot>
<Project1>
project1.vcxproj
someheader.h
somesource.cpp
<Project2>
<Project3>
<Project4>
<Project5>
application.sln
In case that's not obvious, that's a quasi-directory listing showing some project folders and the base solution file.
All new projects are just added to the solution using Visual Studio's default settings. Trying to go against this and making projects work like Linux projects (lib, include, src etc) just ends up causing you grief, so don't do it.
Now, I set my "additional includes" path on every project to $(SolutionDir). Then if I want to include something from Project1:
#include "Project1/someheader.h"
The advantage of this is you don't clutter up your 'additional includes', so it's easy to see at a glance what external includes a project has.
As for linking to lib files, why not take advantage of Visual Studio's project references feature. Honestly, your life will be easier. Simply hook it up so that Project2 references Project1, etc... Then you don't have to worry about libraries and linker paths. You only do that for toolkits that are outside your solution tree (eg distributions such as libpng or openssl).
Again, you free up that setting so it only shows linkages outside of the solution. The other advantage is that your build order is implicitly defined if you use references.
I would go with the 1st solution. it make the project settings simple. As the C++ projects we worked on, we always put the header files together.
I have a solution where I've added and setup boost unit tests. The problem is that I have another project I'd like to test that has some classes in it. In fact, that project is the main reason I added boost.
My project that needs testing is set to output as a .dll. And the problem is that, whenever my tests project needs to access code from the other projects, it can access the header just fine. However, if the header has unresolved code in it that's otherwise resolved in a .cpp file of the project with the objects, I receive a linking error. Is there a way around this? I'd ideally like to keep my objects in my other dll and then test them in my tests project.
You're probably not telling your test project where to find the symbols. Either link against your production code's .lib manually, or you can add the project as a reference and VS will link your projects automatically.
Go to your project's properties, under Common Properties choose Framework and References. Click the Add New References... button, and select your other project. Since it's a .dll, you then want to set Link Library Dependencies to False (save and reopen the dialog, that setting seems to be buggy).
The problem was that the visual studio compiler couldn't link to the CPP in the other files. I had to add the CPP files to the boost project as well using the existing files option.
Create a new solution with a C++ console command-line project
Create a new project, a C++ static library
Make the command-line project depend on the library
Make sure "Link Library Dependencies" is turned on in Configuration => Linker => General (it is by default)
Visual Studio will still not link the library.
How can I fix this? It worked in Visual Studio 2008.
This still works, but was changed in VS 2010:
"With VS2010, we stopped supporting project dependencies defining implicit references and we also introduced a new way of defining project dependencies at the project level. Since a project reference and a project dependency are close concepts, both applying to a project, it made sense to have them represented together, in a consistent way, in the project file. As you will see in the snippets below, the only difference between a project reference definition and a project dependency definition consists in metadata that defines the output assembly inclusion/exclusion into/from the main project link command line.
Although we did not remove the “Project Dependencies” dialog, we recommend defining new project dependencies via the “Framework and References” dialog. You need to set the “Reference Assembly Output” property in the property page UI to false for a project dependency and to true for a project reference."
Just right-click on the console project, select "Properties->Common Properties->Framework and References->Add New Reference" and add the static library project; also check that "Link Library Dependencies" is True on the right hand side. Seems to work for debug and release builds. You learn something new every day. ;)
They changed the UI for adding C++ project dependencies in VS2010, but oddly enough, without removing the old UI, or in any way indicating that it no longer works.
To create the dependency in VS2010, you need to use "Add New Reference" (can be found in project properties), and maybe also in the project's right-click menu (don't have VS here to check)
The old "Project Dependencies" dialog is basically broken now.
For MSVC 14 (2015 version) right-click on the project, then "Add->Reference..." and check all the needed dependencies.
Yes, it has changed somewhere between 2010 and 2015 versions. Fun!
And if you are looking to link a project that has resources in it - you need to specify the .res file directly in the list of linker input dependencies (project's properties dialog box) as it doesn't get picked up by the above configuration.
UPDATE
Still the same (new) behavior in MSVC 2017
I believe the old UI (dependencies) affects build order for Visual Studio, when building from within the IDE, for info. The new project configuration system embeds the references in each project file so that you can build from outside the IDE (whereas in previous versions, you could not, because you would not get automatic linking for dependencies, since dependencies were only done at the solution level).
There are also some issues with more complex projects in the new system; specifically, all resulting binary projects need to have explicit references to every dependent library to build correctly, whereas previously they could be effectively inherited from other dependent libraries. Same underlying cause, though.