管理解决方案/参考

Question

我想创建utils类库（例如，日志记录等） 我想在几个不同的应用程序中使用utils解决方案。

我当然正在使用源代码控制...

• 这是否意味着我应该管理utils解决方案（持有utils类库） 并为每个申请单独解决？

• 如何使用ApplicationA解决方案中的utils类库

• ApplicationA解决方案还可以包含utils解决方案（例如，转到定义工作吗？）

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

• 我们在修复utils解决方案中的错误时该怎么办？ 如何修复泡沫到ApplicationA和B.

Answer 1

听起来你已经确定了可能的方法：

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

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

• 将您的Utilities库项目置于源代码管理中，让每个应用程序的解决方案都将其作为项目参考包含（这是可能的，以回答上面的问题）。

  • 优点：实用程序库在所有项目中都保持最新，并且可以在调试期间进入等等。
  • 缺点：作为一个项目开发的一部分而对公用事业进行的更改可能会破坏另一个项目。此外，这可能会增加版本控制问题，您可能需要回滚补丁版本的更改等。
• 为每个项目创建Utilities库的新副本
  • 优点：构建，调试，部署或版本控制没有问题
  • 缺点：在一个项目中对Utilities所做的更改不会反映在其他项目中，必要时必须手动复制。

在一天结束时，没有一个正确答案;这取决于您的实用程序方法的稳定性，它们需要更改的频率，以及您希望/需要调试它们的频率。

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

Answer 2

我认为您需要了解如何分发API以供使用。你应该把它作为一个单独的项目。版本就是你如何向公众发布的东西。如果您在utils中进行更改并且在AppA中需要它，那很好，只要知道在使用AppB进行测试之前，您将需要使用分支或旧版本的util类。