何时应将项目添加到解决方案中，而不是将项目的dll添加到解决方案中？

Question

我目前有项目A和项目B，同时还有一个类库项目Z。项目Z包含了A和B都使用的类和方法。

我的问题是，我应该将项目Z编译并添加到项目A和B中，使用它的dll文件，还是将项目Z本身添加到A和B中？

在什么情况下，我会使用项目中的项目而不是使用dll中的项目？

- James

---

今天下午我和同事讨论了这个问题。 - John

Answer 1

如果项目Z的代码与A和B的代码在相同的时间表上构建并发布，那么Z很可能应该成为同一解决方案的一部分。

另一方面，如果Z是一个相当稳定的库，并且有自己的发布/维护计划，那么您可能希望将其添加为已编译的引用。

您可以问自己简单的问题，例如Z是否必须每次编译A和B时都进行编译？开发A和B的开发人员是否能够修改Z？

- madd0

---

编译库存在许多缺点。很多时候，查看Z的实现是非常有必要的，如果将其包含为项目，则可以获得更好的调试支持。只有在重新构建时编译开销才会显著。而不同的发布计划可以通过版本控制的分支来进行控制。 - Holstebroe

很不幸，我通过经验学到，并非每个人都像你建议的那样使用源代码控制和/或分支。此外，如果开发A和B的人负责调试Z，他们可能想将项目Z添加到解决方案中。然而，正如我所说，如果库是稳定的，并且有良好的文档，A和B的开发人员不需要永久访问Z，应该专注于自己的代码和错误。 - madd0

Answer 2

根据我的经验，选择项目或者dll的最大区别在于项目内部需要多少透明度。

显然，如果您有编辑项目的潜力，您需要直接访问该项目。但是另一方面，如果您正在调试一个问题，并且您只拥有dll，则您的代码会消失在该dll的黑匣子中并产生结果，不允许您进行步骤。

最终，通常是个人偏好问题。如果您足够自信，在调试或错误搜索时不需要进入dll的黑匣子，并且希望更清洁的解决方案资源管理器，则可以简单地将其作为dll包含。这也可以加快编译时间，因为它不必将特定项目编译成dll以进行调试/发布等。如果您不介意额外的混乱（和更长的构建时间），或者需要透明度，则建议将其包含为项目。

至于我个人的喜好，我倾向于不介意更长的构建时间和更混乱的解决方案资源管理器，并在有可能的情况下添加项目而不是dll。

- guildsbounty

---

一旦 Z 被构建完成，额外的构建时间最多只会是几秒钟。除非 Z 很好地被记录下来，否则你肯定会想要时不时地查看代码。 - Holstebroe

Answer 3

我建议您使用版本控制系统将Z分支并将其添加为项目。这样，您就可以兼顾两者的优点。您可以进行完整的调试，并且可以编辑库，如果在其他解决方案中更新了Z接口，则A和B项目不会受到影响。

如果您对Z进行更新，可以以受控的方式将其与其他版本合并。

除非Z有极好的文档，否则在编写A和B代码时，您肯定希望在Z代码中进出。

只有当Z非常庞大且重新编译需要很长时间时，我才喜欢将其包含为DLL。

- Holstebroe

Answer 4

我认为如果Z被A和B同时使用（假设A和B在不同的解决方案中），那么你应该将Z添加为dll。这样，你只需要在一个地方编辑代码，而不是两个地方，并且你可以确保A和B使用相同版本的Z库（再次假设你在两个地方都更新了dll ;))

- Adrian Serafin

Answer 5

我虽然不是专家，但我的一般经验法则是：

• 如果A和B密切相关，并且Z主要存在于支持它们，那么A和B都可以使用对Z项目的引用。
• 如果A和B不是密切相关的，Z是为了支持A而创建的，后来发现对B也有用处，那么A使用对Z项目的引用，而B使用对Z dll的引用。
• 如果Z被创建为一个独立的库，旨在为可能会发现它有用的所有项目提供支持，那么所有项目都使用对Z dll的引用。

我之所以这样做的原因是确保每个项目都与正确版本的库相连。

您正在使用哪种形式的源代码控制也可能是一个因素。根据整体情况和系统的能力，将Z分支到两个项目中可能是一个好的解决方案。

- Rozwel