如何拆分Visual Studio解决方案？

Question

我有一个Visual Studio 2008解决方案，其中包含相互依赖的＆gt; 40 C＃和C ++ / CLI项目。使用该解决方案非常缓慢，通常我一次只需要几个项目。所以我决定将解决方案分成多个包含3-5个项目的解决方案。 我还希望保留所有项目的“完整”解决方案（这对于自动构建或影响所有项目的大型重构操作都很方便。）（这是这里的主要条件。否则，拆分当然，将项目纳入解决方案是微不足道的。）

有没有办法做到这一点？

我的第一个想法是创建新的空解决方案，并将一些现有的项目文件添加到每个解决方案中。但是，如果我这样做，VS再也找不到项目引用（因为它们不在同一个解决方案中）。我可以将引用添加为“普通”文件引用。但是，如果我这样做，我的“完整”解决方案将不再起作用，因为依赖关系会丢失。

修改

谢谢大家的回答。我想澄清一下我的问题：我的解决方案包含44个项目，不包括测试。因此，将它分成两部分并不是我想到的，我更多地考虑5-8个部分。这就是为什么我想保持“完整”的解决方案，VS可以找出完整版本的正确构建顺序。手动维护8个独立解决方案的构建顺序（例如在批处理文件中）似乎容易出错。

此外，我想“按逻辑”对项目进行分组（即我希望将项目通常在一个解决方案中一起修改）。但是这种分组并不总是与依赖性相匹配。例如，假设我有依赖链

A is referenced by B is referenced by C is referenced by D

并想象A和D经常被一起修改，但B和C很少改变。 （显然，B使用的A接口必须保持不变。）然后我想在一个解决方案中使用A和D，在另一个解决方案中使用B和C.但是，只有当我想从头开始构建所有项目时，我才能拥有包含A，B，C和D的完整“完整”解决方案。一旦构建完成，我就可以打开我的A / D解决方案，只编辑/构建这两个项目。

但我担心我的问题没有优雅的解决方案。 （双关语无意）

Answer 1

您可能要考虑的另一种方法是卸载您不使用的项目，只需右键单击并卸载您不使用的项目......这应该会导致Visual Studio更加快捷。它从VS内存中保留了很多东西。

您可以做的其他事情是编辑构建定义并删除所有未修改的项目（取决于您的链接方式......您知道需要/更新/不需要的内容）。

解决方案 - ＆gt;右键单击 - ＆gt; 配置管理器 - ＆gt;由于某些其他原因，取消选中构建任何不会更改且不需要每个构建的项目。这可以通过使用这些项目的最后一个版本的输出来加速构建，从他们将二进制文件转储到哪里。

注意：您仍然可以右键单击项目并构建以更新其输出，然后重新构建解决方案以获取最新信息...您可以执行此操作，而不是来回更改构建配置包括它。

<强>更新
本着走性能路线的精神（例如真的等到VS 2010），您是否采取了其他一些堆栈溢出问题中列出的措施：Very slow compile times on Visual Studio和Visual Studio Optimizations？这些可以产生很大的不同，并且可以在我们wait on VS 2010 to ship时将性能提升到可接受的水平 还有一些可以对性能产生很好影响的事情：

• 我是highly recommend an SSD，如果它是一个选项。它们价格昂贵但绝对值得，解决方案中的文件越多，它们就能获得更多回报。当我们在工作中订购新机器时，整个开发团队使用SSD，差别是惊人的。当你正在处理一个大型解决方案时，它正在围绕将物理磁头切换到数千个位置来驱动驱动器只是为了读取SSD中的文件...这就是SSD获胜的时间，寻求时间实际上是0ms。
• 同样，一个免费的解决方案是一个很好的drafragmenter（只有你在物理上，不整理SSD ）会产生很大的不同...如果你使用的东西是牢记视觉工作室。我推荐MyDefrag（免费软件），因为它的本地算法是进行碎片整理，记住目录结构，所以至少一个物理驱动器不会花费太多时间来转换你的解决方案所需的文件，它们是一切都非常接近磁盘。
• 根据上述SSD的建议，请记住，廉价和快速驱动器之间的SSD性能存在巨大差异，请在此处进行一些研究。不用担心你的系统，使用免费的实用工具such as gParted你可以很容易地移动你的整个操作系统驱动器，而你的旧驱动器仍然是备份...只要SSD能够适应数据你的C，你很好。

Answer 2

您可以制作多个解决方案，并将任何项目添加到您喜欢的每个解决方案中。

您希望构建的项目可能依赖于其他项目。在这种情况下，您需要从使用“项目”引用（引用解决方案中的任何其他项目）更改为使用文件引用（您引用项目已创建的程序集.dll）。

因此，让我们将它们视为“库”（编译一次，然后使用很多），以及“核心”项目（您正在改变很多）。使解决方案包含您的“库”项目，并（最好）添加一个生成后步骤，将生成的调试/发布dll复制到共享库文件夹中。将核心项目添加到新解决方案中。更改所有核心解决方案引用，以通过共享文件夹中的预构建二进制dll引用您的库（请参阅发行版构建dll，以便最终版本正常工作）。

如果更改库，则需要构建库解决方案以重建它，然后使用核心解决方案重建依赖于库的应用程序。 （因此，将经常更改的代码放在核心解决方案而不是库中是个好主意。您可以在项目成熟时将项目移动到以后，和/或如果需要，可以将库存转换为核心项目经过大量修改一段时间）

[2018编辑]目前，可以使用本地nuget或npm服务器分发库，除非有特殊原因不采用这种方法，否则这将是首选选项。

最后一个选项，如果库需要一段时间来构建并且很少更改 ，那就是使它们成为“预编译”库 - 检查最终的dll文件到源代码控制，以及您的团队成员可以获得最新版本并针对库构建，而无需为他们获取或构建源代码。 （要更新这些库，您必须记住在构建之前检查二进制.dll文件，然后在重建之后再次检入它们，因此您必须权衡优势（更快和更容易的日常构建）与缺点（更多的努力来更改库，源代码管理中更大的二进制文件）。

Answer 3

没有好办法做到这一点。这些工具并没有考虑到这一点。相反，您应该尽可能多地将项目组合在一起。尽管代码量相同，但构建运行速度会快很多倍。

你必须克服这样的想法，即需要单独的项目来获得良好的抽象。这似乎是一种非常干净的强制分离方式。但是这个工具链的价格并不值得。请改用语言功能;类，命名空间等。

Answer 4

问题发生三年后，我们的团队仍然面临同样的问题 - 不是编译时间，而是没有好办法将逻辑上分离的东西拆分成单独的解决方案。

我们最终以soldr (open source)的形式构建我们自己的工具，这是一种解决方案间构建工具。它可以选择利用 nuget 来管理您的代码库或自行工作。我们的想法是将您的工作分成尽可能多的解决方案（.sln），这在逻辑上是有意义的。在我们的案例中，我们有一个用于我们的内部框架，然后每个后端库有一个sln，每个产品一个，等等。每个解决方案都有一个“components”目录（类似于nuget“packages”） dir）我们存储当前解决方案正在引用的实际库文件（DLL等）。这些DLL必须从目标sln的依赖关系的新构建更新，以查看新版本。

我们使用our aforementioned build tool而不是手工劳动。使用非常简单的规则和约定，自动推断解决方案之间的依赖关系。然后，它可以正确构建整个依赖关系图（或生成一个MSBuild文件来执行此操作），在每个步骤构建并将输出复制到下一个目标的components目录。我们还添加了用于过滤将要构建的内容的功能（例如，仅构建直接依赖项），打印依赖图，运行单元测试等。

更新：为了利用 nuget ，我们添加了对使用自动推断的依赖项生成nuspec文件的支持。

Answer 5

另一个选择是拥有一个包罗万象的解决方案，并创建不同的构建配置。

窗口顶部是一个组合框，您可以在其中选择“调试”或“发布”构建配置。将其删除并选择“Configuration Manager ...”选项。

在“Active Solution Configuration”下，下拉组合框并选择＆lt; New ...＆gt;。创建一个新配置（例如，称为“CoreOnly”）并选择“Copy settings from”作为“Debug”。 Untick “创建新项目配置”选项。

现在，您的“CoreOnly”构建配置将显示在窗口中。它显示了所有项目的列表。对于您不想构建的任何项目，请取消右侧列中的“Build”复选框。关闭对话框。

现在，要构建所有项目，请从配置下拉列表中选择“Debug”，然后正常构建。当您构建完所有项目后，您可以通过切换到CoreOnly配置来下载仅构建“核心”项目。只要你记得在编辑不在任何核心项目中的代码时构建Debug（所有项目），你就可以了，你的CoreOnly构建会更快。

此方法的缺点是解决方案打开速度非常慢（尽管在Visual Studio 2008，Visual Studio 2010和Visual Studio 2012这是很多比Visual Studio 2005更好，所以你可能没有问题）并且如果你的配置中没有启用项目，它将永远不会被重建所以您的构建（或正在运行的应用程序）可能会崩溃 - 如果您认为已对（或影响）已禁用的项目进行了更改（或影响），则必须记住切换回常规的“构建所有内容”配置。

Answer 6

您应该分离关注点，尤其是在Visual Studio解决方案中对项目进行分组时。我最近在工作中遇到了这个问题，我必须创建一堆单元测试，并且开发人员创建的原始测试包含在解决方案中。起初，我想到了O.K.我只是把我的测试放在这里b / c我知道它会工作，不必担心让依赖正确。但后来在我为每个不同的单元添加了20个测试项目后，我意识到它的构建速度非常慢。

然后我决定为每组测试创建一个解决方案，而不是将它们全部放在一个位置。这也有助于更好地组织代码，以便更容易找到。例如，我创建了一个文件夹'Test＆gt;单位＆gt; MyUnitTest'和'测试＆gt;整合＆gt; MyIntegrationTest“。它不仅可以让您以后轻松找到它，还可以帮助您更快地进行构建。此外，如果有很多人同时处理代码，每个开发人员都可能会更改项目设置和配置，而不会搞乱其他人。

一般规则是在一个特定区域中只有7个或更少的项目组合在一起。如果您有超过7个项目，那么您可以创建另一个子类别，使其更抽象，更容易让人脑一目了然地理解所有复杂的细节（特别是对于刚接触系统的人或者如果你几个月甚至几年后回到这个项目。）

Answer 7

我们在解决方案中有500多个项目。将每个项目保存在单个解决方案中是有好处的，特别是当基础项目发生更改以影响所有其他项目（例如，帮助程序类）时。

我们发现继续使用的最佳方法是将vsFunnel extension用于Visual Studio。它能够在没有项目的情况下加载解决方案。这些项目仍然列在解决方案中，但在需要之前并未实际加载。当项目通过UI打开时，它会按需加载。

真正的诀窍是从vsFunnel UI启用“加载依赖关系”。当您打开一个项目时，它会加载所有依赖项目等，这使得在目标项目上工作变得更加容易。

例如，在我们的500多个项目中，通常我们专注于单个应用程序，它可能有20个依赖项目。只有那些是加载的，而不是整个500 +。

提示：选择加载依赖关系并加载无 - 然后在UI中打开目标项目时，将加载所有相关项目。

这已经证明节省了大量时间（加上SSD驱动器！）

Answer 8

除了这里提到soldr和Funnel我还可以推荐使用 Solution Load Manager。是的，SSD有帮助，但VS有错误：它崩溃，变得反应迟钝，并且在处理100多个项目时出现了其他问题。将重要的事情放在一起进行重大的重构，重建和调试是必须的，但是每天在较小的项目子集上工作将大大提高性能和满意度。

PS。我想知道是否有人制作了比较漏斗与解决方案负载管理器？