2

这是一个关于 .NET/git 和构建系统的项目结构的问题，所以我会尽量保持简短：

设置：

  • .NET（C# 和 VB.NET）
  • git（以前的 svn，我们没有使用外部）

我尝试了以下项目结构：

  • [应用名称]
    • .git
    • [NameOfApp - 直接在下面的解决方案文件]
      • [项目1]
      • [项目2]
    • [配置]
    • [标准]：开发人员的一些标准配置（当一个人第一次
      初始化他的仓库时复制它们，但他/她可以更改它们）
    • [脚本]：一些脚本，也是构建系统的脚本
    • [依赖项]
      • [依赖1]：是一个子模块
        • [主文件夹]
          • [解决方案-文件]
            • [项目]
        • [依赖项]
          • [子依赖1]
          • [子依赖2]
            • [依赖2]：另一个子模块
            • [另一种解决方案]：在子模块中，有时我在构建过程中会遇到一些问题。由构建脚本调用。

我正在为我们所有的项目寻找一个好的结构，到目前为止，上述结构仅用于一个项目。

所以我的问题：

  • 看起来这对您来说是一个有效的设置？我知道这是一个难题，但是您是否有类似的设置或类似设置的问题。
  • 你会使用 git 子模块还是有更好的东西？有人说它们是邪恶的，可能会引起问题。仅供参考，我的子模块是许多项目使用的项目。依赖项有时会保存解决方案文件，所以我的项目文件夹不够整洁。然后在我的 mainapp 中引用其中的项目。我不知道子树是否足够，我也听说过 repo (for android)，也许这是一个解决方案？或者还有其他用于管理依赖项的工具吗？
  • 有时我的依赖项也有依赖项。因此，当我进行递归克隆时，我会得到一个带有子依赖项的奇怪结构（参见上面的结构）。有时我必须向我的主应用程序添加子依赖项，因为我想在那里更改某些内容并且依赖项需要重建。那么如何保持子依赖或子子依赖呢？
  • 如果您有开源依赖项（例如来自 github），您是否直接使用 dll？还是你 fork 并添加一个 git 子模块？
  • 您是将所有项目添加为项目引用还是直接引用 dll（例如，为您的子或子子依赖项将其分解一点，而不总是重建整个项目树）？
  • 您更喜欢哪种构建系统？

我知道这些不是一个“正确”答案的问题，但也许你可以帮助我一点并分享一些想法。

谢谢， Cyber​​1000

4

1 回答 1

0

项目结构：自然有递归子模块依赖。否则，子模块必须假设项目结构（硬编码相对路径以匹配父结构）。然后子模块特定于特定项目，但不适用于您开发的所有项目。

子模块：你必须熟悉它。这是必不可少的，因为 dll 缺乏版本控制的可追溯性。子模块可以告诉项目当前正在使用的确切版本（哈希）。

保留子依赖项：不要保留，因为我们的构建服务器总是在每次构建之前运行“git clean”。

open-source-dependencies：fork 并作为子模块使用，我们可能会稍作修改以满足我们的需求。比如工程文件是VS2005，我们用的是VS2010。然后我们更改项目文件并在新版本可用时合并上游分支。

项目参考：如果可能，大部分时间使用项目参考。

构建系统：CruiseControl.NET，作为一个 .NET 人。

于 2012-07-09T08:42:26.477 回答