3.3.5: paket.dependencies and paket.lock are out of sync ALWAYS

[konste]

For attached paket.dependencies and packet.lock Paket always reports that they are out of sync! You can delete paket.lock and let Paket 3.3.5 to regenerate it (with Paket install) and immediately the next Paket restore command would report that they are out of sync!

paket.dependencies.txt
paket.lock.txt

[forki]

Thanks for reporting. Will look at it tomorrow
On Jun 27, 2016 9:03 PM, "Konstantin Erman" [email protected]
wrote:

For attached paket.dependencies and packet.lock Paket always reports that
they are out of sync! You can delete paket.lock and let Paket 3.3.5 to
regenerate it (with Paket install) and immediately the next Paket restore
command would report that they are out of sync!

paket.dependencies.txt
https://github.com/fsprojects/Paket/files/335631/paket.dependencies.txt
paket.lock.txt
https://github.com/fsprojects/Paket/files/335632/paket.lock.txt

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#1766, or mute the thread
https://github.com/notifications/unsubscribe/AADgND8ApEWG6Jc1I7PC1zvqooanHKBwks5qQB6GgaJpZM4I_Z0-
.

[forki]

please retry with 3.3.6

Btw: you can also get rid of the framework restrictions on the packages - I mean you are already restricting the full group. (that was also the issue that paket did not detect)

[konste]

Here is what I don't understand despite all the efforts: we have internal package which intentionally targets NET35 and nothing else. What shall I write in paket.dependencies and paket.references so that the package is still picked up for .NET 4.6.1 projects? Whatever I do I get "Package BitTitan.DeviceManagement contains libraries, but not for the selected TargetFramework net461 in project...". I want those libraries to be referenced anyway, they are compatible with all versions of .NET
How?

[forki]

This is unrelated to the issue right?
Can you please open new one?

[konste]

Done.

[daniellittledev]

This issue seems to be back in 3.36.1

[forki]

Please open a new issue with a repro case. I assume it's a new version