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

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

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

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

一些大项目？

每个项目一个解决方案

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

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

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

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

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

应用程序的项目/解决方案结构

文件夹/文件结构

源代码控制的分支结构(如果使用分支)

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

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

源控制

我们有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生成的模块时我们也可以维护该结构,因此世界上一切都很好:-)