如何在大型代码库中组织外部库

Question

只是想知道社区在一个大团队中工作并使用数十种不同的解决方案时如何组织 .net DLL 库？

我特别好奇人们是否选择某种“库”文件夹来包含所有项目使用的所有外部 DLL，以及人们是否对其 DLL 进行版本控制，或者在 DLL 发布新版本时只是覆盖 DLL，并希望下次重新编译时的 .NET 解决方案会选择此问题，

我也不清楚您是否可以简单地将不同版本的 DLL 放入文件夹中并让解决方案选择此问题，或者 .net 是否强制您使用特定版本（注意：我们不需要签署我们的任何程序集）

Answer 1

我在我们的存储库中有一个专门的文件夹，用于存放所有项目都可以引用的第三方库和 DLL。

至于版本控制，我会根据具体情况进行处理。对于一些不经常更新的库或者我不打算在最新版本发布时更新到最新版本的库，我只是将 DLL 放在那里。
然而，对于经常更新的主要库，我通常采用以下模式：

<LibName>/Current/<LibName>.dll
<LibName>/v1.1/<LibName>.dll
<LibName>/v1.2/<LibName>.dll

大多数项目将简单地引用“Current”文件夹中的 dll。但是，如果出现问题，他们可以参考较旧的问题。这样做的好处是，如果您发现问题，可以很容易地切换参考以查看它是否存在于旧版本中。

注意：如果一个项目依赖于另一个项目，您需要在项目之间使用相同的版本，因此最好尽可能尝试使所有内容都使用最新版本。

Answer 2

当前通常有一个 Libs 目录，该目录与解决方案的其余部分以及每个项目中对 DLL 的相对引用进行签入。只要新版本具有相同的名称，它就会被选取 - 只需确保解决方案中的所有项目都引用相同的路径即可。

但是展望未来，新兴的最佳实践将是使用 NuGet 来管理您的依赖项到第三方库。我们现在才开始部署它——对于像 Prism 这样的外部库来说已经很棒了，而且还允许您为自己的共享库创建中央存储库。