FAKE 5.0 DotNet.Restore not restoring properly

[jackfoxy]

Description

FAKE.DotNet.DotNet.Restore id |>ignore does not properly restore.

Repro steps

1. clone current master from https:/jackfoxy/FsRegEx (b5315f8)
2. run build script, note failures (note that a dotnet restore from the command line fixes it)
3. clone again to fresh directory
4. checkout previous commit, 4774e03
5. run build script, note success

Expected behavior

successful restore and build

Actual behavior

C:\Program Files\dotnet\sdk\2.1.104\Sdks\Microsoft.NET.Sdk\build\Microsoft.PackageDependencyResolution.targets(327,5): error : Assets file 'E:\Temp\FsRegEx\src\FsRegEx\obj\project.assets.json' not f
ound. Run a NuGet package restore to generate this file. [E:\Temp\FsRegEx\src\FsRegEx\FsRegEx.fsproj]

Known workarounds

revert back to DotNetCli.Restore id

[jackfoxy]

I was going to collect more info and set up the FSharp.Formatting beta problem #1838 (comment), when I discovered this.

[matthid]

https:/jackfoxy/FsRegEx (b5315f8)

Maybe we have different defaults and therefore we execute a different command?

[jackfoxy]

Default of what? dotnet restore?

[matthid]

Yes maybe when switching to the new API a different command is executed (or different working directory..).

[jackfoxy]

OK, I'll try to track that down. This implies dotnet is installed more than once on my machine. A good example of why I like having relevant DLLs under Paket control, rather than installed apps.

[matthid]

you cannot manage dotnet with paket. especially when paket switches to dotnetcore it would be a chicken and egg problem...

I’ll try to look at this eventually but if you could find the difference / root cause it would help a lot (for example with procmon or the debugger)

[jackfoxy]

I know I can't manage dotnet from paket. I used to be able to manage FAKE from paket, but that is probably ending.

[matthid]

no you can manage your fake version with paket if you really want. for example use dotnet-fake as shown above. In paket there is a pr for “reprotool” - we probably will support that as well once it’s released...

[jackfoxy]

As soon as I get my build script fully functioning on rc001 or later I will test this again.

[jackfoxy]

I have now implemented DotNet.exec id "restore" |> ignore and this also does not work as desired.

Legacy Fake.DotNetCli.Restore id functioned perfectly as dotnet restore does.

[matthid]

Ah I think you miss some parameters and are ignoring functions. restore is already returning unit. please look in intellisense or the api reference

[jackfoxy]

Yes, Overlooked args.
But still does not work "out of the box" with no arguments.
I changed it to DotNet.exec id "restore" System.String.Empty |> ignore

and now I get this:

E:\GitRepos\FsRegEx\src\FsRegEx\unknown(1,1): error FS0078: Unable to find the file 'netstandard.dll' in any of↔ C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1↔ C:\Program Fi
       les (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\Facades↔ E:\GitRepos\FsRegEx\src\FsRegEx↔ C:\Users\Jack\.nuget\packages\fsharp.core\4.3.4\lib\netstandard1.6 [E:\GitRepos\FsRegEx\src\FsRegE
       x\FsRegEx.fsproj]

which I am pretty sure is the result of the restore not doing something.

The "least surprising" thing for DotNet.exec is to mimic exactly what dotnet command line does without having to learn arguments.

[matthid]

Well I'm pretty positive that DotNet.exec id "restore" "" |> ignore is exactly the same as opening a shell and running dotnet restore in the folder where the fsx files is in. Differences might be because of PATH variable or some other environmental stuff. Or maybe because you run dotnet restore on the command line in a different working directory or you change the working directory somewhere else in your script?

[matthid]

Or maybe it is in fact a bug, but at least it should work like stated (I don't know what else this code should do) :/

[jackfoxy]

I just verified Trace.log <| sprintf "source dir is %s" __SOURCE_DIRECTORY__
I execute dotnet restore from same directory as is the current source directory when
DotNet.exec id "restore" System.String.Empty |> ignore runs

[jackfoxy]

I no longer reference legacy FAKE, but I'm still referencing 5.0 from Paket.
I'll try changing over to the recommended way and see if that solves both my outstanding issues.

[matthid]

@jackfoxy Can I just clone your repository on master to reproduce?

[matthid]

Did setup a small test and it seems to work:

[jackfoxy]

@matthid I just now updated github with my latest in master https:/jackfoxy/FsRegEx
feel free to clone

[matthid]

@jackfoxy jackfoxy/FsRegEx#5 seems to work fine (ie dotnet-restore seems to work).
The only thing I noticed is that the new ChangeWatcher-API is indeed missing from FakeLib.

[jackfoxy]

Applied @matthid PR, thanks.

It must be environmental on my side, somehow.
rc004
I deleted all packages, bins, objs, and ran paket update -f
That cleared up my remaining issue, but not this.

If I comment DotNet.exec id "restore" System.String.Empty |> ignore and manually run dotnet restore the whole build script runs.

Uncommenting that line results in

E:\GitRepos\FsRegEx\src\FsRegEx\unknown(1,1): error FS0078: Unable to find the file 'netstandard.dll' in any of↔ C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1↔ C:\Program Fi
       les (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.1\Facades↔ E:\GitRepos\FsRegEx\src\FsRegEx↔ C:\Users\Jack\.nuget\packages\fsharp.core\4.3.4\lib\netstandard1.6 [E:\GitRepos\FsRegEx\src\FsRegE
       x\FsRegEx.fsproj]

Am I on the wrong version of dotnet?

dotnet --version
2.1.104

[matthid]

No idea, I have a similar version

$ dotnet --version
2.1.101

[matthid]

Is there still something open here?

[jackfoxy]

Last I tried to use it, it still didn't work for me.
I'm taking a break from 5.0 for a while. I'm sure I'll get back to it.

[matthid]

Yes let me know if you found a way to reproduce...