Question

更新：

事实证明我们可能在Visual Studio 2003中发现了一个错误（我知道......毫不奇怪）。我们发现，如果使用Visual Studio将解决方案添加到存储库（使用Add Solution to Source Control），一切都很顺利......去图。

因此我们将我们的VSS存储库（如果可以调用它）转换为Perforce，并且我们遇到了多个解决方案中包含的项目的问题。

我们的存储库可能看起来像这样......

//仓库
- DevMain
  - 解决方法1
    - Project1（构建到DLL）
  - Solution2（Project1作为项目参考）
    - Project2的
  - Solution3（Project1作为项目参考）
    - 项目3

在Visual Studio for Solution2中使用集成的源代码控制时，它会抱怨项目不在当前的解决方案文件夹下，我们可能想要移动它。因为多个解决方案引用了项目1，所以我们永远无法在一个解决方案不会抱怨的情况下组织它......

将Project1构建为DLL并将其存储在Lib文件夹中是最佳做法吗？或者有更好的方法吗？

感谢。

Answer 1

我们遇到了类似的问题并且正在接近它，就像@Toby Allen在他的回答中提到的那样，通过客户端规范。然而，随着时间的推移，这变得非常痛苦（随着客户规格变得越来越复杂，建立新的团队成员变得越来越困难;自动化也变得更加复杂，因为事情是......“不断变化”:-)）。

最终，我们改进了使用目录结构和分支的策略。目录结构如下：

//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)

请注意，在整个结构（doc / lib / src / solutions）中重复相同的结构。 Lib包含“外部”库 - 项目引用中包含的第三方库。 Src包含属于特定产品的所有项目的平面列表。然后使用解决方案以多种方式“组合”项目。我认为src目录是一个具有“可用内容”的容器，然后解决方案从这个容器中挑选并组合项目（根据需要）。

多个产品共享的库进入共享目录。进入共享目录后，它们将被视为独立于产品 - 它们具有自己的发布周期，并且永远不会作为源加入产品。通过将共享库发布程序集/程序集分支到产品的 lib 目录 - ＆gt;中，可以将共享库纳入产品中。从产品的角度来看，第三方库和共享库之间没有区别。这允许我们控制使用什么版本的共享库的产品（当产品需要新功能时，它必须在新版本的共享库中明确分支，就像它包含新版本的第三方库一样，与它一起使用的所有优点和缺点。）

总之，我们的结构具有两种“类型”共享库的概念：

项目的本地项目，由多个解决方案使用（包含在src目录中的项目的平面列表中，多个解决方案可以引用它们）
多个产品使用的项目（添加到共享目录，被视为第三方库，其中包含与产品无关的版本）

Answer 2

解决方案应该是每次将Solution1添加到新项目时将Solution1重新绑定到源控制服务器。（它位于File-＆gt; Source Control-＆gt; Change Source Control。）

每个解决方案每个桌面只需要执行一次。

Answer 3

我对使用Perforce使用Visual Studio了解不多，但您可以考虑创建工作区视图，将Project1映射到Solution2，Solution3等，如果需要。

Answer 4

如果我理解正确，您希望文件在磁盘上的存储方式与Perforce中的文件存储方式不同。如果是这种情况，并且你不能简单地重新定义VS中的引用，那么一个设计巧妙的客户端就可以做到这一点。

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/...

这将为您提供一个结构，其中Solution1是解决方案2的子目录。

Perforce，Projects在多个解决方案之间共享

4 个答案: