我们开始使用NuGet,我们遇到了一些问题:
(只是为了确保我们了解NuGet的工作原理)
在添加,更新或删除包时,会创建并更新packages.config(位于project-root中).在此文件中,包版本属性反映了正在使用的完整版本,因此在这个意义上它也是一个状态.可以将allowedVersions属性添加到包规范中,这是对可以更新的版本的限制.要使程序包还原起作用,此文件需要受源代码管理.
packages文件夹位于solution-root中,并在子文件夹中包含下载版本的依赖包,其名称与包名称(包括版本)相匹配,以允许多个中的不同项目使用同一包的多个版本 - 项目解决方案.建议不要将它们作为二进制文件来源控制,并且包恢复可以在需要时重新创建它们.更新包时,将使用其中的包创建与更新匹配的新文件夹.
项目文件包含对packages文件夹中的包的引用,以使构建工作,并且visual studio也能够提供自动完成,智能感知等.更新包时,项目文件中的引用将更新以匹配packages文件夹中包的新位置.
由于packages.config文件包条目包含完整的版本信息,因此我们经常需要更新源控件存储库.或者,我们可以在大多数情况下忽略这些更改,但是当版本发生变化时,我们(在大多数情况下)会忽略它们.这似乎是非常不必要的,因为NuGet恢复应该能够知道允许哪些版本(通过allowedVersions).
必须手动添加allowedVersions属性,这很容易被遗忘.我们正在使用语义版本控制,因此对于我们来说,在安装即Foo-1.1.0版本时,应隐含allowedVersions ="[1,2]".
当添加allowedVersion时,NuGet包恢复似乎无法找到-prerelease程序集(可能是一个错误？).
为什么NuGet在解决方案级别处理包？如果您正在使用包含项目A(repo-1)和项目B(repo-2)的混合搭配解决方案,那么解决方案级别的打包将无法正常运行.也就是说,如果您将该解决方案文件保存在一个单独的位置,那么事情可能仍然有效.但是,如果你然后设置另一个包含项目-A(repo-1)和项目-C(repo-3)的解决方案,那么项目-A将突然再次需要一个包恢复,更糟糕的是,项目引用将是更改为匹配上次更改.回到第一个解决方案将有参考不起作用.检查这些肯定会使它们不适合其他人.
在程序包更新中,更新项目文件引用(以匹配其中包含versionid的新foldernames),并将显示为未提交的更改.承诺这一变化似乎是常态,但我们认为这不是必要的.
关于ExcludeVersion的注释(可以建议作为上述问题的解决方案:
您只能在手动执行NuGet命令时提供该选项.通过Visual Studio中的NuGet菜单安装/更新软件包时,无法使用该选项.使用任何自动化工具意味着必须手动修复foldername和项目引用.
我们知道ExcludeVersion不是默认设置,可能是因为支持某人在多项目解决方案中工作的情况,其中不同的项目依赖于同一个包的不同版本.
(但是,这可能需要NuGet生态系统的重大变化？)
A - packages.config
我希望packages.config中的每个package元素都可以抛弃allowedVersions,而是将version更改为范围说明符.packages元素还应提供一种单独标识从哪个源获取更新的方法.最后,如果安装的软件包遵循语义版本控制,则版本属性应根据安装的版本自动设置版本范围.
示例packages.config:
`<?xml version="1.0" encoding="utf-8"?>
<packages>
<package id="Foo" version="[1,2] source="Development Feed">
</packages>`
这个会:
修复了package.config文件过多提交的问题,因为版本属性不再经常更新.
无需记住为语义版本的项目设置范围.
确保从所需的源中获取包,并且通过在错误的源中查找它而不浪费时间.
B - Packages文件夹和其中已安装软件包的名称
我希望packages文件夹位于每个项目根目录中,并且子文件夹名称仅限于包名称,不包括版本.这个会:
修复了项目文件过多提交的问题,因为项目文件中的项目引用现在指向更新后的同一个包文件夹.
允许项目使用相同包的不同版本,因为它们真正相互独立.
我们很高兴听到所列问题的解决方案.