Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add .NET Core installation instructions #183

Merged

Conversation

henningjensen
Copy link
Contributor

No description provided.

@ErikSchierboom
Copy link
Member

This is great! Note that once .NET Core stabilizes (meaning the CLI tooling is no longer a preview), we will be creating projects for each exercise, so that the user won't havce to it themselves. For more information, see #138. Also, when the CLI tooling is released, the installation instructions for the different platforms can be greatly simplified.

@ErikSchierboom ErikSchierboom merged commit eb7aa6c into exercism:master Jan 26, 2017
@henningjensen henningjensen deleted the improve-installation-docs branch January 26, 2017 22:28
@robkeim
Copy link
Contributor

robkeim commented Feb 6, 2017

@ErikSchierboom It looks like the CLI tooling is no longer in preview... finally :)

https://www.visualstudio.com/en-us/news/releasenotes/vs2017-relnotes

Updated .NET Core and ASP.NET Core - No longer a preview workload. Fixed several bugs and improved usability of .NET Core and ASP.NET Core tooling. Project migration from project.json/xproj to csproj is much more reliable. The “Configure Continuous Delivery...

.NET Core tooling is now automatically included in “ASP.NET and web development” workload and an optional component in “.NET desktop development” workload in the installer. It is also available as a workload called “.NET Core cross-platform development” under “Other toolsets” section in the installer. We have fixed several bugs and usability issues for .NET Core and ASP.NET Core tooling. The csproj project format has been simplified and project migration from project.json/xproj to csproj is much more reliable.

@robkeim robkeim mentioned this pull request Feb 6, 2017
@ErikSchierboom
Copy link
Member

Ah, that's great! That means we can start working on creating a .NET Core project for each exercise. First, I'll do some local testing to see if things are indeed working as expected.

There is an issue with NUnit it appears: nunit/dotnet-test-nunit#101 And there's also this related issue.

This might be a good time to decide if we want to keep using NUnit, as xUnit seems to be more popular nowadays and has great out-of-the box support for the new CLI tooling (which makes sense as almost all Microsoft projects themselves use xUnit).

@robkeim
Copy link
Contributor

robkeim commented Feb 6, 2017

I'd be in favor of xUnit given the out-of-the-box support, although I only have an artificial understanding of the two test frameworks.

We're not doing anything advanced in terms of testing today, so I imagine that changing to xUnit, would be fairly straightforward although probably a bit tedious.

@ErikSchierboom
Copy link
Member

I just ran my first updated CLI program, and although it might no longer be a preview, it's not done by any means. VS Code also doesn't correctly pick up my code's extension method (I'm testing the accumulate exercise). Running the tests also immediately gives a build warning (microsoft/vstest#433), although it does execute correctly.

There are some rough edges at the moment, but, and now comes the good part, the new CLI and MSBuild format are very nice to work with. This is how the .csproj files will look like:

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp1.0</TargetFramework>
  </PropertyGroup>

  <ItemGroup>
    <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>

</Project>

By default, all .cs files will be compiled, which makes things far easier to setup. Running the tests is then simply a matter of calling dotnet test, which does work:

Eriks-MacBook-Pro:accumulate erikschierboom$ dotnet test
Build started, please wait...
/usr/local/share/dotnet/sdk/1.0.0-rc3-004530/Microsoft.Common.CurrentVersion.targets(1912,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved.  These reference conflicts are listed in the build log when log verbosity is set to detailed. [/Users/erikschierboom/Programming/xcsharp/exercises/accumulate/accumulate.csproj]
Build completed.

Test run for /Users/erikschierboom/Programming/xcsharp/exercises/accumulate/bin/Debug/netcoreapp1.0/accumulate.dll(.NETCoreApp,Version=v1.0)
Microsoft (R) Test Execution Command Line Tool Version 15.0.0.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Starting test execution, please wait...
Passed   AccumulateTest.Accumulate_squares
Passed   AccumulateTest.Accumulate_reversed_strings
Passed   AccumulateTest.Accumulate_is_lazy
Passed   AccumulateTest.Empty_accumulation_produces_empty_accumulation
Passed   AccumulateTest.Accumulate_allows_different_return_type
Passed   AccumulateTest.Accumulate_within_accumulate
Passed   AccumulateTest.Accumulate_upcases

Total tests: 7. Passed: 7. Failed: 0. Skipped: 0.
Test Run Successful.
Test execution time: 1.6011 Seconds

I hope that once the CLI is RTM, the rough edges have been smoothed and we have a simple, cross-platform setup for the C# (and F#) tracks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants