如何拆分Visual Studio解决方案？

Question

我有一个Visual Studio 2008解决方案,其中包含> 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内存中保留了很多东西.

您可以做的其他事情是编辑构建定义并删除任何未修改的项目(取决于您的链接方式......您知道需要/更新/不需要什么).

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

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

更新
在去表现途径(例如等到2010 VS真),你采取一些其他的堆栈溢出问题中所列措施的精神:非常慢编译在Visual Studio中的时间和Visual Studio的优化？这些可以产生很大的不同,并且可以在我们等待VS 2010发货时将性能提升到可接受的水平.
还有一些可以对性能产生很好影响的事情:

• 如果可以选择,我强烈推荐使用SSD.它们价格昂贵但绝对值得,解决方案中的文件越多,它们就能获得更多回报.当我们在工作中订购新机器时,整个开发团队使用SSD,差别是惊人的.当你正在处理一个大型解决方案时,它正在围绕将物理磁头切换到数千个位置来驱动驱动器只是为了读取SSD中的文件...这就是SSD获胜的时间,寻求时间实际上是0ms.
• 沿着相同的路线,免费的解决方案是一个很好的drafragmenter(仅当您使用的是物理,不要碎片整理SSD),使一个很大的区别...如果你使用的东西,那就是维持视觉工作室的初衷.我建议MyDefrag(免费软件),因为它是为整理磁盘碎片本地算法保持心中的目录结构,所以至少一个物理驱动器不花尽可能多的时间开关周围的蒸汽你在你的解决方案所需要的文件,他们都非常接近上磁盘.
• 根据上述SSD的建议,请记住,在廉价和快速驱动器之间SSD性能存在巨大差异,请在此进行一些研究.不要担心你的系统,有免费的实用工具如的GParted你可以移动整个操作系统赶过来很容易,你的旧驱动器将仍然是一个备份......只要SSD能够适应数据从你的C , 你很厉害.

Answer 2

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

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

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

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

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

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

Answer 3

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

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

Answer 4

在您提出问题三年后，我们的团队仍然面临同样的问题 - 不是编译时间，而是没有好的方法将逻辑上分离的内容拆分为单独的解决方案。

我们最终以soldr（开源）的形式构建了我们自己的工具，这是一种解决方案间构建工具。它可以选择利用nuget来管理您的代码库或独立工作。这个想法是将您的工作拆分为符合逻辑的尽可能多的解决方案（.sln 的）。在我们的例子中，我们有一个用于我们的内部框架，然后每个后端库一个，每个产品一个等等。每个解决方案都有一个“组件”目录（类似于 nuget“包”目录）我们存储当前解决方案引用的实际库文件（DLL 等）。这些 DLL 必须从目标 sln 的依赖项的新版本进行更新才能看到新版本。sln

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

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