Copy link

Member

Zaid-Ajaj commented on Dec 9, 2020

Fable.Remoting#201 - Fable.Remoting.Giraffe broken in Giraffe 5 is a blocker for this upgrade where latest Giraffe v5.0-pre that works with net5 isn't compatible with the Giraffe adapter from Fable.Remoting. It's a bit tricky on remoting side of things because upgrading the adapter also break backward-compat with applications using Giraffe [>= 3.6 && < 5]

theimowski commented on Dec 9, 2020

Thanks for the heads up. Until that issue is solved I'll pin Giraffe version to below v5

theimowski commented on Dec 9, 2020

@theprash do you think it's a good idea to move away from paket-based dependencies for fake build script and instead use the #r "nuget: Package" syntax? Wondering if that's the recommended way for fake scripts - can we guarantee pinned versions of resolved packages?

Zaid-Ajaj commented on Dec 10, 2020

Thanks for the heads up. Until that issue is solved I'll pin Giraffe version to below v5

@theimowski I just pushed a new version of Fable.Remoting.Giraffe v5.0.0-rc-6 that uses latest prerelease of Giraffe targeting net5. It should work in principle, let me know if you encounter any issues when using it

@theimowski we've tried and it doesn't work for some reason that I don't fully understand (but Prash does). I think for now we've had to run our FAKE scripts via fsi or something.

theprash commented on Dec 10, 2020

@theimowski The main reason for moving was that FAKE seems to be tied to its own paket version which didn't support .NET 5. However, I never really liked the fake-cli approach, though I'm sure it has some advantages. One problem is that #r "paket: groupref build //" is a compile error everywhere except VS Code as far as I'm aware. And you need the additional
#load "./.fake/build.fsx/intellisense.fsx".

RE package resolution, no I don't think you can have completely reproducible package resolution with this method if NuGet doesn't provide it.

Another option is to run FAKE as a console project instead. I quite like this approach because you can easily use paket and you don't need any special tooling like fake-cli or any special #r commands that IDEs don't understand. You just dotnet run the console project. You can pass through the command line arguments and set up the FAKE environment in the same or similar way to what I already added to the top of build.fsx. It might be worth add a function to FAKE itself that can do this in one line.

theimowski commented on Dec 10, 2020

Yeah I think @Zaid-Ajaj also likes the idea of invoking FAKE via standard fsproj rather than fsx. I'll experiment with that approach.
The #r nuget syntax is great for quick setup and fire-and-forget scripts. However as it doesn't guarantee locked resolution, I'd rather not user it to run FAKE.

theimowski commented on Dec 11, 2020

Need to park updating to latest Giraffe prerelease, as Saturn needs to catch up SaturnFramework/Saturn#281

theimowski commented on Dec 11, 2020

af5bc09 is a PoC of using FAKE in fsproj rather than as fsx script

theimowski commented on Jan 23

Updated the PR to latest prerelease of Saturn and Giraffe - seems to work nice locally.
Would be curious to hear your thoughts on a different approach for running build as opposed to build.fsx - see updated README.md for default template.
Still need to fix the tests.

olivercoad commented 28 days ago

@theimowski I think it probably had more to do with making it run directly in the content folders that made it start working.

theimowski commented 27 days ago

And why would that be?

theimowski commented 27 days ago

Prerelease version of template now available with dotnet new -i SAFE.Template::3.0.0-beta001

theprash commented 18 days ago

@theimowski CONTRIBUTING.md still says you should run dotnet fake build to build the template. If I do dotnet run I get "Specify which project file to use because C:\Users\Prash\dev\SAFE-template contains more than one project file". It only works with the longer command dotnet run -p Build.fsproj.

Do you know why it doesn't work in the same way as the output SAFE app?

Are you referring to the Template repo are the generated SAFE template? In the template repo, there are two proj's (Build.fsproj and SAFE.Template.proj). When you generate a template, dotnet run works as expected.

theprash commented 18 days ago •

@bengobeil The template repo. Ah right I didn't notice that other proj file. So dotnet run -p Build.fsproj is what we need to put in CONTRIBUTING.md then 👍🏾

ddombrow commented 14 days ago •

Not sure if this is due to my setup but I get an error trying to use the beta template under WSL2, has to do with the paket project path that gets inferred I think:

dotnet paket restore --project "\\wsl$\Ubuntu-18.04\[snip]\Metro\src\Shared\Shared.fsproj" --output-path "obj" --target-framework "net5.0"
Paket version 6.0.0-beta8
Total time taken: 0 milliseconds
Paket failed with
-> DirectoryNotFoundException: Could not find a part of the path '/wsl$/Ubuntu-18.04/[snip]/Metro/src/Shared/Shared.fsproj'.

isaacabraham commented 13 days ago

Closes #424

olivercoad commented 12 days ago

@ddombrow The problem is it's finding and using the dotnet.exe on windows instead of using the dotnet installed in WSL.

I've opened an issue fsharp/FAKE#2573

A workaround is to override DotNetCliPath in the fake dotnet exec options

// around L35 in build.fs
let dotnet cmd workingDir =
    let dotnetPath =
        Option.defaultValue "dotnet" (ProcessUtils.tryFindFileOnPath "dotnet")

    let result =
        DotNet.exec
            (DotNet.Options.withWorkingDirectory workingDir
             >> DotNet.Options.withDotNetCliPath dotnetPath)
            cmd
            ""

theimowski commented 9 days ago

3.0.0-beta002 includes now Fantomas formatting plus a couple small fixes