Create .NET Standard Framework Build

[rprouse]

.NET Standard is intended to replace portable libraries and gives us access to more APIs which will allow us to re-introduce features that were dropped in the PCL version of NUnit like Timeouts, Platform detection, File and Directory asserts, etc.

I am marking this as design as the planning needs more work, but I hope to complete this for the next release, so I am moving to the 3.5 milestone.

We will need to decide if this replaces the portable version or if we deprecate PCL for one release. We also need to figure out which build tools support building .NET Standard libraries.

[rprouse]

In order to build a .NET Standard version of the library, developers will need to have at least Visual Studio 2015 Update 3 installed if we put the projects in the main solution. In order to build from the command line, they will need dotnet installed. Because of this, we should discuss approaches before I start working.

For installing dotnet,

1 - the cake script could check if it is installed and install it if it is not. It is a small download.
2 - we could do like we do for CF and check if it is installed and skip compile/test if it is not
3 - we could do option 2 and add a cake task to install dotnet

I prefer option 1 so that every developer is always building netstandard, but would like opinions from @nunit/core-team, @nunit/contributors and @nunit/net-core-runner-team

For adding the projects to the solutions, as I said, it will require Visual Studio Update 3 or I think the latest versions of MonoDevelop, options are,

1 - Make running the latest versions of Visual Studio or Monodevelop a requirement for NUnit developers
2 - Create a separate solution for netstandard

I prefer option 1 because it will ensure all of our code is compiled and checked, but I can understand this being an issue for some developers, please speak up.

If we go with option 1, one thing I would like to explore is the new multi-targeting. For example, we could have only one copy of the NUnit Framework project that targets .NET 2.0, 3.5, 4.0, 4.5 and NetStandard. It would make our solution a lot smaller and more manageable. For an example of this, you can look at the https://github.com/nunit/dotnet-test-nunit project that targets netstandard1.3 and .NET 4.5.1.

The single project file also has the advantage in that it includes the NuGet packaging info so we could also drop our NuSpec files.

As I see it, we have three decisions to make,

1 - Should we automatically install dotnet
2 - Should we require Visual Studio 2015 Update 3+ or latest MonoDevelop for developers
3 - Should we merge each of our targets into one project

I plan to start working on this issue as soon as we do the repository split, so I thought we should get the discussion going. Let the jousting begin 😄

[rprouse]

I should also add more about the reasons behind why we want to target netstandard1.3. The introduction to this issue is a start, but people should also read https://github.com/dotnet/corefx/blob/master/Documentation/architecture/net-platform-standard.md and https://docs.microsoft.com/en-us/dotnet/articles/standard/library

If you still have questions or don't see the worth, please ask 😄

[CharliePoole]

I have to do the "homework" before commenting in detail, but here are a few top-level ideas...

1. We get into trouble when we try to do too much in parallel. I think this issue is a good candidate as an Epic and I don't think we should try to do the three items you list at the same time. You probably have a better idea than I do about the best order in which to do them.
2. I don't think we should "replace" portable - at least not in one shot. I'd rather see it co-exist with netstandard for a month or so before dropping it. Belt and suspenders, you know.
3. Let's get some more active committers who are familiar with netstandard before committing to support it. I'm going to get myself familiar, but you shouldn't count on me because of my quasi-imminent departure. :-)

[ChrisMaddock]

For example, we could have only one copy of the NUnit Framework project that targets .NET 2.0, 3.5, 4.0, 4.5 and NetStandard

That in itself is more exciting than actually supporting NetStandard. ;-) Would love to see us make use of that.

The only existing NUnit target NetStandard doesn't seem to support is CF, is that right?

For installing dotnet...

I like option three. We talked about this when we put in the skip-Silverlight-if-not-installed bit. The Cake script could pause at the start and prompt the user if they want to install/skip the additional features for SL, CF and NetStandard. (If targeted) I imagine that would mean the majority of people would install, but installing anyway on the quiet doesn't seem right.

For adding the projects to the solutions, as I said, it will require Visual Studio Update 3 or I think the latest versions of MonoDevelop, options are,

With VS Community 2015 being free, I think that would be reasonable. If a user couldn't upgrade for any reason, the solution would just not load the core projects anyway, right? If that's the case, making a separate solution doesn't seem necessary imo. I know nothing about MonoDevelop, and if that would cause any issues. :-)

[jcansdale]

@rprouse,

For an example of this, you can look at the https://github.com/nunit/dotnet-test-nunit project that targets netstandard1.3 and .NET 4.5.1.

Can you spot the issue there? It means we can only test with .NET 4.5.1 and above using the current dotnet-test-nunit implementation. This is a shame because otherwise we trivially test all framework at once.

I've been meaning to add a feature suggestion to the dotnet-test-nunit project to support earlier versions of .NET. Unfortunately the Microsoft test libraries also target .NET 4.5.1, but the output is JSON based and not terribly complicated. I think we could do a .NET 3.5 version relatively easily.

[CharliePoole]

@ChrisMaddock I think that VS Community 2015 solves the biggest piece of this for us. But somebody should figure out what's doable in the latest versions of MonoDevelop and (IMO) SharpDevelop before we take the leap.