我有一个关于为大量小型应用程序创建公共库的问题。我最近加入了一个2人的开发团队。我们即将扩展到3.我们维护了200多个应用程序。所有应用程序都支持我们的运营，所有都是内部开发项目。
所有这些应用程序都引用了许多第三方依赖项，例如dapper，nlog等......但是没有一个引用内部库中常见的。
我认为最好将这些第三方包装在外观中以允许可互换性，并且还提供这些应用程序使用的常用功能，例如发送电子邮件，实例化数据库连接等。所有应用程序都将被修改以引用此库。
我认为有助于增加电子邮件和日志记录等内容的一致性，但是，我不知道如何管理引用单个版本库的200个应用程序。
我最初的想法是让所有200个应用程序引用相同版本的库，当它的新的一个依赖项（库）被更改时，它将由CI构建自动重建，但是从我所说的这个风险太大而TFS不支持。
我是否应该允许这200个应用程序全部引用我创建的公共库的各种版本，或者它真的不值得麻烦，让所有应用程序启动自己的日志记录，电子邮件发送和审计逻辑？
如果公共库是最佳实践，那么如何在发现错误时跟踪哪个应用程序使用哪个版本的库？
编辑以澄清潜在的重复问题
潜在的重复问题涉及如何创建一个构建脚本，该脚本将根据其依赖项自动构建项目。这个问题是询问一个需要这种构建机制的公共图书馆是否适合。
答案 0 :(得分：2)
你可能会使用NuGet保持NLog等第三方依赖关系。
为什么不将NuGet用于您的内部图书馆？您可以合理的努力设置私有NuGet源。
有些公司会限制其开发人员可能使用的第三方库。因此，他们可能不希望开发人员访问官方NuGet提要中的所有内容，或者除了官方提要之外，他们可能还有一组他们想要提供的专有库。
在这些情况下，您可以设置自定义NuGet供稿，并且可以将Visual Studio配置为提供该供稿，而不是官方供稿或除官方供稿之外。 Feed可以是本地（本地计算机上的文件夹或网络文件夹），也可以是远程（Intranet或Internet URL）。
根据您将代码编译在外部数据中心的舒适程度，同一链接中还列出了许多NuGet服务提供商。