应该将project.lock.json文件检入源代码管理吗？(ASP.NET Core 1.0)

Question

使用ASP.NET Core 1.0,最好将project.lock.json文件签入源代码管理吗？

Answer 1

简短的回答:不,不应该将project.lock.file检入源代码控制 - 你应该配置版本控制系统来忽略它(如果你使用git就把它添加到.gitignore).

答案很长:project.lock.json包含项目整个依赖关系树的快照 - 不仅是"依赖关系"部分中列出的包,还包括这些依赖关系的所有已解析的依赖关系,依此类推.但它不像ruby的Gemfile.lock.与Gemfile.lock不同,project.lock.json不会告诉dotnet restore应该恢复哪些软件包的确切版本 - 它只会被覆盖.因此,它应该被视为缓存文件,永远不会被检入源代码控制.

如果你将它检入版本控制,那么很可能在其他机器上:

• dotnet 会认为所有软件包都已恢复,但事实上有些软件包可能会丢失,构建将失败,而不会暗示开发人员可以运行 dotnet restore
• project.lock.json将被覆盖dotnet restore,在大多数情况下将与源代码管理中存储的版本不同.因此几乎每次提交都会对其进行修改
• project.lock.json将在合并期间导致冲突

Answer 2

实际上，有时你确实想在 git 中提交你的 project.lock.json 。

检查您的项目 json

出于确切的原因，它会向您显示您所使用的依赖项。说：

1. 我作为一名开发应用程序的开发人员，我讨厌每次更新包，因此我将包依赖项添加到 nuget 包 X = 1.*
2. 我恢复包我得到版本 1.2.4
3. 软件包制造商犯了一个非常愚蠢的错误，他在尝试修复并发布 1.2.5 时破坏了一些东西
4. 第二个人签出（或者更糟糕的版本构建开始）。
5. 2号人恢复并获取版本1.2.5
6. 第二个人运行您的应用程序并发现该应用程序已损坏。
7. 第二个人开始调试并认为软件中一定存在错误。

在这一步中，第 7 个人 2 可以在 git 中看到他的锁定文件已更改，并且已下载更新版本的库，而其他开发人员尚未对其进行测试！

缺点

签入此文件的缺点是您可能会在包的持续更新中遇到合并冲突。

替代解决方案

仅使用硬版本依赖项（但这对于 nuget 来说相当困难）。并且只能偶尔手动更新到较新的版本。

缺点

• 如果您构建一个库供其他人使用，则这不起作用，因为您将它们固定到依赖项的某个版本。
• 依赖项的依赖项仍然会自动解决，因此如果您自己不指定它们，则无法保证存在版本dotnet restore

结论

如果您想避免“在我的机器上运行”引号以及不断手动更新到新版本的地狱：检查project.lock.json。

并且在发布之前构建一个 CI/Release 构建检查来测试该文件与 git 相比是否没有更改（如果您的软件非常关键）！

如果这不是问题并且自动更新（到可能损坏的包）也不是大问题，那么您可能不想提交您的project.lock.json。