更新:
这是我访问量最大的问题之一，但我仍然没有真正为我的项目找到令人满意的解决方案。我在另一个问题的答案中读到的一个想法是创建一个工具，该工具可以为您从列表中选择的项目“即时”构建解决方案。不过，我还没有尝试过。
如何构建一个非常大的应用程序？
以及在没有一种解决方案的情况下如何管理依赖项。
注意:我正在寻找基于经验的建议，而不是您在 Google 上找到的答案(我可以自己做)。
我目前正在开发一个应用程序，它有超过 80 个 dll，每个都有自己的解决方案。管理依赖项几乎是一项全职工作。有一个自定义的内部“源代码控制”，添加了用于在各处复制依赖 dll 的功能。对我来说似乎是一个次优的解决方案，但有更好的方法吗？我担心，在实践中处理一个包含 80 个项目的解决方案会非常困难。
(上下文:winforms，而不是 web)
编辑:(如果您认为这是一个不同的问题，请给我留言)
在我看来，以下之间存在相互依赖关系:
但是，如果可能的话，我很难将它们分开来单独考虑。
我问了另一个相关问题here .
最佳答案
源代码管理
我们有 20 或 30 个项目被构建到 4 或 5 个离散解决方案中。我们正在为 SCM 使用 Subversion。
1) 我们在 SVN 中有一棵树，其中包含按 namespace 和项目名称逻辑组织的所有项目。根目录中有一个 .sln 可以构建它们，但这不是必需的。
2) 对于每个实际解决方案，我们在 SVN 中都有一个新的 trunks 文件夹，其中包含 SVN:对所有必需项目的外部引用，以便它们从主树下的位置更新。
3) 在每个解决方案中是 .sln 文件加上一些其他必需的文件，以及该解决方案独有且不跨解决方案共享的任何代码。
拥有许多较小的项目有时会有点痛苦(例如，TortoiseSVN 更新消息会被所有这些外部链接弄乱)但确实具有不允许循环依赖的巨大优势，因此我们的 UI 项目依赖于 BO项目，但 BO 项目不能引用 UI(也不应该!)。
建筑
我们已经完全切换到使用 MS SCSF and CAB enterprise模式来管理我们的各种项目在 Win Forms 界面中组合和交互的方式。我不确定你是否有同样的问题(多个模块需要在一个通用表单环境中共享空间)，但如果你这样做了，那么这很可能会给你如何构建和组装你的解决方案带来一些理智和惯例。
我提到这是因为 SCSF 倾向于将 BO 和 UI 类型的函数合并到同一个模块中，而之前我们保持严格的 3 级策略:
FW - 框架代码。功能与软件相关的代码。
BO - 业务对象。其功能与问题域关注点相关的代码。
UI - 与 UI 相关的代码。
在那种情况下，依赖关系严格是 UI -> BO -> FW
我们发现即使在使用 SCSF 生成的模块时我们也可以保持这种结构，所以世界上一切都很好:-)
关于visual-studio - 在 C# 中构建大型 Winforms 应用程序的项目和依赖项，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/152053/