build.cmd fails if Fake package was previously installed via Chocolatey

[vlukash]

Description

build.cmd fails if Fake package was previously installed via Chocolatey

The root cause:
NuGet packages from https://ci.appveyor.com/nuget/fake and http://nuget.org/api/v2 have a different structure.

appveyor

/
--/tools
----/fake.exe

nuget.org

/
--/bin
----/fake.exe

build.cmd expects that FAKE package has 'tools' folder with fake.exe. But the Fake package contains bin folder only

Repro steps

1. Clean NuGet cache:
   C:\Users<user>.nuget\packages
   C:\Users<user>\AppData\Local\Nuget\Cache

2. Install Fake 5 via Choco:
   choco install fake -pre
   Currently it's the FAKE.5.0.0-alpha010
   See that "C:\Users<user>\AppData\Local\Nuget\Cache" has fake.5.0.0-alpha010.nupkg

3. Pull Fake repository from git.
   paket.lock currently references Fake as:

remote: https://ci.appveyor.com/nuget/fake
  | FAKE (5.0.0-alpha010)

4. Run build.cmd
   Build.cmd will call .paket\paket.exe restore and the cached version from Choco will be restored.

Expected behavior

Restored Fake package has 'tools' folder:
packages\build\FAKE\tools\Fake.exe

Actual behavior

Build fails because can't find fake.exe

Restored Fake package has 'bib' folder only:
packages\build\FAKE\bin\Fake.exe

Known workarounds

Clean NuGet cache and install Fake package from the https://ci.appveyor.com/nuget/fake

Related information

• Windows 10
• master branch.

[vlukash]

I'm trying to create a PR for this but I need more information on the expected behavior.

Should we update the Fake package generation for nuget.org so it has 'tools' folder?
I see that 4.x and 3.x packages from nuget.org use 'tools' folder.

Or this is something that was changed in v5 and build.cmd should search for fake.exe in both folders?

[matthid]

Ah nice catch. I think what happens is that appveyor uses the wrong fake.nupkg from 'nuget/dotnetcore/Fake.nupkg' instead of 'nuget/legacy/Fake.nupkg'. those are different and we never actually use or need the first one. It's an artifact because we package all projects.

Probably just deleting the wrong nupkg in the build will fix that...

[matthid]

or appveyor detects the chocolatey package, then we need to adapt the build or the appveyor.yml

[vlukash]

@matthid , thanks for the update on this.

The issue is only for the Chocolatey package.
NuGet package is generated correctly.

Details:
The root cause is that Chocolatey and NuGet packages internally use *.nupkg file with the same name but different content.
And if NuGet restore is called after choco install then NuGet will restore file from cache that has a wrong structure/content

I see that nuget/dotnetcore/chocolatey/fake.nupkg is generated based on the nuget\dotnetcore\Fake.netcore\win7-x86, which is wrong (based on the previous comment) and different from the FAKE Nuget.

FAKE NuGet uses the build folder as the file source.

I believe it's better to keep content and structure consistent for Chocolatey and NuGet.
That will solve this issue with the build.cmd

Linking the PR, please take a look:
#1613

[matthid]

are you trying to say that chocolatey and nuget use a shared cache?
I thought the problem was that the appveyor feed contains the chocolatey package...

[vlukash]

yes, I see that paket restore uses *.nupkg cached by Choco.
It would be great if someone can try to repro this. Maybe it's my local machine issue only..

Repro steps are in the bug description

[vlukash]

Oh, the issue was due to the old (I believe 0.9.x or older) Chocolatey version installed locally...
My bad.

After upgrading Chocolatey to the latest 0.10.7 I don't see this issue anymore.
Now Chocolatey removes cached fake.5.0.0-alpha010.nupkg from the C:\Users\<user>\AppData\Local\NuGet\Cache right after pachage installation.

I see someone faced the same issue here:
chocolatey/choco#479

[vlukash]

Closing current bug