Use default file

[ErikSchierboom]

Some tracks lessen the barrier for users by providing an empty implementation file, which prevents the user from having to create the file themselves. An example of such a track is the Elm track, but the Scala track is also discussing this. How do you all feel about this? I think it would indeed lower the barrier, especially if we will also be providing exercise-specifc .fsproj files.

[jwood803]

Would it be just an empty set of .fsproj files for each exercise?

[ErikSchierboom]

Well, I imagine the .fsproj file would reference two files:

1. The stub implementation file.
2. The test file.

In my mind, the implementation file is empty, except for a module definition.

The .fsproj file should also be referencing NUnit, or any other library the exercise assumes the user to user (for example FsCheck for property-based tests or FParsec for parsing data).

To give users the best introduction to F#, I would suggest to use Paket for managing the dependencies (which can integrate nicely with the .fsproj file) and FAKE for allowing the user to run the tests using a command-line script.

This would result in the following files:

• Anagram.fs
• AnagramTest.fs
• Anagram.fsproj
• build.fsx
• paket.dependencies
• paket.lock
• paket.references
• build.fsx
• run-tests.cmd
• run-tests.sh

The main benefit is that there is less friction for users.

I've been following Enrico Sada, and he has been hard at work getting F# to work with the new .NET CLI in combination with .NET Core. Ideally, we would be using this, as this makes everything instantly cross-platform and we have a single installation path for users on any system. I even saw a fantastic demo of Paket working together with the .NET CLI, I think that is where we should be headed.

Once the .NET CLI/Paket integration is finished, I would like to start migrating the existing exercises.

[jason-kerney]

I would love this. I have been using these at supplements to teaching programming. I have a few friends who I am introducing to programming using F#and they are unable to remember how to run the tests for a loooooong time.

[ErikSchierboom]

As @robkeim mentioned in this C# track issue, the CLI tooling is no longer in preview. I just managed to get an F# project with xUnit tests running on .NET Core on my Mac, so things are starting to improve :)

This is the .fsproj file I used for my demo project:

<Project Sdk="FSharp.NET.Sdk;Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.0</TargetFramework>
    <Version>1.0.0-alpha</Version>
    <EnableDefaultCompileItems>false</EnableDefaultCompileItems>
  </PropertyGroup>

  <ItemGroup>
    <Compile Include="MyTests.fs" />
    <Compile Include="Program.fs" />
    <EmbeddedResource Include="**\*.resx" />
  </ItemGroup>

  <ItemGroup>
    <PackageReference Include="FSharp.NET.Sdk" Version="1.0.0-beta-*" PrivateAssets="All" />
    <PackageReference Include="Microsoft.FSharp.Core.netcore" Version="1.0.0-alpha-161023" />
    <PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.0.0-preview-20170106-08" />
    <PackageReference Include="xunit" Version="2.2.0-beta5-build3474" />
    <PackageReference Include="xunit.runner.visualstudio" Version="2.2.0-beta5-build1225" />
  </ItemGroup>

  <ItemGroup>
    <DotNetCliToolReference Include="dotnet-compile-fsc">
      <Version>1.0.0-preview2-020000</Version>
    </DotNetCliToolReference>
  </ItemGroup>

</Project>

[robkeim]

Cool stuff :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[ErikSchierboom]

Fixed by #348.