Another approach you can take to this is using the Subversion externals property to be able to manage your code, either in separate repositories or in a single repository. The advantage is that you can simply update the URLs in question when you need a new release of the shared code in your solution.
Note: I don't remember jack about the Visual Studio solution and project organization; it's been at least 5 years since I've done any Windows development. That being said, this discussion is applicable no matter what the file/directory layout is. I'm going to make one up and please just adjust it to your actual situation.
Lets assume you have one big repository that has all your related projects in it. If you think that isn't necessarily scalable, I'd suggest taking a look at the Apache projects SVN setup; they have all the projects in one repository. Taking a page from the ASF, let's start out the repository structure as follows:
/SolutionA/trunk
/SolutionA/tags
/SolutionA/branches
/SolutionB/trunk
/SolutionB/tags
/SolutionB/branches
/SharedClassLib/trunk
/SharedClassLib/tags
/SharedClassLib/branches
/SharedWebService/trunk
/SharedWebService/tags
/SharedWebService/branches
So far this is just a standard SVN layout; each more-or-less independent entity has its own area of the repository to play with. Now, lets assume you've been developing away on the SharedClassLib and you are up to version 2.0.0, and on the SharedWebService you are on version 1.2.5. The directory layout will look something like:
/SharedClassLib/tags/1.0.0
/SharedClassLib/tags/1.5.0
/SharedClassLib/tags/2.0.0
/SharedWebService/tags/1.0.0
/SharedWebService/tags/1.2.0
/SharedWebService/tags/1.2.5
The other tags are just for illustration of the fact that your development has been marching on over time and you've had multiple releases.
Now, back in SolutionA, you have a LocalClassLibrary project and a LocalWebApp project. These projects are strictly part of this solution are are not shared outside of this solution. Taking a stab at a directory layout, your trunk might look something like:
/SolutionA/trunk/SolutionA/<some_solution_level_files>
/SolutionA/trunk/SolutionA/LocalClassLibrary/<some_project_level_files>
/SolutionA/trunk/SolutionA/LocalWebApp/<some_project_level_files>
So, our problem is, how do we get the SharedClassLib and SharedWebService into our SolutionA? By using Subversion externals. Read the externals web page first, then come back here.
To make your life a little easier, I'd suggest creating a svn.externals file in your solution directory to set the svn:externals property if you are doing this from the command line. If you are using some other tool, just keep in mind that in this case, you are going to need to add multiple lines. The file will look like:
SharedClassLib http://your.svn.server/SharedClassLib/tags/2.0.0
SharedWebService http://your.svn.server/SharedWebService/tags/1.2.5
Edit 1: At this point, you can see that the URLs you are referring to are fully qualified. Meaning that they can be separate repositories, and you don't have to use the layout I've described here. Additionally, if you are at an intermediate stage in your development and you need the latest, bleeding edge, development version of your shared code, use an URL like http://your.svn.server/SharedClassLib/trunk
. At some point, however, you are going to want to settle on a sable version of the external code before you tag and release your solution.
Edit 2: Note that this is the pre-1.5 svn syntax. It has changed a bit in 1.5
Do an svn propset svn:externals -F svn.externals .
in your solution directory, then svn commit && svn update
. At this point svn will populate your working copy with the contents of those URLS. Your working copy would look something like:
./SolutionA/svn.externals
./SolutionA/<some_solution_level_files>
./SolutionA/LocalClassLibrary/<some_project_level_files>
./SolutionA/LocalWebApp/<some_project_level_files>
./SolutionA/SharedClassLibrary/<some_project_level_files>
./SolutionA/SharedWebApp/<some_project_level_files>
When you need to bring in new versions of the shared projects, update the svn:externals property appropriately. Please note, there are some caveats to this approach, and are detailed in the SVN externals documentation. Mainly, don't plan on being able to make changes in ./SolutionA/SharedClassLibrary and expect the changes to be magically picked up when you do a commit in SolutionA.
Now you are ready to release SolutionA to the world. Just create the appropriate tag (svn copy) of the trunk to the tags directory:
/SolutionA/tags/1.0.0
Now your SolutionA will have it's own code at the correct tag/version, and you are using the right version of the shared projects for that release.
Obviously, the same discussion applies to SolutionB.
I haven't worked with SVN in a while, so my apologies if I've gotten any of the above a little bit wrong.