There are a few different levels of organization to consider. I will
take them one at a time.
The first level is how you organize your source files into the
components you compile and link, which correspond to the projects you
define in the Visual Studio development environment. You have two
choices here: you can have two projects that build executable
programs that happen to have some source files in common, or you can
have three projects. In the three-project design, you would move the
common files to a project that builds a library. Then you would have
two other projects that build the two different executable programs.
These projects would link in the library from the first project, but
not contain the source files that are used to build the library.
Of these choices, the two-project design will be easier to set up, and
the three-project design would be standard professional practice.
With big enough projects, the compiling time you can save by reusing
object code rather than source code can be significant, and it is
easier to manage aggregations of object code in libraries than
individual object files. If you are dealing with just two small
projects, these considerations may not apply to your situation.
In Visual Studio, a workspace is just a container for related
projects. I don't think there is any standard practice other than to
put projects that you want to work on together in the same workspace.
Putting projects in the same or different workspaces has no effect on
how they build; it only affects whether you see them at the same time
when you look at a workspace or you have to change workspaces to
change from one to another. So if you want to work on these two
programs together, it would make sense to put them into one workspace,
and if you want to focus on only one at a time, you might want to put
them in separate workspaces. This is just a question of your working
Independent of the organization of your files into projects and the
organization of your projects into workspaces, you must decide how to
organize the files in folders in the file system on your disk drive.
Standard practice would be to have one folder per project, with that
project's files, and only that project's files, in that folder. This
would work with the three-project design, where you would have three
separate folders for the library and the two programs that use the
library. It would not work so well with the two-project design. With
the two-project design, I would advise you to keep all the source
files in the same folder, rather than follow standard practice and
have a folder per project. If you had a folder per project, you would
have to duplicate the common source files in each folder, and having
two copies of the same file in different places is very undesirable
If a workspace contains only one project, it's standard practice to
store the workspace file in the same folder as the project's files.
If a workspace contains multiple projects, you can store it anywhere
where you can conveniently find it. One straightforward design would
be to have a higher-level folder that contains the workspace file and
the folders for the projects that the workspace contains.
It's hard to evaluate the three options you listed, because when you
talk about "project folders," I'm not sure if you are talking about
projects or folders, which are two different things. I'm also not
sure if you are talking about organizing the files in the file system
or in the Visual Studio project/workspace structure, or both.
I hope this explanation is helpful. If it is not clear enough or you
need more information, please ask for a clarification and I will