7

背景

我有以下组件：

  • 我使用 NuGet 包的本地解决方案 (.NET 4.5)。
  • 我的解决方案中的一个 PowerShell 构建脚本，其目标是构建、运行单元测试、Web.config 转换等。
  • 没有 Internet 连接且运行 CruiseControl.NET 的构建服务器，它调用我的构建脚本来构建文件。它还用作开发构建的 (IIS7) 环境。
  • 具有 IIS7 且无法访问 Internet 的生产服务器。

目标

我想利用我的解决方案中的 NuGet 包并将它们作为源的一部分存储在本地——而不必依赖我的构建和生产服务器上的 Internet 连接或 nuget 包服务器。

问题

  • 我如何告诉 MSBuild 正确部署这些包，或者这是 NuGet 的默认行为？
4

4 回答 4

9

Scott Hanselman 撰写了一篇出色的文章，题为如何在 NuGet.org 关闭（或者您在飞机上）时访问 NuGet。如果你通读这篇文章，你会在最后看到他提出的建议主要是临时类型的解决方案，他特意说你不应该需要离线缓存，除非在那些紧急情况下。

但是，如果您阅读他文章的底部，他会提出以下建议：

如果您担心公司范围内的外部依赖关系，您可能希望在您的组织内拥有一个包含您所依赖的 NuGet 包的网络共享（可能在共享构建器服务器上）。如果您作为一个组织处于低带宽情况下，这将非常有用。

这就是我最终在类似情况下所做的事情。我们与我们所依赖的各种软件包的最新版本保持共享（当然，我假设您在某种类型的网络上）。它工作得很好，只需要一点点工作就可以半定期更新软件包（我们有一个季度更新周期）。

另一篇可能对您有帮助的文章（对我来说）是：使用 NuGet 分发我们公司的内部 DLL

于 2012-11-26T19:05:24.383 回答
0

默认情况下，Nuget 将所有依赖项放在一个packages/文件夹中。您可以简单地将这个文件夹添加到您的源代码控制系统中，当您进行构建时，Nuget 不需要从 Internet 下载任何内容。您还需要确保未在您的解决方案上配置 Nuget 包还原。

于 2012-11-26T19:03:02.680 回答
0

你必须做出决定；您可以在构建时下载/安装包（无论是使用包还原、您自己的脚本还是为您执行此操作的构建工具），或者您将 /packages 程序集放在源代码管理中，就好像它们在 / lib目录。

我们在内部使用包还原和 NuGet 的 Visual Studio 扩展时遇到了很多问题，以至于我们几乎完全放弃了 NuGet，因为它存在缺陷，尽管我们公司的 2 种产品中有 1 种是私有 NuGet 存储库。

基本上，我们管理生命周期的方式是使用我们的产品 BuildMaster 和 ProGet 的组合，这样：

  • ProGet 缓存我们所有的 NuGet 包（包括我们自己发布的包和来自 nuget.org 的包）
  • BuildMaster 执行 CI 和部署方面并处理所有 NuGet 包恢复，因此我们无需处理大量签入库或解决方案的噩梦，即包恢复

如果您要采用类似的过程，那么在您的第一个环境中创建一个包含已安装 NuGet 包程序集的构建工件可能是最简单的，然后只需将该工件部署到您的生产中，而无需重复该过程。

希望这会有所帮助，
-托德

于 2012-11-27T16:23:41.430 回答
0

我知道这是一个古老的讨论，但是由于大小而存储构建项目所需的所有文件到底有多糟糕？

如果一个库不可用，你应该替换它的想法是疯狂的。代码要花钱，而且由于您无法控制 git 或 nuget 上的库，因此应该提供一份副本。

许多公司的一项要求是审计。如果发现图书馆窃取您的数据怎么办。您如何确定该库是否已从 NUGET 中删除，并且您甚至无法构建代码以进行仔细检查。

一种适合所有网络的 Nuget 和 git 方式是不行的。

我认为 Nuget 过去的工作方式，即文件存储在本地并可选择放置在源代码管理中的方式是可行的方法。

于 2019-02-25T21:03:53.477 回答