hardcode dotnet version

[fbehrens]

maybe this is a fix for #19.
If it works next question would be where to get or store the dotnet-version.

[forki]

This is what I do in FAKE 4:

https://github.com/SAFE-Stack/SAFE-BookStore/blob/master/global.json

https://github.com/SAFE-Stack/SAFE-BookStore/blob/master/build.fsx#L30

[tomasaschan]

If we go this way instead of runDotNet, we should probably just remove that utility function and use DotNetCli.Test in the other call site.

Concievably, we could create a default config mutator which we chain with the mutator here, to set e.g. tool path and configuration in a single place.

let defaultConfig config = { c with Configuration = "release"; ToolPath = dotnetCliPath }

// ...

DotNetCli.Build defaultConfig
DotNetCli.Test (defaultConfig >> fun c -> { c with SomeOtherSetting = "changed" })

Note that without changing the toolspath in the test call site, the build will fail there with the same error as the one this attempts to solve (this is currently handled by runDotNet).

[fbehrens]

@forki: Can't find the function DotNetCli.GetDotNetSDKVersionFromGlobalJson() neither on github nor searching the git log of fake. Where is it ?

Should it be added to FAKE 5 via PR ?

[jindraivanek]

@fbehrens It's in hotfix_fake4 branch: https://github.com/fsharp/FAKE/commits/hotfix_fake4/src/app/FakeLib/DotNetCLIHelper.fs

[forki]

@fbehrens yes I did not merge it to FAKE 5 since @matthid said this is done differently. But I don't really know how

[forki]

ok let me PR it to FAKE 5

[forki]

see fsprojects/FAKE#1754

[fbehrens]

@tlycken Totally agree, I do not have much knowledge about how all this is properly done with dotnet commands. +1 to use the Helpers from FAKE. Just have tried to use them, but expect the build to fail again. Should we just copy the scaffold (file structure / build.fsx ) from another fsproject, maybe the safe-bookstore?

[fbehrens]

the error message of the failed build on travis for our self-contained-hello-world is

/home/travis/.local/share/dotnetcore/dotnet "build" --configuration debug 
Failed to load (���, error: libunwind.so.8: cannot open shared object file: No such file or directory
Failed to bind to CoreCLR at '/home/travis/.local/share/dotnetcore/shared/Microsoft.NETCore.App/2.0.4/libcoreclr.so'
Finished Target: Build
Running build failed.

in https://github.com/dotnet/cli/issues/3390 it's said that apt-get install libunwind8 will fix this.
Don't know how to go on.

[tomasaschan]

in dotnet/cli#3390 it's said that apt-get install libunwind8 will fix this.
Don't know how to go on.

We can install dependencies in Travis before we start the build. In short, add the following to .travis.yml:

before_install:
  - sudo apt-get install libunwind8

If any other packages are needed too, just list them, space-separated, after the command above.

[tomasaschan]

Should we just copy the scaffold (file structure / build.fsx ) from another fsproject, maybe the safe-bookstore?

I'm strongly against such an approach; one of the fundamental properties of a build script/build pipeline is that it's useless as soon as it's "magic". In that case, it's much better if we can ensure that it's so dead-simple that we all understand how it works. That said, looking at other build scripts to see how they solve specific problems is, of course, not a problem; I just don't want the build script to include anything we don't need and aren't using.

[tomasaschan]

Nice!

The previous build error seems to have been a temporary glitch (from what I could understand in the build log, NuGet failed to respond). Restarting the build solved it.

And with that, we have working CI builds on Windows and Linux - thanks a lot, @fbehrens! 🎉

[tomasaschan]

This also fixes #19.

[forki]

Yay!