共享第三方DLL的NuGet或程序集文件夹？
我有大约10-15个独立解决方案的项目，这些解决方案在微软.NET商店中引用第三方DLL。我们想要解决的问题之一是跨项目使用的DLL版本的一致性（所有项目中的E.G. Netwonsoft 8.0.3，而不是独立版本（取决于何时创建项目））。共享第三方DLL的NuGet或程序集文件夹？
我在前面的位置看到过两种不同的方式，并想知道是否还有其他方法可以解决这个问题。
- 我在公司内的任何项目的解决方案中引用了所有第三方DLL的企业NuGet。 DLL将被更新，然后提供给项目中的开发人员，以便自行解决和升级（如果需要）解决方案。
- 另一家公司在源代码中有一个程序集文件夹，其中包含所有“已批准”的第三方DLL，并且所有引用都位于此目录中。
我没有看到这个问题，但它只是提供了上述两种解决方案之一：Where should you store 3rd party assemblies?
是否有其他的选择除了上面列出的？
尽可能使用NuGet。主要原因在于Git并没有很好地处理大的二进制文件，并且使用LFS并没有什么意义，因为有一个有效的选择。 TFVC对较大的二进制文件的问题较少，但如果您使用TFVC，我会记住未来迁移到Git的问题。
请记住，在这种情况下，不仅NuGet，而且可能还有npm和其他包源。
如果要强制执行某个正在使用的版本，请创建一个自定义任务，并将其挂接到CI管道中。这样，您可以轻松发出警告或设置某种策略。自定义任务可以采用packages.config文件，扫描引用的软件包，然后查询TFS/VSTS软件包管理源以查看它是否使用最新版本（或正在使用最新的次要版本）...（或正在使用至少x版本）...或从某处获取json文件或xml文件中的批准版本，并根据该文件进行验证...
在您的源代码管理中，当存储库第一次填充时，使用所需的依赖项DLL提交并推送到主服务器。因为即使在其他分支上的所有用户都将从存储库中提取数据，所以您可以确保他们能够收到所需的所有DLL。如果你指的是GAC中的DLL，这只会成为一个问题，GACUtil或者只是确保每个人都使用相同的Windows版本。
使用NPM是我认为是可能的绊脚石之一为我们未来的项目和引用的程序集。你认为公司的NuGet服务器将是一个更好的解决方案，以帮助减轻未来的这个问题吗？说实话，我并不熟悉Node或NPM，但仍然掌握了所有这些工作的方法。 – missionearth
我建议使用Proget或使用TFS2017软件包管理功能来设置您自己的NuGet服务器。 – jessehouwing