Including one project in many solutions?

[John Brock]

I'm using Visual Basic 2008 Express, and I've been wondering about
the "proper" way to structure my code. In particular, I'm not
clear on the purpose of "solutions". I understand that they are
a container for "projects", but what isn't clear is when you should
put everything in a single solution, and when you should have
separate solutions.

One thing I have noticed is that it is possible for one solution
to include a project that was initially created as part of another
solution. For example, I can create a solution S1 with a project
P1, which is a class library and creates a DLL. I can then create
another solution S2, add P1 to S2 (which does *not* result in P1
being physically copied to S2), and then create another project P2
in S2 that references P1. At least in this simple case I don't
run into any problems: I can open either S1 or S2 to edit P1, and
when I run P2 the P1 DLL gets compiled and copied to the proper P2
bin directory.

What this means is that if I have two applications which both
reference a single DLL, I have the option of creating a single
solution and putting all three projects there, or creating three
separate solutions, one for each project, and adding the DLL project
to the two application solutions. My intuition tells me that the
former is probably the "right" way to go, but I would have a hard
time saying why. In particular, with the second approach my two
applications are isolated from each other, and I don't have to
worry about the "Multiple Startup Projects" thing. So can anyone
explain what advantages the first approach has, or would problems
I might have if I went with the second?

(Also, can anyone recommend a good general article on the best ways
to structure .NET projects and solutions?)

 

[Family Tree Mike]

I'm using Visual Basic 2008 Express, and I've been wondering about
the "proper" way to structure my code. In particular, I'm not
clear on the purpose of "solutions". I understand that they are
a container for "projects", but what isn't clear is when you should
put everything in a single solution, and when you should have
separate solutions.

One thing I have noticed is that it is possible for one solution
to include a project that was initially created as part of another
solution. For example, I can create a solution S1 with a project
P1, which is a class library and creates a DLL. I can then create
another solution S2, add P1 to S2 (which does *not* result in P1
being physically copied to S2), and then create another project P2
in S2 that references P1. At least in this simple case I don't
run into any problems: I can open either S1 or S2 to edit P1, and
when I run P2 the P1 DLL gets compiled and copied to the proper P2
bin directory.

What this means is that if I have two applications which both
reference a single DLL, I have the option of creating a single
solution and putting all three projects there, or creating three
separate solutions, one for each project, and adding the DLL project
to the two application solutions. My intuition tells me that the
former is probably the "right" way to go, but I would have a hard
time saying why. In particular, with the second approach my two
applications are isolated from each other, and I don't have to
worry about the "Multiple Startup Projects" thing. So can anyone
explain what advantages the first approach has, or would problems
I might have if I went with the second?

(Also, can anyone recommend a good general article on the best ways
to structure .NET projects and solutions?)

I think a possible article to get you started is:
http://msdn.microsoft.com/en-us/library/ms998208.aspx

 

[John Brock]

I think a possible article to get you started is:
http://msdn.microsoft.com/en-us/library/ms998208.aspx

Thanks, that's very much the sort of thing I was looking for. As
I suspected, MS does strongly favor the single solution approach.

Interestingly though, none of the three models they examined exactly
matched my intended second approach, which doesn't use file references
(like their Multi-Solution Model), and doesn't nest inner solutions
entirely within an outer solution (like their Partitioned Single
Solution Model), but rather uses solutions which overlap partially
but not entirely.

This isn't clear from my example, which for simplicity only used
two solutions, but you can see what I was actually thinking of
doing if you create another solution S3 containing a project P3,
and then add P1 to S3. The three solutions with their projects
are now S1(P1), S2(P2,P1), and S3(P3,P1). P1 is the support DLL,
while P2 and P3 are two applications that are entirely isolated
from each other. That was the point: when I'm working on P2 I can
never see or change P3, and vise versa.

Being a conservative sort, I'm going to go with Microsoft's
recommended model. Still, it would be interesting to know whether
my second approach is workable, or whether Visual Studio would
eventually get confused by multiple partially overlapping solutions
and end up doing something Bad.

 

[John Brock]

[...]

I think a possible article to get you started is:
http://msdn.microsoft.com/en-us/library/ms998208.aspx

Thanks, that's very much the sort of thing I was looking for. As
I suspected, MS does strongly favor the single solution approach.

Interestingly though, none of the three models they examined exactly
matched my intended second approach, which doesn't use file references
(like their Multi-Solution Model), and doesn't nest inner solutions
entirely within an outer solution (like their Partitioned Single
Solution Model), but rather uses solutions which overlap partially
but not entirely.

This isn't clear from my example, which for simplicity only used
two solutions, but you can see what I was actually thinking of
doing if you create another solution S3 containing a project P3,
and then add P1 to S3. The three solutions with their projects
are now S1(P1), S2(P2,P1), and S3(P3,P1). P1 is the support DLL,
while P2 and P3 are two applications that are entirely isolated
from each other. That was the point: when I'm working on P2 I can
never see or change P3, and vise versa.

Being a conservative sort, I'm going to go with Microsoft's
recommended model. Still, it would be interesting to know whether
my second approach is workable, or whether Visual Studio would
eventually get confused by multiple partially overlapping solutions
and end up doing something Bad.

I'm just following up on my own post to say for the record that
yes, if you follow my second approach as described above, Visual
Studio will rather quickly do Something Bad. It's not so much that
VS gets confused somehow -- what it does actually makes perfect
sense -- it's that the model itself is obviously flawed. For
example, if I open S2 and change the name of a class in P1, the
name change will propagate to P2, but not to P3, which means I will
see errors in P3 the next time I open solution S3. Totally
unworkable, so I don't want to leave the suggestion laying around
for someone else to take seriously. The Microsoft article above
does a pretty good job of describing what *will* work.