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

Question

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

Answer 1

简短回答：不，不应将project.lock.file检入源代码控制 - 您应该将版本控制系统配置为忽略它（例如，如果您将＆＃39;添加到.gitignore。重新使用git）。

长答案：project.lock.json包含项目整个依赖关系树的快照 - 而不仅仅是＆＃34;依赖关系＆＃34;部分，但也解决了这些依赖关系的所有已解决的依赖关系，等等。但它不像红宝石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. 第2人检查（甚至更糟糕的释放构建开始）。
5. Person 2恢复并获得版本1.2.5
6. Person 2运行您的应用程序，发现应用程序已损坏。
7. Person 2开始调试并认为软件中一定存在错误。

在此步骤7，第2人可以在git中看到他的锁文件已被更改，并且已下载了更新版本的库，其未经任何其他开发人员测试过！

缺点

检查此文件的缺点是，您可能会在继续更新软件包时遇到合并冲突。

替代解决方案

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

缺点

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

结论

如果您想避免在我的机器上工作＆＃39;引号和不断手动更新到更新版本的地狱：检查project.lock.json。

还要构建一个CI / Release构建检查，以测试在发布之前该文件是否与git相比没有变化（如果您的软件非常关键）！

如果这不是问题，并且自动更新（可能已损坏的软件包）不是一个大问题，您可能不想提交project.lock.json。

Answer 3

不，它只是一个锁定文件，实际上你不应该在存在锁定文件时检查它（除非锁定它的程序想要将它检查到源代码控制中，在这种情况下，排除你的锁文件！）。