FAKE CLI overwrites Paket.Restore.targets with an old one, which breaks .NET Core Paket

[atlemann]

Description

I'm trying to use the newly released .NET Core Paket in combination with FAKE5 CLI, however, FAKE seems to do a paket restore which overwrites Paket.Restore.targets with an old one which does not support netcore Paket.

It does not happen every time, only when I see the line Starting full restore process. in the console, which seems to come from FAKE CLI. It works fine if I see The last restore is still up to date. Nothing left to do.

Repro steps

Please provide the steps required to reproduce the problem

1. Step A
   git clone https://github.com/atlemann/NetCorePaketFake

2. Step B
   ./build.sh or build.cmd

Expected behavior

Paket to be bootstrapped and the build to succeed.

Actual behavior

Paket.Restore.targets is overwritten with an old one and I get the following output:

$ build.cmd
  Restoring packages for E:\src\NetCorePaketFake\build.proj...
  Restore completed in 39.59 ms for E:\src\NetCorePaketFake\build.proj.
  Generating MSBuild file E:\src\NetCorePaketFake\obj\build.proj.nuget.g.props.
  Generating MSBuild file E:\src\NetCorePaketFake\obj\build.proj.nuget.g.targets.
  Restore completed in 112.9 ms for E:\src\NetCorePaketFake\build.proj.
Starting full restore process.
run Build
Building project with version: LocalBuild
Shortened DependencyGraph for Target Build:
<== Build
   <== Restore
      <== Clean

The running order is:
Group - 1
  - Clean
Group - 2
  - Restore
Group - 3
  - Build
Starting target 'Clean'
Finished (Success) 'Clean' in 00:00:00.0235061
Starting target 'Restore'
Starting task 'DotNet:restore': NetCorePaketFake.sln
E:\src\NetCorePaketFake> "C:\Program Files\dotnet\dotnet.EXE" msbuild /version /nologo (In: false, Out: true, Err: true)
15.8.166.59604
E:\src\NetCorePaketFake> "C:\Program Files\dotnet\dotnet.EXE" restore NetCorePaketFake.sln /nodeReuse:False "/bl:C:\Users\aru\AppData\Local\Temp\tmp447E.tmp.binlog" (In: false, Out: false, Err: false)
C:\Program Files\dotnet\sdk\2.1.402\MSBuild.dll -nologo -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,C:\Program Files\dotnet\sdk\2.1.402\dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,C:\Program Files\dotnet\sdk\2.1.402\dotnet.dll -maxcpucount -target:Restore -verbosity:m /bl:C:\Users\aru\AppData\Local\Temp\tmp447E.tmp.binlog /nodeReuse:False NetCorePaketFake.sln
  '"E:\src\NetCorePaketFake\.paket\paket.exe"' is not recognized as an internal or external command,
  operable program or batch file.
E:\src\NetCorePaketFake\.paket\Paket.Restore.targets(81,5): error MSB3073: The command ""E:\src\NetCorePaketFake\.paket\paket.exe" restore" exited with code 9009. [E:\src\NetCorePaketFake\src\NetCorePaketFake\NetCorePaketFake.fsproj]
Exec: E:\src\NetCorePaketFake\.paket\Paket.Restore.targets(81,5): error MSB3073: The command ""E:\src\NetCorePaketFake\.paket\paket.exe" restore" exited with code 9009.
...
...

Known workarounds

1. Run build.cmd
2. Revert Paket.Restore.targets
3. Run build.cmd

Workaround in script:

Target.create "ResetPaketTargets" (fun _ ->
    CommandHelper.gitCommand "." "checkout .paket/Paket.Restore.targets")

Related information

• Operating system
  Windows 10, Ubuntu
• Branch
• .NET Runtime, CoreCLR or Mono Version

PS E:\src\NetCorePaketFake> dotnet --info
.NET Core SDK (reflecting any global.json):
 Version:   2.1.402
 Commit:    3599f217f4

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17134
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.402\

Host (useful for support):
  Version: 2.1.4
  Commit:  85255dde3e

.NET Core SDKs installed:
  2.1.4 [C:\Program Files\dotnet\sdk]
  2.1.104 [C:\Program Files\dotnet\sdk]
  2.1.201 [C:\Program Files\dotnet\sdk]
  2.1.202 [C:\Program Files\dotnet\sdk]
  2.1.300 [C:\Program Files\dotnet\sdk]
  2.1.400 [C:\Program Files\dotnet\sdk]
  2.1.401 [C:\Program Files\dotnet\sdk]
  2.1.402 [C:\Program Files\dotnet\sdk]

.NET Core runtimes installed:
  Microsoft.AspNetCore.All 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.All 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.All]
  Microsoft.AspNetCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.AspNetCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 2.0.5 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.0.9 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.3 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.NETCore.App 2.1.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

Indications of severity

Blocking: Cannot use FAKE5 CLI with .NET Core Paket

Version of FAKE (4.X, 5.X)

FAKE 5

[matthid]

Yes one "fix" would be to just release a new fake runtime with updated paket.core version.
Question is if it is reasonable to disable this particular feature or if this breaks something else

[atlemann]

So the first thing FAKE CLI does is Paket restore using Paket as a library? Could there be a switch to not do this, since dotnet restore would trigger that during build?

[matthid]

not do what? paket restore is needed for the fake modules to be available.

[atlemann]

True, I forgot about that. Is there any other workaround I could use now? Not sure how to work around this on my build agents. And Paket using Mono throws all kinds of Mono Exceptions for some reason (only on my linux build agents).

[atlemann]

Could FAKE CLI not update Paket.Restore.targets? Is that the particular feature you mentioned?

[matthid]

easy workaround is to undo pending changes with git in your fake script ;)

[atlemann]

Moving .paket to e.g. .mypaket and changing the <Import Project=... in the *sproj file works as a workaround, but ... it doesn't follow the convention of having everyting in .paket folder.

[atlemann]

Right, guess there's a FAKE package for interop with git

[matthid]

Could FAKE CLI not update Paket.Restore.targets? Is that the particular feature you mentioned?

Yes but we need to think if that breaks some use-cases, the best scenario is to use a compatible paket version (which can be seen in Fake.Runtime package dependencies), so currently that is Paket.Core (>= 5.181.1)

usually updating paket is fine but in scenarios like this things can happen (but I don't consider this a bug)

[atlemann]

Workaround of the century:

Target.create "ResetPaketTargets" (fun _ ->
    CommandHelper.gitCommand "." "checkout .paket/Paket.Restore.targets")

[atlemann]

So this would mean that every time Paket changes the Paket.Restore.targets, the FAKE CLI will change it back to whatever its current Paket.core dependency wants? So i.e. bugfixes in Paket would potentially be reset or lag behind when using FAKE CLI?

[matthid]

I said it usually works but it is not a supported scenario :)

[matthid]

Fixed with 4a92098

With 5.10 fake will warn if there is a paket <-> fake version mismatch and fake will suggest the version to use. The hint can be ignored but then stuff like this issue will happen. Usually I'll try to keep up with paket releases as long as they are compatible with the fake test-suite.

[lust4life]

same issue here, can we try to keep up with version which include Paket.Restore.targets changes in paket repo, 5.193.0 seems a little bit old, commit like this in paket release version should be considered update, since this will affect the whole work suit.

and same workaround needs to be added when using with docker. e.g. : causiq/logary#386

Target.create "Clean" (fun _ ->
  // This line actually ensures we get the correct version checked in
  // instead of the one previously bundled with 'fake`
  Git.CommandHelper.gitCommand "" "checkout .paket/Paket.Restore.targets"
  )

[matthid]

@lust4life I'm open for suggestions for a "better" fix

can we try to keep up with version

I try to keep up with paket but in no scenario I'm as fast as @forki