在数百个小型应用程序中维护一个公共库

Question

我有一个关于为大量小型应用程序创建公共库的问题。我最近加入了一个 2 人的开发团队。我们即将扩展到 3 个。我们维护了 200 多个应用程序。所有应用程序都支持我们的运营，并且都是内部开发项目。

所有这些应用程序都引用了许多第三方依赖项，例如 dapper、nlog 等……但没有一个引用通用的内部库。

我认为最好将这些第三方包装在外观中以允许可互换性，此外还提供这些应用程序使用的常用功能，例如发送电子邮件、实例化数据库连接等。所有应用程序都将被修改以引用此库.

我认为这有助于增加电子邮件和日志记录等内容的一致性，但是，我不知道如何管理引用单个库版本的 200 个应用程序。

我最初的想法是让所有 200 个应用程序引用相同版本的库，当它的新依赖项（库）发生更改时，CI 构建将自动重建这些库，但据我所知风险太大，TFS 不支持。

我应该允许这 200 个应用程序都引用我创建的公共库的不同版本，还是真的不值得麻烦，让所有应用程序启动它们自己的日志记录、电子邮件发送和审计逻辑？

如果公共库是这方面的最佳实践，当发现错误时，您如何跟踪哪个应用程序使用哪个版本的库等。

---

编辑以澄清潜在的重复问题

潜在的重复问题是关于如何创建一个构建脚本，该脚本将根据更改的依赖项自动构建项目。这个问题首先要问一个需要这种构建机制的通用库是否合适。

Answer 1

您可能会使用 NuGet 使 NLog 等第三方依赖项保持最新。

为什么不将 NuGet 也用于您的内部库？您可以通过合理的努力设置私有 NuGet 提要。

一些公司限制其开发人员可以使用哪些第三方库。因此，他们可能不希望开发人员能够访问官方 NuGet 提要中的所有内容，或者他们可能希望在官方提要之外提供一组专有库。

在这些情况下，您可以设置自定义 NuGet 源，并且可以将 Visual Studio 配置为提供该源，而不是提供该源，或者除了官方源之外。 Feed 可以是本地的（本地计算机上的文件夹或网络文件夹），也可以是远程的（Intranet 或 Internet URL）。

来源：docs.nuget.org

根据您将代码编译到外部数据中心的舒适程度，同一链接中还列出了许多 NuGet 服务提供商。