.net - 与packages.config、项目引用和解决方案范围的包文件夹有关的NuGet 问题

Question

我们开始使用 NuGet，但遇到了一些问题:

首先是一些 NuGet 事实:

(只是为了确保我们已经了解 NuGet 工作原理的前提)

在您添加、更新或删除包时会创建和更新 packages.config(位于项目根目录中)。在这个文件中，包版本属性反射(reflect)了正在使用的完整版本，所以在这个意义上它也是一个状态。可以将 allowedVersions 属性添加到包规范中，从而限制可以更新的版本。为了使包恢复工作，这个文件需要在源代码控制之下。

包文件夹位于解决方案根目录中，并在子文件夹中包含依赖包的下载版本，该子文件夹的名称与包名称(包括版本)相匹配，以允许多个版本的不同项目使用同一包的多个版本。 -项目解决方案。建议不要对这些进行源代码控制，因为它们是二进制文件，而且包还原可以在需要时重新创建它们。更新包时，会创建一个与更新匹配的新文件夹，其中包含该包。

项目文件包含对包文件夹中包的引用，以便构建工作和 Visual Studio 还能够提供自动完成、智能感知等。更新包时，项目文件中的引用会更新以匹配包文件夹中包的新位置。

问题:

由于packages.config 文件包条目包含完整的版本信息，因此我们需要不断更新源代码控制存储库并进行更改。或者，我们可以在大多数情况下忽略更改，但是当版本发生更改时，我们(在大多数情况下)可以忽略它们。
这似乎非常不必要，因为 NuGet 还原应该能够知道允许哪些版本(通过 allowedVersions)。

allowedVersions 属性必须手动添加，这很容易被遗忘。我们正在使用语义版本控制，所以对我们来说，在安装 Foo-1.1.0 版本时，应该暗示 allowedVersions="[1,2)"。

添加 allowedVersion 时，NuGet 包还原似乎无法找到 -prerelease 程序集(可能是错误？)。

为什么 NuGet 在解决方案级别处理包？如果您正在使用包含项目 A (repo-1) 和项目 B (repo-2) 的混合搭配解决方案，那么解决方案级别的打包将无法正常工作。也就是说，如果您将该解决方案文件保存在单独的位置，事情可能仍然有效。但是，如果您随后设置了另一个包含 project-A (repo-1) 和 project-C (repo-3) 的解决方案，那么 project-A 将突然需要再次进行包恢复，更糟糕的是，项目引用将是更改以匹配上次更改。回到第一个解决方案将有不起作用的引用。检查这些肯定会使它们对其他人不起作用。

在包更新时，项目文件引用被更新(以匹配新的文件夹名和其中的 versionid)并将显示为未提交的更改。提交此更改似乎是常态，但在我们看来，这应该没有必要。

ExcludeVersion 的注意事项 (可以建议作为上述问题的解决方案:

您只能在手动执行 NuGet 命令时提供该选项，afaik。通过 Visual Studio 中的 NuGet 菜单安装/更新包时，无法使用该选项。使用任何自动化工具意味着之后必须手动修复文件夹名称和项目引用。

我们知道 ExcludeVersion 不是默认设置，可能是因为支持有人在多项目解决方案中工作的情况，其中不同的项目依赖于同一包的不同版本。

可能的解决方案？

(但是，这可能需要 NuGet 生态系统发生重大变化？)

A-packages.config

我希望packages.config 中的每个包元素都可以放弃allowedVersions，而是将版本更改为范围说明符。包元素还应该提供一种方法来单独标识从哪个源获取更新。最后，如果安装的软件包遵循语义版本控制，则版本属性应根据安装的版本自动设置版本范围。

示例packages.config:

`<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Foo" version="[1,2] source="Development Feed">
</packages>`

这个会:

修复 package.config 文件过多提交的问题，因为版本属性不再不断更新。

无需记住为语义版本化项目设置范围。

确保从所需的提要中获取包，并且不会因为在错误的来源中查找而浪费时间。

B - 包文件夹和已安装包的名称

我希望包文件夹位于每个项目根目录中，并且子文件夹名称仅限于包名称，不包括版本。
这个会:

修复项目文件过多提交的问题，因为项目文件中的项目引用现在在更新后指向同一个包文件夹。

允许项目使用同一包的不同版本，因为它们真正相互独立。

我们很高兴听到所列问题的解决方案。

Answer 1

正如 NuGet Enterprise - best practices for different maturity levels of packages 中所建议的，我认为你让事情变得比必要的复杂:)

为什么你不想捕获编译代码的包的版本？这是可靠诊断和可重复构建的关键信息。鉴于您可能会将代码更改提交回版本控制，提交用于帮助构建该源的包的详细信息非常有用。

“安装即 Foo-1.1.0 版本时，应暗示 allowedVersions="[1,2)"我不认为 allowedVersions 真的可以暗示，因为并非所有 NuGet 包都遵守 SemVer(请参阅与log4net 1.2.11)。设置 grep对于作为 CI 构建或预提交/预推送开发检查的一部分的 allowedVersions 应该会发现这一点。它不应该经常改变，密切关注它是很有用的(如果其他团队和软件包正在正确使用 SemVer，无论如何:))。

要查找售前包，您需要 Prerelease或 -IncludePrerelease nuget 安装上的标志。

“如果您正在使用包含项目 A(repo-1)和项目 B(repo-2)的混合搭配解决方案”-为什么要这样安排代码？单个解决方案的代码应该都存在于同一个 repo 中。跨存储库破坏解决方案代码肯定会很痛苦!

您可以告诉 nuget 使用无版本的文件夹名称来安装包 ( -ExcludeVersion )。

我强烈建议放弃 Visual Studio NuGet 集成，转而使用命令行 nuget.exe并改为构建脚本。这尤其与 #5 有关，但通常与 NuGet 的交互有关。 Visual Studio 集成在单独使用来自 nuget.org 提要的 3rd 方公共(public)包时很好，但在处理内部 NuGet 提要和包时不够灵活，我不喜欢。