c# - 管理解决方案/引用

Question

我想创建实用程序类库(例如，日志记录等)。
我想在几个独立的应用程序中使用 utils 解决方案。

我当然在使用源代码管理...

• 这是否意味着我应该管理 utils 解决方案(持有 utils 类库)以及每个应用程序的单独解决方案？

• 我需要做什么才能使用 ApplicationA 解决方案中的 utils 类库

• ApplicationA 解决方案是否也可以包含 utils 解决方案(例如，去定义工程？)

• 如果可能，这是否意味着任何更改 proggrammerA 通过 ApplicatioA 解决方案应用到 utils 库，也会影响使用相同 utils 类库的 ApplicationB 解决方案

• 当我们修复 utils 解决方案中的错误时，我们该怎么办？如何修复 ApplicationA 和 B 的气泡。

Answer 1

听起来您已经确定了可能的方法:

• 开发和管理独立于任何特定应用程序的实用程序库。

  • 优点:无需管理多个版本，在一个解决方案中完成的更新不会影响/破坏其他解决方案
  • 缺点:Utilities 程序集本质上是一个封闭的盒子，是您的应用程序正在使用的组件，与任何第三方或 .NET Framework 程序集相同。

• 将您的 Utilities 库项目置于源代码管理中，并将每个应用程序的解决方案作为项目引用包括在内(这是可能的，以回答您上面的问题)。

  • 优点:实用程序库在所有项目中保持最新，并且可以在调试等过程中逐步进入。
  • 缺点:在一个项目的开发过程中对实用程序所做的更改可能会破坏另一个项目。此外，这可能会增加版本控制问题，您可能需要回滚补丁构建的更改等。
• 为每个项目创建实用程序库的新副本
  • 优点:构建、调试、部署或版本控制没有问题
  • 缺点:对一个项目中的实用程序所做的更改不会反射(reflect)在其他项目中，如果需要，必须手动复制过来。

归根结底，没有一个正确答案；这取决于您的实用方法的稳定性、它们需要更改的频率以及您希望/需要调试它们的频率。

在大多数情况下，我发现为每个项目创建实用程序类库的新副本更为方便。它们最终会有所不同，但易于维护弥补了所有项目之间缺乏一致性。如果您有一组非常复杂的实用程序类来封装您的业务的某些部分，您可能希望采用另一种方式并独立维护它。