Visual Studio project and solution path variables

[Anthony_Richards]

In VS2012, under project properties..configuration properties...general I see paths such as $(SolutionDir)$(Configuration)\.

I presume that somewhere there must be a list of variables such as 'SolutionDir', 'Configuration' along with what they stand for.
How can I view this list? What is it called?
I want to set the output directory for a built .EXE to the project directory. Is there a variable 'ProjectDIr' for example that is shorthand for the full path to the directory I want to target?

Thanks in advance.

[IanH]

I just search the help index for one of the property macro names that I know and it normally lands me on a help page with a list of them.

The equivalent online help page for VS2012 is http://msdn.microsoft.com/en-us/library/c02as0cs%28v=vs.110%29.aspx

$(ProjectDir) is in that list, but I'm pretty sure the project directory is the starting point for any path-to-directory or path-to-filename type of properties anyway.  Consequently you may be able to leave the output directory field empty (or perhaps ".\" )

Note that having multiple configurations (versus multiple projects) dump their final output into the one directory is a recipe for confusion of the build system.  Be very careful about what happens during a "Clean" as well.  Depending on what you are trying to achieve, I'd avoid using the project directory itself for build output.

[Anthony_Richards]

Thanks for your input, Ian.

One of the (many and growing - still learning how to use it) annoying problems I have with setting up projects and 'solutions' in VS2012 is not knowing how to control the folder/subfolder structure that is created when building a solution which has more than one project in it.
For example, suppose I have to create a C++ main project and a Fortran static library project that is required by the C++ project. I have done this twice and have finished up with a different folder structure each time and do not understand why.
If I want to build an application called MYAPP, I would first create a root folder called MYAPP. I would want all associated files to be in subfolders of this main folder, so I would want the C++ project to be in subfolder CPPMAIN, say, and for it to create its executable in folders /CPPMAIN/Release and /CPPMAIN/Debug as required.
I would want the static library project files etc. to be in (for example) subfolder /FORTRANLIBRARY/ and for that project to create its library in /FORTRANLIBRARY/Release/ or /FORTRANLIBRARY/Debug/. For maintenance reasons, I would keep the C++ code in its own subfolder /CPPCODE/ and the Fortran code in its own subfolder folder /FORTRANCODE/. I would want the 'solution' to be called 'MYAPP' and for it to reside in my application folder /MYAPP/.
However, depending on the order I create the above projects from scratch along with the 'solution' that contains them both, I am able to finish up with one /Release/ subfolder rather than the two that I was expecting (hoping) to get.

I just do not understand how I can set up a folder structure that suits me right from the start. It would appear impossible to rearrange any folder structure that VS2012 sets up for a project and/or solution without disabling the whole solution structure, so one has to start again, which seems to me wasteful when a bit more knowledge might save me that extra effort.
Any ideas?

[IanH]

What's the difference between CPPMAIN and CPPCODE (and likewise for the FORTRANLIBRARY and FORTRANCODE).

The typical structure looks like:

The .sln file sits in the top MyApplication directory.  The vfproj and .f90 files sit in the FortranStaticLibrary directory, likewise for the .vcxproj and.cpp are in the CppMainProgram folder.  Intermediate obj files go in the Debug and Release subdirectories of the project directories, solution final outputs (the exe say, and any DLL's if relevant) go in the Debug and Release subdirectories of the top level solution directory. 

The x64 intermediate level is for 64 bit builds.  In some cases for symmetry I add a Win32 intermediate level for the 32 bit builds too - this makes the property settings more consistent across platforms.

I think this is pretty much what you get out of the box, though fortran main program and dll projects need to be told to put their final output in the solution level debug and release directories.  There's a checkbox when you create the solution that also creates the MyApplication solution level directory.  Sometimes rather than creating a solution by creating a new project I find it easier to use the blank solution template and then create the projects separately.