Scaffold and build system

[fbehrens]

Hi @tlycken,
I want to continue up our short discussion in #20 about this.

When I suggested to copy this things from established example projects, I agree to you, that we should only copy those parts that we need and understand.

For my own learning understanding of the dotnet-core platform, I have created a minimal scaffold from scratch: https://github.com/fbehrens/Dotnetcorescaffold .
Important for me was that I get familiar with the native dotnet commands.
This went very smooth. (big thanks to @forki and @Krzysztof-Cieslak for paket and inonide)

In the readme are the steps of creation documented.
Its completely wired up with

• 3 Projects (Library, Cli and Tests )
• uses Paket for dependencies (Fuchu,Expecto)
• has ci (Travis and Appveyor)
• and borrows its structure and build system from the safe-bookstore.

I did this because I needed to understand how all this works.

Here are some differences to what is currently here:

• no need for --use-mono argument
• build scripts can invoke fake targets (like ./build.sh Clean)
• build scripts (fsx,cmd,sh) are simpler
• the git-version stuff is missing
• uses Expecto instead of xUnit
• it builds much faster (don't know why, but on my Mac its 17s against 37s for a full build)

Please have a look at it. What do you think about it?
If you like it, I would make a pull request for switching to it.

[tomasaschan]

Nice!

I probably won't be able to take a closer look before the weekend, but a few initial comments:

• What you're doing to avoid --use-mono doesn't work on WSL, which is why it built my script that way instead. (We also couldn't figure out in what contexts the OS variable is set... It was exactly that kind of overhead that I wanted to avoid by building as much as possible from scratch.)

• The current setup already supports e.g. .\build.sh clean :)

• The fsx we have can be probably be simplified a lot by making better use of Fake helpers (e.g. ditch runDotNet, but other than that the greatest difference between your build.fsx and the one we have is that you have inlined the target implementations with the Target.Create calls, while we currently have them separated (which IMO makes the code easier to read, but it's a matter of taste I guess).

• On top of that, GitVersion adds some complexity to build.fsx, which I don't think you can avoid if you want that functionality, which we do... :)

As you can probably tell from my comments, I'm initially sceptical to just switching it all out; it seems that your approach and mine are very similar, and so are the results. However, whatever we switch to will probably be better in some aspects, and worse in others, so not much will have been gained.

Instead, I think a better way forward would be to take all the stuff you've learned by doing your scaffold project, and use it to make small, incremental improvements to the infrastructure we already have, if there are specific pain points you want to alleviate. (For example, my choice of testing framework is definitely not set in stone - I just took a setup I'm comfortable with to be able to verify that tests are actually run on the CI server etc...)

[tomasaschan]

Also, bear in mind that I put together an infrastructure so that we would have some place to put our code when we start building the actual functionality we're after; let's not get stuck in bikeshedding here, but just make sure we have what we need to build code :)

[fbehrens]

thanks for your comments. It is OK as ever this goes. For me it and is unusual to have paket.dependencies in ./src and to call a fake target with src/build.sh --use-mono -- Clean.

It is really just a scaffold, but this stuff is complex. I copied the relevant parts from SAFE-BookStore which was recommended and maintained by @forki.

As there is no actual code the changing of the structure and the build system is a incremental change, for which I will happily create a pull request

[fbehrens]

Sorry, i could not resist creating a PR #30 for this.