Fix fast restore

[matthid]

This has regressed countless times:

• (recently) Change caching logic to be more suitable for FAKE and in particular the Ionide tooling #3598
• Fixes #3012 #3013
• make sure to not start paket and if we start it use full-restore #3200
• [v2] make sure to not start paket and if we start it use full-restore #3201
• Do a global restore as it was intended #3206

The last regression was due to the change of the caching file to only contain hashes. This is tricky to fix in msbuild, but there is https://docs.microsoft.com/en-us/visualstudio/msbuild/getfilehash-task?view=vs-2019 which seems to produce the exact same hash we already generate in C# (when using SHA256 in hex format).
I guess this also replaces #2870, lets see if this actually works for everyone, if not we are doomed ;)

Therefore we:

• Add (failing) integration test for Finalize targets #2684.
• Fix the issue at hand

[matthid]

/cc @TheAngryByrd Please check if this regresses on #2796

[TheAngryByrd]

Seems to be working for me!

Only issue I seemed to have is having an older FAKE version causes paket.restore.cached to be in a old format and give this new Targets file errors. Might need to recommend people update their FAKE version if they hit this error

.paket/Paket.Restore.targets(101,13): error MSB4184: The expression ""System.String[]".GetValue(1)" cannot be evaluated. Index was outside the bounds of the array.

[matthid]

I think we should fix that, if we cannot read the cache file we should probably call restore and consider it outdated

[matthid]

Seems the testsuite agrees ;)

[forki]

is this ready?

[matthid]

Should be ready if it turns green. I addressed the failing tests and the issue @TheAngryByrd pointed out (including a test for this scenario as none existed)

Notice that this also fixes fsprojects/FAKE#2348 which apparently is a feature now in the SAFE-Stack. Instead of adding an integration test into FAKE, I think it should be enough that we now have one here, time will tell.

[matthid]

I accidentally pushed into origin and then deleted the branch, therefore we now have 4 instead of 2 CI builds and two are red because they can't find the branch :)

[forki]

@matthid you always find novel ways to confuse me ;-)

[matthid]

That's why I added a comment ;).
push origin is just to much muscle memory ;)

[forki]

You could point origin to your fork and name the common fork upstream Matthias Dittrich <[email protected]> schrieb am Di., 2. Juli 2019, 19:47:

…

That's why I added a comment ;). push origin is just to much muscle memory ;) — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#3608?email_source=notifications&email_token=AAAOANBLLF5ZD6S5OU5UVRDP5OIBZA5CNFSM4H4WQFWKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODZCBRCQ#issuecomment-507779210>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAOANEASK632R7RJFAVCZLP5OIBZANCNFSM4H4WQFWA> .

[baronfel]

That's what I do, too terrified I'll flub things up by happenstance

[matthid]

Had to fix another test anyway, so back to normal ;)