Questions about reorganizing Visual SourceSafe projects

I have inherited a very disorganized VSS database and I need to clean it up. Before I finalize my reorganization, I would like to get some guidance so I don't make similar mistakes as the previous person. I'm going to move everything to a new instance of VSS and start fresh. Historical information isn't a concern, so it is understood that the fresh install will not include history of prior versions. (The current VSS db will be available if needed.)

We are currently using Visual Studio 2005 and Visual Source Safe 2005. We'll be moving to VS2010 and perhaps TFS, but first steps first.

We have three ASP.NET products, each of which share multiple libraries. Here's the basic structure of the projects:

PRODUCT 1  
    References:  
        Library 1  
          References:  
            Library 4  
            Library 5  
        Library 2  
        Library 3  

PRODUCT 2  
    References  
        Library 1  
            References:  
                Library 4  
                Library 5  
        Library 3  
        Library 6  

PRODUCT 3  
    References  
        Library 5  
        Library 3  

As a first step I have all of the products and libraries "Unbound" from VSS and have structured them in folders as follows. (There are 3 developers and we'll all setup the same folder structure on our machines.)

C:\Source\Products\Product1  
C:\Source\Products\Product2  
C:\Source\Products\Product3  
C:\Source\Libraries\Library1  
C:\Source\Libraries\Library2  
...  
C:\Source\Libraries\Library5  

Each Product and Each library has it's own solution; project references are used for all referenced libraries. For example, the solution for PRODUCT 1 includes project references for Libraries 1, 2, 3, 4, and 5. The solution for Library 1 has project references for Libraries 4 and 5 and so on. Everything builds at this point.

Question: Is it common practice for PRODUCT 1 to include project references for Libraries 4 and 5 even though it doesn't reference them directly (Yet one of its referenced projects does)?

I plan to setup a parallel structure in VSS:

$\Prodcuts\Product1  
...  
$\Libraries\Libra开发者_Go百科ry5  

Question: Is this a logical structure to be using? If not, what should I do different.

Thanks in advance for your input.

Darvis

---

Question: Is it common practice for PRODUCT 1 to include project references for Libraries 4 and 5 even though it doesn't reference them directly (Yet one of its referenced projects does)?

Yes it is, it is even required for certain tasks, like code analysis in VS2010. The build process will exclude any directly unused reference anyway (not a reason for not cleaning it up, but it's kind of supported that not all the project references listed are used directly when building the project).

If you work in VB.NET, you can automatically clean the references (but you can easily break code analysis capabilities, and I encountered cases where it was just not working well), in C# the ability to clean project references is not built-in (certain (non-free) plug-ins do it like Resharper)

Question: Is this a logical structure to be using? If not, what should I do different.

(Maybe it should be a separate question on programmers, as it is kinda subjective, but I'll answer anyway :) )

I don't see any problem in your logic. Personally I don't split library projects and executable projects. They are just projects. It's really a matter of personal preference, others would split it by Clients, Platforms, etc. But as long as people can see the logic behind what you are doing, and I don't think you will encounter any more problem with it while using VSS.