组织大型 c# 解决方案答案

【问题标题】：Organising a large c# solution组织大型 c# 解决方案
【发布时间】：2013-03-07 08:29:48
【问题描述】：

我有一个每天在 TFS 中构建的大型解决方案。该解决方案涵盖多个逻辑子解决方案 - 例如由项目 A、B、C、D 组成的 ApplicationA； ApplicationB 由项目 A、B、E、F 组成，ApplicationC 由项目 A、C、G、H 组成。

目前，我们在本地制作构建解决方案文件的副本并卸载我们不需要构建的项目来处理项目 - 因此对于 ApplicationA，我们将卸载除 A、B、C、D 之外的所有内容。

另一种方法是创建多个解决方案配置，这些配置只会为 ApplicationA 构建项目 A、B、C、D - 但我担心这会很麻烦并且 .sln 文件最终会很大。

问题在于，许多项目被整合到一个 wix 包中并一起安装 - 所以主 .sln 文件是有意义的，尤其是从构建的角度来看，而且还包括调试。

维护多个解决方案文件似乎并不正确，因为当添加新项目时，我们需要将它们添加到多个解决方案中。所以也许配置方法是要走的路，但感觉也不对。

有没有人遇到过类似情况，您是如何解决的？

【问题讨论】：

“但是维护多个解决方案文件是不可行的，因为当添加新项目时，我们需要将它们添加到多个解决方案中。”？这真的有那么繁重吗？我一直使用多种解决方案（在处理大量项目时）并且从未发现这非常痛苦。

标签： c# .net

【解决方案1】：

听起来有五个解决方案文件是有意义的：

可以将所有这些解决方案文件放在同一个顶级目录中。

但是维护多个解决方案文件是不可行的，因为当添加新项目时，我们需要将它们添加到多个解决方案中。

为什么会有这样的问题？您需要确定项目需要哪些应用程序......在主解决方案中创建项目（肯定需要它），然后为需要它的解决方案使用“添加现有项目”。真的没有那么多工作 - 而且我不希望经常添加新项目。（如果是，则表明存在更大的问题。）

【讨论】：

谢谢乔恩——我觉得这是正确的前进方向，只是提出了通过配置来做的想法，所以我想调查一下。（顺便说一句 - 喜欢你关于 c# 设计策略视频的书和视频 :)）
@NDJ：配置也可以，但在其他方面很痛苦。（例如，在构建相同程序集的不同版本时，我使用 Noda Time 的配置。）如果只关注少数几个项目，我认为单独的解决方案更有意义。