在C#中构建大型winforms应用程序的项目和依赖项

Question

更新:
这是我最常访问的问题之一,但我仍然没有找到一个令人满意的解决方案.我在回答另一个问题时读到的一个想法是创建一个工具,可以为您从列表中选择的项目"动态"构建解决方案.我还没试过.

---

你如何构建一个非常大的应用程序？

• 一个大解决方案中的多个小型项目/组件？
• 一些大项目？
• 每个项目一个解决方案

在没有一个解决方案的情况下,如何管理依赖关系.注意:我正在寻找基于经验的建议,而不是您在Google上找到的答案(我可以自己做).

我目前正在开发一个应用程序,它有80个dll,每个都在自己的解决方案中.管理依赖项几乎是一项全职工作.有一个自定义的内部"源代码控制",增加了复制依赖dll的功能.对我来说似乎是次优解决方案,但有更好的方法吗？我担心,在实践中制定一个包含80个项目的解决方案将非常粗糙.

(上下文:winforms,而不是web)

编辑:( 如果您认为这是一个不同的问题,请给我留言)

在我看来,之间存在相互依存关系:

• 应用程序的项目/解决方案结构
• 文件夹/文件结构
• 源代码控制的分支结构(如果使用分支)

但是如果可能的话,我很难将它们分开来单独考虑它们.

我在这里问过另一个相关的问题.

Answer 1

源控制

我们有20或30个项目被构建到4或5个分立解决方案中.我们正在使用Subversion for SCM.

1)我们在SVN中有一个树,包含按命名空间和项目名称逻辑组织的所有项目.根目录下有一个.sln可以构建它们,但这不是必需的.

2)对于每个实际的解决方案,我们在SVN中有一个新的中继文件夹和SVN:对所有必需项目的外部引用,以便从主树下的位置更新它们.

3)在每个解决方案中都有.sln文件以及一些其他必需文件,以及该解决方案独有且不在解决方案之间共享的任何代码.

有许多较小的项目有时会有点痛苦(例如,TortoiseSVN更新消息会使所有这些外部链接变得混乱)但确实具有不允许循环的依赖性的巨大优势,因此我们的UI项目依赖于BO项目,但BO项目不能引用UI(也不应该!).

架构 我们已完全切换到使用MS SCSF和CAB企业模式来管理我们的各种项目在Win Forms界面中组合和交互的方式.我不确定您是否遇到相同的问题(多个模块需要在通用表单环境中共享空间),但如果您这样做,那么这可能会为您构建和组装解决方案带来一些理智和惯例.

我提到这是因为SCSF倾向于将BO和UI类型函数合并到同一个模块中,而之前我们维护了严格的3级策略:

FW - 框架代码.其功能与软件问题相关的代码.BO - Business Objects.其功能与问题域关注相关的代码.UI - 与UI相关的代码.

在那种情况下,依赖性严格来说是UI - > BO - > FW

我们发现即使在使用SCSF生成的模块时我们也可以维护该结构,因此世界上一切都很好:-)

Answer 2

我认为拥有一个包含所有 80 个项目的解决方案非常重要，即使大多数开发人员大部分时间都使用其他解决方案。根据我的经验，我倾向于使用一个大型解决方案，但为了避免每次按 F5 时重建所有项目的痛苦，我转到解决方案资源管理器，右键单击我现在不感兴趣的项目，并执行“卸载项目”。这样，该项目就会保留在解决方案中，但不会花费我任何费用。

话虽如此，80已经是一个很大的数字了。根据这 80 个子系统分解的程度，我还可能创建其他解决方案文件，每个文件都包含一个有意义的子集。这将节省我大量的右键单击/卸载操作的精力。然而，事实上，您拥有一个大的解决方案，这意味着始终对它们的相互依赖关系有一个明确的看法。

在我使用过的所有源代码控制系统中，它们的 VS 集成选择将 .sln 文件置于源代码控制中，并且许多系统无法正常工作，除非该 .sln 文件位于源代码控制中。我觉得这很有趣，因为 .sln 文件过去被认为是个人的东西，而不是项目范围的东西。我认为唯一一种绝对值得源代码控制的 .sln 文件是包含所有项目的“一大解决方案”。例如，您可以将其用于自动构建。正如我所说，个人可能会为了方便而创建自己的解决方案，我并不反对那些进入源代码控制的解决方案，但它们对个人比对项目更有意义。