What's The Deal With Project Dependencies In .NET?
Author
Hi,
Ok so im writing some code and i have the framework files in one project, but i want to write the testing code in another. The problem im having is that i cant include the headers easily.
Since the projects lie in the same workspace i know where the folder for the other project is, in the same workspace folder. So what i am currently doing is having the include paths look something like this:
#include "../wsDir/FrameWorkDir"
This is in the framework main.c.
I have added the framework project to the framework test project's dependencies and tried this
#include <framework.h>
and this:
#include "framework.h"
and the compiler doesn't find them. Only does it find them when i specify the absolute path.
So what is the deal with organising project dependencies in this way, and also where do project references fit into the equation, if at all.
ace
In the options you must set a place to look for other headers or libs. You can do this eithe by project through the project settings. C\C++ General Additional Include directories.
You can also set it up as a global serach locations through the tools\options\Projects\ VC++ BUIld and set the search paths for includes and libraries.
In addition you mention the < vs " for including headers. typically the <> indicate a system header and causes teh compiler to serach the system paths first for the header while a "" indicates your own headers and causes the compiler to search for the header in your includes first.
Cheers
CHris
You can also set it up as a global serach locations through the tools\options\Projects\ VC++ BUIld and set the search paths for includes and libraries.
In addition you mention the < vs " for including headers. typically the <> indicate a system header and causes teh compiler to serach the system paths first for the header while a "" indicates your own headers and causes the compiler to search for the header in your includes first.
Cheers
CHris
Author
I understand everything you say but i wannaknow what project dependencies and references are for.
ace
ace
Don't confuse dependencies with modifying the #include search path. Dependencies are for the linker's benefit, the #include search path is used by the compiler to resolve #include directives. Adding a dependency doesn't update the #include search path.
(My opinion follows from here on out):
When you make a multiple project solution, always start by making a blank solution, then adding the projects in one by one. Your filesystem layout will end up like this:
SolutionName /
-Project1
-Project2
-etc
When you need to reference headers you wrote that are in another project, use the .. notation to navigate to the file. The only information that is exposed is the name of the project you're pulling the header from, and the path to that file within that project. (This is what you were wanting to do.)
When you want to bundle additional system-level libraries directly with your solution (for source control, so people can just download and run without installing libs like Boost), you can create a subdir under your SolutionName folder, and modify the "additional library search paths" so you can reference the headers using the standard system header notation (angle brackets).
Where the dependencies come in is where you need to link one module to another. All adding a dependency does is:
1. alters the solution build order so the dependent component builds before the consuming module
2. alters the consuming module's link command line to link against the generated output of the dependent module
Dependencies are for the linker's benefit, not the compiler's.
Note I didn't recommend adding your own projects to the additional library paths: this is for the benefit of readability.
Edit:
References are primarily for the CLR - they're how you link to other assemblies. Now, supposedly they work for unmanaged C++, however, I haven't really sat down and see what they do -- I suspect the same thing as dependencies.
(My opinion follows from here on out):
When you make a multiple project solution, always start by making a blank solution, then adding the projects in one by one. Your filesystem layout will end up like this:
SolutionName /
-Project1
-Project2
-etc
When you need to reference headers you wrote that are in another project, use the .. notation to navigate to the file. The only information that is exposed is the name of the project you're pulling the header from, and the path to that file within that project. (This is what you were wanting to do.)
When you want to bundle additional system-level libraries directly with your solution (for source control, so people can just download and run without installing libs like Boost), you can create a subdir under your SolutionName folder, and modify the "additional library search paths" so you can reference the headers using the standard system header notation (angle brackets).
Where the dependencies come in is where you need to link one module to another. All adding a dependency does is:
1. alters the solution build order so the dependent component builds before the consuming module
2. alters the consuming module's link command line to link against the generated output of the dependent module
Dependencies are for the linker's benefit, not the compiler's.
Note I didn't recommend adding your own projects to the additional library paths: this is for the benefit of readability.
Edit:
References are primarily for the CLR - they're how you link to other assemblies. Now, supposedly they work for unmanaged C++, however, I haven't really sat down and see what they do -- I suspect the same thing as dependencies.
And remember only add dependencies from libs to dlls or libs to exe's. YOu never add a dependancy from a lib to a lib:)
CHeers
Chris
CHeers
Chris
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
