在企业中使用Nuget自动包恢复有哪些优点?

在企业中使用Nuget自动包恢复有哪些优点?,nuget,nuget-package-restore,Nuget,Nuget Package Restore,我一直在尝试在公司内部实施Nuget策略,我想知道在内部托管TFS上处理内部项目时,自动包恢复的真正价值是什么 我知道,在开源项目中或使用外部托管的源代码管理时,不签入外部包可以节省大量磁盘空间,但除此之外(节省服务器上的磁盘空间)我看不到使用自动恢复的任何其他优势:实际上,它给我们带来了一些问题,因为构建机器无法连接到internet,而使用该功能,我们要么更改防火墙规则,要么保留nuget存储库的本地缓存 谢谢你: 最初的NuGet工作流是将Packages文件夹提交到源代码管理中。原因是它

我一直在尝试在公司内部实施Nuget策略,我想知道在内部托管TFS上处理内部项目时,自动包恢复的真正价值是什么

我知道,在开源项目中或使用外部托管的源代码管理时,不签入外部包可以节省大量磁盘空间,但除此之外(节省服务器上的磁盘空间)我看不到使用自动恢复的任何其他优势:实际上,它给我们带来了一些问题,因为构建机器无法连接到internet,而使用该功能,我们要么更改防火墙规则,要么保留nuget存储库的本地缓存

谢谢你

最初的NuGet工作流是将Packages文件夹提交到源代码管理中。原因是它与开发人员在没有NuGet时通常做的事情相匹配:他们创建一个
Lib
ExternalDependencies
文件夹,将二进制文件转储到其中,并将其提交给源代码管理,以允许其他人构建

因此,我们的想法是,软件包将在构建项目的每台机器上恢复,这样二进制数据就不会受到源代码控制。对于Mercurial或Git这样的分布式源代码控制系统,即在客户机和服务器上使用的磁盘空间和带宽

但是当你的构建机器无法连接到互联网上的nuget.org(我假设)时,这确实会带来一个问题。我想你已经找到了主要的解决方案。将包提交到源代码管理并避免包还原,允许生成计算机连接到internet,或设置本地镜像


我不想说包恢复在您的环境中没有任何好处。我不认为提交包有什么大的危害。但这实际上取决于您的团队如何运作、您的团队期望什么以及您所处的企业环境类型。

正如Steven在他的文章中所指出的,使包不受源代码管理的主要原因是减少源代码管理服务器需要存储和传输的数据量。显然,在一家控制所有硬件的公司中,磁盘空间和网络传输都不是问题,但如果不需要,为什么要浪费磁盘空间/时间处理软件包呢。请注意,包目录的大小可能占工作区总大小的相当大的百分比。在我的例子中,当使用TFS(对于我的工作区)时,packages目录占总工作区的80%-95%,而对于我的私有工作区(基于git,因此具有占用一些空间的.git目录),packages目录占总工作区的50%-75%。总而言之,如果使用包还原,可以在源代码管理服务器上节省大量空间

解决Nuget.org访问问题的一个方法是拥有自己的。此本地包存储库可以是本地的,也可以只是服务器上的共享目录。因为存储库位于您公司的局域网内,所以构建服务器访问本地nuget存储库应该不是什么大问题。 这种方法的一个附带好处是,您的构建过程独立于Nuget.org(在非常罕见的情况下,它会停止),更重要的是,您确切地知道哪些包会被拉入构建(因为它们将是本地存储库中批准的包)

对于我们来说,是否使用本地nuget存储库和包恢复选项取决于我们将所有内部库打包为nuget包的决定(我已经在一篇关于另一个nuget问题的文章中描述了我们的开发过程)。因此,我们需要一个本地包存储库来分发这些内部包。这意味着将第三方软件包添加到此存储库很容易,因此使用软件包还原非常有意义。 如果您不将内部库打包为nuget包,那么您将把它们与解决方案和代码文件一起放在源代码管理中。在这种情况下,您也可以对第三方库执行同样的操作


最后,这一切都是一种权衡。磁盘空间与基础架构设置的方便性等。选择最适合您的环境的解决方案。

感谢您的输入谢谢。。。我们还讨论了使用Nuget托管内部共享库的问题:如何解决调试来自Nuget的库而不需要源代码的问题。@CodeLimber为了调试我们自己的库,我们设置了一个符号服务器(不太难)和我们使用的第三方包。显然,并不是所有的第三方软件包都发布它们的PDB,但在这种情况下,您在下载中找不到它们。如果你真的想要它们,你可以随时获取源代码,构建它,在本地存储包,并将符号推送到本地的符号服务器。谢谢