[PackageReference] Enable repeatable build using project lock file

[jainaashish]

This is the tracking issue for implementation of enabling repeatable builds for PackageReference using project lock file.

Spec - https://github.com/NuGet/Home/wiki/Enable-repeatable-package-restore-using-lock-file
Tech Spec - https://github.com/NuGet/Home/wiki/Repeatable-build-using-lock-file-implementation

[StingyJack]

That tech spec link is a 404. Is that intentional?

[jainaashish]

It was still in PR which is why not available outside. But I've merged it now so you should be able to view.

[bording]

@jainaashish NuGet/Engineering is not a public repo.

[jainaashish]

ahh didn't realize it.

[StingyJack]

If this is used to configure the restore operation, why would this be a "lock" file and not a "config" file? "Lock" is not going to make as much sense to users.

Perception - The lock file should not be mistaken for a MSBuild props file that users can modify and check in.

That perception part is worded/reads poorly. The lock/config file is something that users need to see and be able to modify and checkin if repeatable restore are needed. Why not just add an in the project file for this instead of a separate file?

The way the "dependencies" element continually nests, as well as the way the sample file is organized is too messy and complicated to be used as the actual lock file. Its probably a good mechanism for informing the user of the dependency graph, but not as good as a more concise arrangement or diagram. As a user, I dont want to have to read through or have to update the dependency versions in multiple places just to fix a package at a specific version, because that is a maintenance pain. (packages.config was already kind of a pain when trying to cap versions since nuget did not emit the allowedVersion attributes by default, and there is apparently no way to cap versions for a solution).

The consuming application just needs to be able to specify the packages it is going to compile against/with, so the lock file ought to be organized from that point of view. Specifying versions for dependencies of the application's direct references seems irrelevant except for assembly binding redirects.

Sorry for dumping if this was not actually open for comment, but my first impression was "why not just bring back packages.config if this is supposed to do what that already did?" (possibly with a new section for package ref so as not to confuse existing usages). Json is a terrible format for a config file because it does not permit comments, and being able to describe the configuration possibilities or why a specific value was chosen are very important for maintaining an application.

[jainaashish]

PR# NuGet/NuGet.Client#2342 merged into release-4.9.0-preview3 branch