The new TFS nuget packages add A LOT more dependencies than the previous ones (seems partly due to donet core), and that begin to worry me

oof that's a lot of dependencies. How many of them end up in the zip?

Add the paket.lock forgotten in #979

🙇 thank you! is there a way to make one of the CI builds check that the packet.lock file that's checked in is correct? Like maybe after restoring packages it could check if the file is different?

oof that's a lot of dependencies. How many of them end up in the zip?

none. I have tested the generated package and it works well without. But I must have taken the time to test it :(

is there a way to make one of the CI builds check that the packet.lock file that's checked in is correct?

No, I don't see a reliable way to do it. The lock file define the dependencies version calculated at one time (and thus validated as "it works" by the developper). The restore will be done based on this file.

The only way to recompute the lock file is to delete it and let paket recreate it. And then we could compare it with the one committed. But everytime a dependency will upgrade (thus we have an outdated package), we will have a warning/error.

The thing your are imagining is generaly done by not committing the lock file, and the lock will be regenerated at each build but that's not generaly what is expected because that's not us anymore that handle version upgrading of dependencies....

none. I have tested the generated package and it works well without. But I must have taken the time to test it :(

and undo the GitTFsVS2015.csproj like describe in the doc....

is there a way to make one of the CI builds check that the packet.lock file that's checked in is correct?

No, I don't see a reliable way to do it. The lock file define the dependencies version calculated at one time (and thus validated as "it works" by the developper). The restore will be done based on this file.

ah. I was imagining that when CI runs paket that it could then do git status paket.lock. But I guess CI doesn't invoke paket?

oof that's a lot of dependencies. How many of them end up in the zip?

none. I have tested the generated package and it works well without. But I must have taken the time to test it :(

Cool.

Would it be worth adding a comment to paket.dependencies that mentions paket.lock or the paket docs?

👍 on this PR

I have added the links. Feel free to merge...