I have always used the Visual Studio Dependencies option to ensure that, for example, when building my C++ projects, any dependent LIB or DLL projects are also built. However, I keep hearing people mention 'references' and wondered, with VS 2010 on the horizon, I should be changing how I do this.
Are there any benefits to using references to dependencies or is the former a .NET feature only? I am currently using VS2008.
'References' are a .NET thing and don't apply to native C++; they are different than dependent projects. A dependent project in a solution is a project that must be built before (or after depending on which way the dependency goes) another project.
A reference is an assembly that contains types used in the project. The analogous thing in a native C++ project might be the include files used by a project and the .lib files that get linked in (the native C++ project 'consumes' those items even if they aren't built in another step of the solution).
I prefer using references since these were introduced for unmanaged C++ in VS 2005. The difference (in unmanaged C++ developer's perspective) is that reference is stored in .vcproj file, while project dependencies are stored in .sln file.
This difference means that when you reuse your project in different solutions (and I often do) you don't need to redefine the inter-project relationships again.
Visual Studio is smart enough not to depend gravely on the paths of the projects when it establishes the reference relationship.
It used to be in VS2008 that a project dependency on a static library would automatically result in the right configuration (Debug|Release) would be linked in. It looks like VS2010 lost that ability with the move to msbuild. Sigh.