我们开始使用NuGet遇到了一些问题：
首先介绍一些关于NuGet的事实：
- packages.config（位于项目根目录）会在添加、更新或删除包时被创建和更新。该文件中的“version”属性反映了正在使用的完整版本号，因此在这个意义上也是一种状态。可以在包规范中添加allowedVersions属性，它限制了可以更新的版本。为了使包还原工作，此文件需要在源代码控制下。 - packages文件夹位于解决方案根目录，其中包含依赖包的下载版本，在子文件夹中命名与软件包名称相匹配（包括版本），以允许在多项目解决方案中使用同一软件包的多个版本。建议不将其纳入源代码控制，因为它们是二进制文件，而且包还原可以在需要时重新创建它们。当包被更新时，会创建一个新的与更新相匹配的文件夹，并在其中放置软件包。 - 项目文件包含对packages文件夹中软件包的引用，以便进行构建，并使Visual Studio能够提供自动完成、智能感知等功能。当软件包更新时，项目文件中的引用将更新为与软件包在packages文件夹中的新位置相匹配。
以下是问题：
1.由于packages.config文件中包条目包含完整的版本信息，我们必须不断更新源代码控制存储库中的更改。或者，我们可以忽略更改，大多数情况下，仅当版本发生更改时，我们才能够（在大多数情况下）忽略它们。这似乎非常不必要，因为NuGet还原应该能够通过allowedVersions知道哪些版本是允许的。
2.allowedVersions属性必须手动添加，有时会被遗忘。我们使用语义化版本控制，因此对于我们来说，在安装Foo-1.1.0版本时，应自动应用allowedVersions="[1,2)"。
3.添加allowedVersion后，NuGet包还原似乎无法找到预发布程序集（可能是一个错误）。
4.为什么NuGet处理解决方案级别的软件包？如果您正在使用混合匹配解决方案，其中包含project-A（repo-1）和project-B（repo-2），则解决方案级别的打包将无法正常工作。也就是说，如果您将该解决方案文件保存在单独的位置，则可能仍然可以工作。但是，如果您设置了另一个包含project-A（repo-1）和project-C（repo-3）的解决方案，则project-A将突然需要进行软件包还原，并且更糟糕的是，项目引用将因最后一次更改而更改。返回第一个解决方案将具有无法工作的引用。对这些进行检查肯定会使它们对其他人不起作用。
5.在软件包更新时，项目文件引用将被更新（以匹配其中带有版本id的新文件夹名称），并且将显示为未提交的更改。提交此更改似乎是常规操作，但在我们看来，这是不必要的。
关于ExcludeVersion的注意事项（可能会建议作为上述问题的解决方案）：
- 据我所知，只有在手动执行NuGet命令时才能提供该选项。通过Visual Studio中的NuGet菜单安装/更新软件包时，无法使用该选项。使用任何自动化工具意味着必须手动修复文件夹名称和项目引用。 - 我
首先介绍一些关于NuGet的事实：
- packages.config（位于项目根目录）会在添加、更新或删除包时被创建和更新。该文件中的“version”属性反映了正在使用的完整版本号，因此在这个意义上也是一种状态。可以在包规范中添加allowedVersions属性，它限制了可以更新的版本。为了使包还原工作，此文件需要在源代码控制下。 - packages文件夹位于解决方案根目录，其中包含依赖包的下载版本，在子文件夹中命名与软件包名称相匹配（包括版本），以允许在多项目解决方案中使用同一软件包的多个版本。建议不将其纳入源代码控制，因为它们是二进制文件，而且包还原可以在需要时重新创建它们。当包被更新时，会创建一个新的与更新相匹配的文件夹，并在其中放置软件包。 - 项目文件包含对packages文件夹中软件包的引用，以便进行构建，并使Visual Studio能够提供自动完成、智能感知等功能。当软件包更新时，项目文件中的引用将更新为与软件包在packages文件夹中的新位置相匹配。
以下是问题：
1.由于packages.config文件中包条目包含完整的版本信息，我们必须不断更新源代码控制存储库中的更改。或者，我们可以忽略更改，大多数情况下，仅当版本发生更改时，我们才能够（在大多数情况下）忽略它们。这似乎非常不必要，因为NuGet还原应该能够通过allowedVersions知道哪些版本是允许的。
2.allowedVersions属性必须手动添加，有时会被遗忘。我们使用语义化版本控制，因此对于我们来说，在安装Foo-1.1.0版本时，应自动应用allowedVersions="[1,2)"。
3.添加allowedVersion后，NuGet包还原似乎无法找到预发布程序集（可能是一个错误）。
4.为什么NuGet处理解决方案级别的软件包？如果您正在使用混合匹配解决方案，其中包含project-A（repo-1）和project-B（repo-2），则解决方案级别的打包将无法正常工作。也就是说，如果您将该解决方案文件保存在单独的位置，则可能仍然可以工作。但是，如果您设置了另一个包含project-A（repo-1）和project-C（repo-3）的解决方案，则project-A将突然需要进行软件包还原，并且更糟糕的是，项目引用将因最后一次更改而更改。返回第一个解决方案将具有无法工作的引用。对这些进行检查肯定会使它们对其他人不起作用。
5.在软件包更新时，项目文件引用将被更新（以匹配其中带有版本id的新文件夹名称），并且将显示为未提交的更改。提交此更改似乎是常规操作，但在我们看来，这是不必要的。
关于ExcludeVersion的注意事项（可能会建议作为上述问题的解决方案）：
- 据我所知，只有在手动执行NuGet命令时才能提供该选项。通过Visual Studio中的NuGet菜单安装/更新软件包时，无法使用该选项。使用任何自动化工具意味着必须手动修复文件夹名称和项目引用。 - 我
`<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Foo" version="[1,2] source="Development Feed">
</packages>`
这将会:
解决 package.config 文件过度提交的问题，因为版本属性不再经常更新。
无需记住对语义化版本化项目设置范围。
确保从所需的 feed 中获取软件包，并且不会浪费时间在错误的来源上查找。
B - Packages 文件夹和已安装软件包的名称
我希望 packages 文件夹位于每个项目根目录下，子文件夹名称仅限于软件包名称，不包括版本。 这将会:
解决项目文件过度提交的问题，因为项目文件中的项目引用现在指向更新后的相同软件包文件夹。
允许项目使用相同软件包的不同版本，因此它们彼此真正独立。
我们非常乐意听取有关解决上述问题的方案。