Nuget - 在源代码管理中存储包，或者不？答案

【问题标题】：Nuget - store packages in source control, or not?Nuget - 在源代码管理中存储包，或者不？
【发布时间】：2022-05-03 21:26:37
【问题描述】：

我们目前不使用 nuget 作为我们的依赖项，更喜欢采用老式的方式并将它们全部粘贴到 libs 文件夹中并从那里引用。我知道。所以1990年代。

无论如何，nuget 总是让我感到有些不安……你知道，依赖云等等。因此，我发现自己主要同意 Mark Seeman（见此处：http://blog.ploeh.dk/2014/01/29/nuget-package-restore-considered-harmful/），他说：

就个人而言，我总是禁用该功能，而是签入我的存储库中的所有包。这从来没有给我任何问题。

问题是，这在版本 3 中已更改，您不能将软件包与解决方案一起存储，如下所述：https://oren.codes/2016/02/08/project-json-all-the-things/。哪一种搞砸了将它们检查到源代码中。

那么，我在这里什么都不担心吗？我应该从 nuget 井里喝水，还是与 Seeman 先生等人一起谨慎行事？

【问题讨论】：

就个人而言，我永远不会将包存储在源代码管理中。它们存储在 Nuget 中是有原因的，您为什么要使用特定版本来阻塞您的 git 存储库？升级时，您的开发人员会清理本地副本吗？没有。或者至少，不太可能。如果您使用最新的 nuget 范例，如果找不到包，它们将自动恢复。您也可以使用nuget restore xxxx.sln 将其编入命令行选项
如果您主要关心的是访问 nuget.org 存储库（连接），那么设置一个私有 nuget 服务器来缓存您需要的包。这可以是文件共享或免费的 nuget 服务器（nuget.org 存储库是 OSS）
Can (Should) I put 3rd party libraries in version control?的可能重复
相关：stackoverflow.com/questions/1710027/…
也相关，支持包含在源代码控制中的论据：softwareengineering.stackexchange.com/questions/301547/…

【解决方案1】：

将 NuGet 包存储在源代码管理中是一个非常、非常的坏主意。我不小心做了一次，结果我的源代码非常臃肿，那是在 .NET Core 之前...

从 NuGet 井中畅饮。如今，大多数软件组件都以类似的方式打包（NPM、Bower 等）。引用的博文已有两年之久，并且 .NET 世界中的包管理正在迅速变化，所以这是我最近的一些经验。

无法从 nuget.org 删除 NuGet 包。它们可以隐藏，但是如果您的应用程序请求隐藏包，它将下载它像平常一样。它永远不会消失在虚空中。
“启用包还原”不再出现故障，因为它现在是 NuGet 2.7+ 中的默认选项。你别无选择。
不再按解决方案存储包，而是按机器存储包，这将节省大量带宽并缩短构建时的初始提取周期。
如果您使用 .NET Core 构建新项目，您将拥有数十个包，因为整个 BCL 将作为 NuGet 包提供。您真的要将所有 System.* 包签入到源代码中吗？

【讨论】：

> "无法从 nuget.org 删除 NuGet 包。" - 这是不真实的。 Microsoft.Net.Compilers 2.0.0 包过早发布，我的一些项目自动更新到它，然后包从 NuGet 中提取，我根本无法构建我的解决方案，NuGet 抱怨无法下载它。我不得不手动调整我的packages.config 和csproj 文件以引用1.3.2。见这里：github.com/dotnet/roslyn/issues/14591
只是说，我们使用了 nuget，版本 3 比版本 2 好得多。我们从未遇到任何问题，它在解决方案级别上运行良好。请注意，这是要走的路，我没有打开自动更新。
我刚刚验证，如果您只是归档文件 [project]/packages 并更新项目的另一个签出，VisualStudio 构建过程也将运行 bower/npm update 从 NuGet 中提取所需的包。真的不需要自己归档包。太好了。

【解决方案2】：

您希望将 Nuget 包存储在源代码管理中的原因非常简单。您的组织不希望您的构建服务器能够访问 Internet。

【讨论】：