Replace FAKE with CAKE

[ErikSchierboom]

We currently use FAKE as our build tool. We should consider switching to Cake, which has two advantages over using FAKE:

1. Cake uses C# instead of F# to encode the build script
2. There is tooling in Visual Studio to debug Cake scripts

As such, I feel that Cake might better a better fit for the C# track than FAKE, especially given the fact that our .NET Core build script is now much simpler.

[tushartyagi]

@ErikSchierboom I am interested in working on this one. I have done some reading on Cake today. Combined with #213, this would remove the dependency from paket and only use Nuget for dependency management, right?

[ErikSchierboom]

@tushartyagi That would be brilliant! This would indeed remove the need to use Paket, which could thus be removed. Let me know if you have any more questions!

By the way, did you know that Cake also has a Visual Studio extension?

[ErikSchierboom]

@tushartyagi Oh, and just to be clear, this work should once again be based on PR #199, but you probably knew that already :)

[tushartyagi]

@ErikSchierboom Thanks for the info. Your comment has changed my direction from Cake.Paket to Cake.VisualStudio 😃

[ErikSchierboom]

You're welcome! :) Having it integrated right into your IDE makes for far easier development. By the way, there is also a Cake Gitter room if you have any questions.

[ErikSchierboom]

@tushartyagi I got an email stating that you put some questions in this issue, but I can't seem to find the comment. Does that mean you figured it out yourself?

[tushartyagi]

@ErikSchierboom Yes. My question was why are we copying everything to the build folder. We could get away by building and testing everything in the exercises folder. Then I realised that we are replacing the stubs with Example.cs and running all the tests, so making a copy of everything is needed outerwise we botch up the exercises' files. :)

Anyhow, can you tell me why in build.fsx we have refactoringProjects? And some projects are removed from defaultProjects as well. Is there any particular reason?

[ErikSchierboom]

@tushartyagi Great question! Here is a short description what the build script does:

1. It tries to build the exercise's project as is, without any modifications. In this mode, the Example.cs file is not compiled, but the default stub file (<exercise>.cs) is. This verifies that the files the user will receive when he fetches the exercise (<exercise>.cs, <exercise>Test.cs and <exercise>.csproj) build correctly, which makes it easier for the user to start. However, there are some exercises, where we provide a default stub file that doesn't compile. This is intentional, as for these exercises, coming up with how to structure the implementation is part of the exercise. In other words, we explicitly don't provide a stub implementation that already compiles. Currently, there are three of these exercises: dot-dsl, hangman and react. That is why these projects are excluded from the defaultProjects set, as they won't compile and would thus make the build fail.
2. There are three exercises that are refactoring exercises: tree-building, ledger and markdown. These exercises are special in that they have a fully working implementation and all tests enabled. For these exercises, we want to verify that the default implementation (which is not just simply a stub anymore) passes all tests. That's the purpose of the refactoringProjects set.
3. Finally, we want to verify that the example implementation (Example.cs) passes all tests. To verify this, we do two things. One: we modify the project to exclude the <exercise>.cs file instead of the Example.cs file. This means that when the project is built, Example.cs is built instead of <exercise>.cs. Two: we remove the Skip = "Remove to run test" part of the [Fact] and [Theory] attributes in the <exercise>Test.cs files, to ensure that all tests will run (as by default, only one test runs as the other tests are skipped). Modifying the test files is the second reason why we copy the exercises to a separate folder.

Hope this helps clear up things!

[ErikSchierboom]

@tushartyagi By the way, if you want to get really fancy and experimental, you could look at Cake.Frosting. That is a standalone Cake runner that runs under .NET Core. I think it would be ideal for us, as we could then completely lose the Mono dependency. However, it is still in alpha, so I don't know if it works. If you feel like it, feel free to look at it. Otherwise, just use regular Cake.

[ErikSchierboom]

@tushartyagi Giving it a bit more thought, the Cake.Frosting bit is probably a bit too alpha. However, I've just learned of the Cake.CoreCLR NuGet package, which is a .NET Core compatible version of Cake. That will allow us to completely ditch Mono and further simplify the build.

I have also been referred to two projects using the Cake.CoreCLR package: Cake.Kudu and BitbucketPipelinesShield.

[tushartyagi]

Whoa! That's too much info. :P Let me tell you the progress. I have added the bootstrap packages (powershell and shell, which come free from the Cake developers). I've defined the tasks which clean, change stub to example, build, and test the code. These are working fine when I test them with the first few projects. (Not wasting time for testing all 104). I still have to make changes for refactoring and default projects, which we discussed above. Although in the build file, (`cake.build`) I am using `Dotnetcore*` commands [0], under the impression that cake will do the cross platform stuff for me. From what I understand, ditching mono would mean changing the bootstrap file since that is the place where I remember seeing `mono` commands. Am I correct? Also, I am travelling this weekend so will start working on this again from Monday. :) [0]: http://cakebuild.net/dsl/dotnetcore/

…

On 3 Mar 2017 8:02 pm, "Erik Schierboom" ***@***.***> wrote: @tushartyagi <https://github.com/tushartyagi> Giving it a bit more thought, the Cake.Frosting bit is probably a bit too alpha. However, I've just learned of the Cake.CoreCLR NuGet package, which is a .NET Core compatible version of Cake. That will allow us to completely ditch Mono and further simplify the build. I have also been referred to two projects using the Cake.CoreCLR package: Cake.Kudu <https://github.com/wcomab/Cake.Kudu> and BitbucketPipelinesShield <https://github.com/devlead/BitbucketPipelinesShield/blob/master/.travis.yml> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#214 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABjgOQlZuw_apR1nJc41k4WR6L_bfkXLks5riCRrgaJpZM4MNIzD> .

[ErikSchierboom]

@tushartyagi That's great! I would suggest to just ignore my above comments for now and just get your version working (which also uses Mono). Once we get that working, we can move on.

As for the Dotnetcore commands, they are indeed cross-platform. It's just the bootstrapper that has a dependency on Mono, but as said, let's fix that later :) Enjoy your travels!

[ErikSchierboom]

@tushartyagi I've just merged #199, which contains the .NET Core PR! 🎉 How are things looking at on the Cake side?

[tushartyagi]

@ErikSchierboom I was travelling and then stuck with work. Will start on this today and hopefully complete it in a day or two. :)
Congrats on pushing the .NET Core PR. It was a big one!!

[ErikSchierboom]

@tushartyagi No worries, there is no haste :) Great to hear you'll be continuing your work!

[tushartyagi]

@ErikSchierboom Please check #219 for this issue.

[ErikSchierboom]

@tushartyagi I will check it tonight, thanks!

[ErikSchierboom]

This has been fixed in #226.