Perforce, Projects shared among multiple Solutions

Question

UPDATE:

So it turns out that we may have found a bug in Visual Studio 2003 (I know...no surprise). We found out that if the solutions were added to the repository using Visual Studio (using Add Solution to Source Control) everything went fine...go figure.

---

So we're converting our VSS repository (if it can be called that) to Perforce and we're running into issues with projects included in multiple solutions.

Our repository might look like this...

• //Depot
  • DevMain
    • Solution1
      • Project1 (Builds to a DLL)
    • Solution2 (Has Project1 as a project reference)
      • Project2
    • Solution3 (Has Project1 as a project reference)
      • Project3

When using the integrated Source Control in Visual Studio for Solution2 it complains that the projects are not under the current solutions folder and we may want to move it. Because multiple solutions reference Project 1 we can never organize it where one solution won't complain...

Is the best practice to just build Project1 to DLL and store it in a Lib folder? Or is there a better way?

Thanks.

Answer 1

The solution should be to rebind Solution1 to the source control server each time it's added to a new project. (It's under File->Source Control->Change Source Control.)

This should only need to be done once per desktop per solution.

Answer 2

I don't know much about using Visual Studio with Perforce, but you might consider creating workspace views that map Project1 into Solution2, Solution3, etc., where needed.

Answer 3

If I understand correctly you want how your files are stored on disk to differ from how it is stored in Perforce. If this is the case, and you cant simply redefine the reference within VS, then a cleverly designed client can do the trick.

Client: Client_Solution2

Description:
Created by Me.

Root:   C:/Development/Solutions

View:
//depot/Devmain/Solution1/... //Client_Solution2/Solution2/Solution1/...
    //depot/Devmain/Solution2/... //Client_Solution2/Solution2/...

This will give you a structure where Solution1 is a sub directory of solution 2.

Answer 4

We had a similar problem and were approaching it very much like @Toby Allen mentions in his answer, via client specs. However, in time this becomes very painful (setting up a new team member becomes more and more difficult as client specs become more and more convoluted; also automation is much more complicated because things are... "in flux" :-) ).

Eventually, we evolved our strategy to use a directory structure and branching instead. The directory structure is as follows:

//depot
    /products
        /(product_name)
            /doc
            /lib
                /(3rd_party_libname)
                    (DLLs)
                /(another_3rd_party_libname)
                    (DLLs)
            /src
                /Project1
                    (files, csproj, vbproj, etc)
                /Project2
                    (files, csproj, vbproj, etc)
                /Project3
                    (files, csproj, vbproj, etc)
            Solution1.sln (includes src/Project1)
            Solution2.sln (includes src/Project1, src/Project2)
            Solution3.sln (includes src/Project1, src/Project3)
        /(another_product_name)
            /doc
            /lib
            /src
            (solutions)
    /shared
        /(shared_lib_name)
            /doc
            /lib
            /src
            (solutions)
        /(another_shared_lib_name)
            /doc
            /lib
            /src
            (solutions)

Note that the same structure is repeated throughout the structure (doc/lib/src/solutions). Lib contains "external" libraries - 3rd party libraries that are included in project references. Src contains a flat list of all projects that are part of a particular product. Solutions are then used to "combine" projects in any number of ways. I think of src directory as a container with "what is available", solutions are then picking from this container and combining projects (as needed).

Libraries that are shared among multiple products go into shared directory. Once in shared directory, they are treated as independent from products - they have their own release cycle and are never joined to products as source. Shared libraries are pulled into products by branching the shared library release assembly/assemblies into product's lib directory -> from product's perspective there is no difference between a 3rd party library and a shared library. This allows us to control what product is using what version of a shared library (when a product wants new features, it has to explicitely branch in newer release of a shared library, just like it would include a new release of a 3rd party library, with all pros and cons that go with it).

In summary, our structure has concept of two "types" of shared libraries:

• projects local to a product, used by multiple solutions (included in a flat list of projects in src directory, multiple solutions can reference them)
• projects used by multiple products (added to shared directory, treated as 3rd party libraries with releases independant from products)