Visual Studio project organization question

Visual Studio project organization question

I've got a question about project organization.  My overall project centers around a top level .exe, and about 10 or so supporting dll's, The .exe and each dll has its own folder containing a .vfproj file and three sub folders; Code, Debug and Release.

The .sln file for the whole shebang is in a root folder that contains all the .vfproj folders.

Is this a good way to organize a project like this?  Visual Studio makes it pretty easy to set up this way.

I like the way this works except for one thing.  When I go to zip up the project, I want to zip up the project files and all Code, but not the folders of object files.

I am tempted to edit each dll project to set it Linker > Output File setting, which presently says $(OUTDIR)/BlahBlah.dll, to the output directory of the .exe project.  The thinking being that I'll only have a single Debug and Release folder to fiddle with.  But it seems I will have to hardcode the pathname, and that would be bad when unzipped on another computer.

Do you have any thoughts on this?  Is there a way to specify a relative path?  Would merging all the Debug folders into one cause problems?


Brian in Austin, Texas

3 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.

The best answer to this might be "What works well for you."

I tend to make the output directory for significant DLLs and EXEs to be a common directory, named per the configuration, that is under the solution directory.  (This is the organisation that MS VC++ projects used to default to - they may well still.)  Because DLL's and EXE's are in the same directory the DLL search rules then pretty much guarantee that the right DLL will be loaded when an EXE from that folder is loaded.

In the properties for the relevant project, you can use $(SolutionDir)$(ConfiguationName) to refer to that directory in a local path independent manner. 

I have seen reports that this arrangement may confuse some tools, but I've not experienced any problems.

Let's see what the forum software does with some ascii art:

+ Solution            Has .sln file, use $(SolutionDir) to reference


	  + StaticLibrary     Has StaticLibrary.vfproj, all StaticLibrary.f90 sources

	                      Can use $(ProjectDir) to reference, but it is the default



	    + Debug           Intermediate and Output directory for StaticLibrary.

	                      Receives all objects for StaticLibrary, plus the .lib itself.

	                      Named after current project configuration, so

	                      use $(ConfigurationName) to reference.


	    + Release         ditto


	  + DLLProject        Has DLLProject.vfproj, all DLLProject specific sources.


	    + Debug           Intermediate directory (only) for DLLProject.  Has all

	                      objects for DLLProject, but the DLL itself is directed

	                      (via the output directory property) elsewhere (see below).


	    + Release         ditto


	  + ExeProject        Has ExeProject.vfproj, all ExeProject specific sources.


	    + Debug           Intermediate directory (only) for ExeProject.  Has all

	                      objects for ExeProject, but the exe itself is directed

	                      (via the output directory property) elsewhere (see below).


	    + Release         ditto


	  + Debug             Solution level output directory.  Has final outputs from

	                      the various DLL and Exe projects.  Use

	                      $(SolutionDir)$(ConfigurationName) to reference.


	  + Release           ditto                  

Many zip tools (and source code control systems) allow exclusion of the things to be zipped (or controlled) on the basis of a regular expression or similar.  Consistent naming of the Intermediate and Output directories can simplify use of this exclusion filter.

x64 introduces a platform level into the hierarchy for the intermediate and output directories.  Consistency would suggest that level is mirrored in x86 (Win32) builds.  It would also have been nice if we (all tools) all agreed on the names of the platforms, but alas...

[Note that a solution is a Visual Studio concept.  With current Visual Studio versions (2010 on, perhaps earlier) and MS provided project types (so this is not really relevant to Intel Fortran only solutions) a separation has been introduced between Visual Studio and the underlying build system.  This can complicate the way that $(xxx) things get mapped through to actual settings in the build.]

"I see!", said the blind man.

That's what I was looking for.  Following your tip, I have found my way to the online help topic called:

Intel® Fortran Compiler XE 13.1 User and Reference Guides:  Supported Build Macros

I will need to do some experimenting, but I think once I decide how I want it, I'll be able to configure the various projects to put files where I want them.

I don't know how you managed to get the ascii art to do your bidding, but it did.




Leave a Comment

Please sign in to add a comment. Not a member? Join today