Fix for #2361

[seanamosw]

Description

Fixes #2361 by inverting the original logic.
The code used to first search for paket. On Windows when using the paket dotnet tool installed with -toolpath, this would find a paket subfolder of the dotnet tool.
It would never reach the code to search forpaket.exe.

I've changed this to first search for paket.exe, if not found, then it will search for paket.

[matthid]

Thanks for taking care of this. I guess this does fix #2242 as well?

[matthid]

Should we add a test for this?

[matthid]

Looks reasonable.

[seanamosw]

Thanks for taking care of this. I guess this does fix #2242 as well?

Yes, it looks to be exactly the same issue.

Should we add a test for this?

I could see it being useful to catch potential future regressions here.

[seanamosw]

@matthid Is there anything more you need done for this? We have some windows devs/windows builds that are blocked by this.

[matthid]

I assumed/hoped you would add the test :)

builds that are blocked by this.

Couldn't you just 'dotnet pack' this module and add it to your internal feed to unblock yourself temporarily?

[seanamosw]

We use paket.template files, obviously don't want to rework that.
Edit: I misunderstood. Yes, we could do that.

I'll see if I can get a test added for this.