0

更新：

所以事实证明，我们可能在 Visual Studio 2003 中发现了一个错误（我知道……这并不奇怪）。我们发现，如果使用 Visual Studio（使用将解决方案添加到源代码管理）将解决方案添加到存储库中，一切都很好......去图吧。

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

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

  • //仓库
    • 开发主程序
      • 解决方案1
        • Project1（构建到 DLL）
      • 解决方案 2（以 Project1 作为项目参考）
        • 项目2
      • 解决方案 3（以 Project1 作为项目参考）
        • 项目3

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

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

谢谢。

4

4 回答 4

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 包含“外部”库 - 项目引用中包含的第 3 方库。Src 包含属于特定产品的所有项目的平面列表。然后使用解决方案以多种方式“组合”项目。我将 src 目录视为具有“可用内容”的容器，然后从该容器中挑选解决方案并组合项目（根据需要）。

在多个产品之间共享的库进入共享目录。一旦进入共享目录，它们就被视为独立于产品——它们有自己的发布周期，并且永远不会作为源加入产品。通过将共享库发布程序集/程序集分支到产品的lib目录中，将共享库拉入产品 -> 从产品的角度来看，第 3 方库和共享库之间没有区别。这使我们能够控制哪些产品正在使用哪个版本的共享库（当产品需要新功能时，它必须明确分支到共享库的新版本中，就像它包含新版本的第 3 方库一样，以及随之而来的所有优点和缺点）。

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

  • 产品本地的项目，由多个解决方案使用（包含在 src 目录中的平面项目列表中，多个解决方案可以引用它们）
  • 多个产品使用的项目（添加到共享目录，被视为具有独立于产品版本的第 3 方库）
于 2009-03-04T15:19:36.750 回答
0

我不太了解将 Visual Studio 与 Perforce 结合使用，但您可以考虑在需要时创建将 Project1 映射到 Solution2、Solution3 等的工作区视图。

于 2009-01-21T19:53:29.023 回答
0

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.

于 2009-01-23T09:04:53.730 回答
0

解决方案应该是在每次将 Solution1 添加到新项目时将其重新绑定到源代码控制服务器。（它在文件-> 源代码管理-> 更改源代码管理下。）

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

于 2009-01-20T20:02:54.777 回答