管理反射属地的属地

Question

我目前使用的是一个大型解决方案，包含大约100个项目。至少有10个项目是可执行的应用程序。一些库项目是通过MEF和反射而不是直接引用作为插件导入的。如果所需插件本身的依赖项没有被复制到可执行项目的输出或插件目录中，我们将在运行时得到反射错误。

我们已经尝试或讨论过以下解决方案，但这些解决方案似乎都不合适：

1. “硬”引用：最初，我们有可执行项目引用它们需要的其他项目，即使它们最终将作为可选插件导入。这很快就失去了团队成员的青睐，他们需要构建排除某些插件的构建，并且喜欢从一开始就卸载这些项目。这也使得很难使用Resharper或其他工具来清除未使用的引用和删除过时的第三方库，而不会意外地将“未使用”的引用吹走到所需的插件本身的依赖项。
2. 构建后复制(使用预构建的“拉”)：在一段短时间内，一名高级团队成员将所有插件项目设置为将其输出自身复制到一个已知的"DependencyInjection“文件夹中，称为”构建后事件“。需要这些插件的项目会有预构建事件，将每个想要的插件复制到自己的输出目录中。虽然这意味着插件项目“正确”不知道它们可能在哪里使用，但这引起了两个主要问题。首先，当一个插件项目发生变化时，他们必须分别构建(顺序)插件项目，然后是他们要在其中测试的可执行项目(以获得文件复制)。重建一切都会更方便，但速度太慢。第二，持续集成构建必须重新配置，因为它编译了所有目录中的所有内容，并且只关心所有构建是否成功。
3. 构建后复制(push)：目前的解决方案从xcopy开始，现在主要是在插件项目的构建后事件中使用机器人复制来将所需的文件直接复制到使用它们的可执行项目的插件文件夹中。这是很好的工作，如果一个人改变了一个插件，你可以直接去运行调试器。此外，CI构建不会中断，用户禁用某些用于各种构建的“可选”插件项目不会因为缺少引用而获得构建错误。这似乎仍然很麻烦，而且在所有单独的构建后窗口中维护都很麻烦，因为这些窗口非常小，无法扩展。当可执行项目从项目重组或重命名时，我们直到第二天听到夜间自动化测试的结果后才能发现是否有中断的引用。
4. 带有引用的“虚拟”项目--：一个简单的想法是为每个不同的可执行构建配置创建空项目，然后返回到这些配置的硬引用方法。每个用户都会使用自己的引用来收集插件及其依赖项。他们还将引用实际的可执行文件并复制它。然后，如果希望在特定配置中运行特定的可执行文件，则需要运行其虚拟项目。这个似乎特别臃肿，从来没有尝试过。
5. NuGet ：在我对NuGet的熟悉程度有限的情况下，这似乎很适合使用软件包，但我不知道如何在内部实现该解决方案。我们已经讨论过要打破这个解决方案，但是团队中的许多成员都强烈反对。对来自同一解决方案中的包使用NuGet是否可能？

在这种情况下，最佳实践是什么？是否有比上述任何一种更好的解决方案来管理反射依赖项的依赖关系，或者对上面的一项进行细化是最好的选择？

Answer 1

好的，在这个答案中，我假设每个开发人员需要在本地不断地拥有所有100个程序集(调试模式)来完成它的工作(开发、编译、冒烟测试、运行自动测试)。

您提到RebuildAll需要很长的时间。通常，这种症状是由太多的程序集+构建过程导致的，而不是合理化的。因此，首先要做的是尝试将100个程序集合并到尽可能少的程序集中，并避免使用Copy Local = true之类的东西。其效果将是一个更快(如10倍)的RebuildAll进程。请记住，程序集是物理制品，它们只对物理事物有用(例如插件、按需加载、测试/应用程序分离……)。我写了一本白皮书，详细介绍了我对这个主题的想法：http://www.ndepend.com/WhiteBooks.aspx。

通过.NET程序集和Visual项目划分代码库(8页)

• 创建程序集的常见有效和无效原因
• 提高Visual解决方案编译性能(提高到x10的速度)
• 组织开发环境

在白皮书的建议中，一个想法是避免引用项目，而是引用程序集。这样，您就有责任填写项目>右键单击>项目依赖项，这将定义项目>右键单击>项目构建顺序。如果您决定继续处理100个程序集，则定义此设置代表了一种努力，但作为奖励，高级(可执行)项目可以依赖于一个仅由反射使用的库，这将解决您的问题。

你量过按PDB序列点#表示的代码行了吗？我估计，在200 K到300 K的极限范围内，做一个RebuildAll (在白皮书中进行了优化)应该需要5到10秒(在一台像样的笔记本电脑上)，而且它仍然可以接受。如果您的代码库非常大，并且超出了这个限制，那么您将需要打破我的第一个假设，找到一种开发人员不需要所有程序集来完成其工作的方法(在这种情况下，我们可以进一步讨论这个问题)。

免责声明:这个答案引用了我创建并管理其开发的工具NDepend站点上的资源。

Answer 2

我一直处于像你这样的情况。我们有将近100个项目。我们也在使用MEF和System.AddIn。一开始我们有一些解决办法。我正在研究核心解决方案，其中包括核心程序集及其测试。在一个单独的解决方案中的每个插件类别，包括契约，实现(一些插件有多个实现)和测试，以及一些测试主机以及核心程序集。稍后，我们添加了一个包含所有项目的解决方案，在尝试了您提到的几种方法之后，我们决定执行以下操作：

1. 保留强制性的引用，
2. 所有可执行项目都被设置为输出到公共位置(一个用于调试，另一个用于发行配置)，
3. 所有不应该引用的项目都被设置为输出到这些公共位置，
4. 其他人引用的所有项目都保持不变，每个引用都使用Copy Local = true设置。
5. 测试没有改变。

虽然建造都很慢，但我们没有任何其他问题。当然，拥有将近100个项目是一个迹象，表明设计可能过于模块化，正如Patrick建议的那样，我们应该尝试压缩它。

无论如何，您可以在几个小时内尝试这种方法，也许可以不设置Copy Local = true，而是尝试将4中提到的所有项目的输出文件夹设置为公共位置。我们不知道这个设置会像Patrick提到的那样减慢构建过程。

PS。我们从未尝试使用NuGet，因为我们没有足够的资源和时间来尝试它。不过看上去很有希望。

Answer 3

我们正在启动一个新的项目，我正在寻找这个类似问题的“最佳实践”解决方案。对我们来说，我们可以将项目分为两类:一是平台组件，它提供全面的公共服务集；二是垂直组件，它将执行特定于业务的功能。

在过去，我们使用了Visual插件和一个简单的UI，允许开发人员指定公共程序集路径来复制输出程序集，然后从公共程序集文件夹中引用所有程序集(无论它们驻留在不同的解决方案中)。

我正在看NUGET，但你必须做的纯粹的工作，以创建和维护NUGET包是惩罚性的。

这是一个非常常见的场景，很有兴趣看看其他人是如何解决这个问题的。