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.

[ChrisMaddock]

I did some homework:

• MonoDevelop has an in-progress PR to support netstandard: netstandard project support mono/monodevelop#1622
• SharpDevelop seems to have no sign of supporting netstandard yet, but equally still has an open issue to support .NET 4.6. I think VS community may see the end of SharpDevelop?

Rob - would you accept help with this one? I can't offer any prior expertise, but sounds like fun. 😄

[rprouse]

@ChrisMaddock help would be appreciated. There is already a branch up with work started on this. Look for the branch with this issue number. If you want, you can pull it down and bring it up to date and see if you can get it building again 😄

I won't be looking at it this week if you want to look at it.

[ChrisMaddock]

Didn't realise it was already under way - will have a look. Cheers!

[CharliePoole]

@rprouse Could we rename this issue to "Create .NET Standard Framework Build?"

I'm sure you didn't intend to wipe out the portable build immediately anyway. 😄

Additionally, I hope you will release this as a series of incremental dev builds, without waiting for every missing feature to be added.

[rprouse]

@CharliePoole I have renamed it. Part of the reason why I wanted to move this to 3.6 is so that we could get the initial PR in early in the release and then add issues to re-enable individual features. We might want to create an epic for this, but we can do that once we get this initial PR done.

[mhutch]

FWIW the netstandard support that just landed MonoDevelop is for MSBuild based projects, not xproj.

[rprouse]

Thanks for the info @mhutch. I didn't know you can do netstandard projects using MSBuild based projects. Clearly I have more reading to do 😄

[mhutch]

@rprouse yes, it's kind of hidden away :) In the project options for a PCL project there's an option to switch it to target netstandard. It's a little confusing because there's a project.json file in the MSBuild project - but in this case it's just a NuGet package manifest, essentially replacing packages.config.

[rprouse]

@mhutch thanks for that info. That would work better for NUnit. Do you know if the .NET Core tooling still needs to be installed for Visual Studio? Do you know someone that I can talk to for advice on which approach would be best for our project?

[mhutch]

@rprouse yes, this only works in VS2015 Update 3 with the .NET Core Tools RC.

I'd personally recommend the MSBuild approach since MonoDevelop / Xamarin Studio supports it, but the official guidance is to use xproj: https://docs.microsoft.com/en-us/dotnet/articles/core/tutorials/target-dotnetcore-with-msbuild

[rprouse]

@mhutch thanks for the link. I think we fall into the "You may want to use MSBuild to target .NET Core for existing projects that already use MSBuild that you want to port to .NET Core" category 😄

[jcansdale]

I tried using the .csproj + project.json combination for a little while, but found myself in a world of pain. I've settled on a hybrid .csproj + packages.config / .xproj + project.json approach as a least worst option.

The .csproj gives me a stable environment with quick compiles and the .xproj + project.json gives me multi-targeting and .NET Core support. It's not perfect, but it's maybe better than a proliferation of .cproj (one for each target) and a .xproj (for .NET Core support).

Here is an example repo:
https://github.com/jcansdale/CSProjXProj

@mhutch, I'm guessing MonoDevelop / Xamarin Studio would load the .csproj projects fine but would choke on the .xproj? (BTW, the two project types don't reference each other)

[mhutch]

Correct, MD/XS does not support xproj (and never will).

[ChrisMaddock]

@rprouse - Have you had any further thoughts on which way you think we should go with this?

I've done the last couple of changes got things building again (excl SL & CF) - although ReflectionExtensions.cs will definitely need a tidy! 😓 There's still something a little odd going on with tests, will need to look at that.

What are your thoughts on xproj vs csproj? I'm not following .NET core development that closely, but it sounds like .csproj is what we should be aiming for? Is it worth attempting to bite that bullet straight away, and keep everything in the one solution?

[rprouse]

@ChrisMaddock I am pretty sure I am going to go with the csproj approach. I will likely start with the projects in their own solution and then move them into the main solution when we understand any potential issues. I was thinking of dropping my existing branch and starting again fresh once the CF and SL changes are merged. Cleaning up all of the CF and SL defines will create way too many conflicts and starting with the cleaner code might be easier.

At this point, my rough plan of attack will be,

• Wait for the two CF/SL PRs to be merged
• Create a new branch for this issue
• Create a .NET Core solution and add CSPROJ projects for each project
• Mirror the existing PORTABLE functionality
• Create a PR and merge back into master closing this issue
• Evaluate all of the functionality that is disabled by conditionals and create issues for each
• Wherever possible, re-enable each feature as a separate PR

[ChrisMaddock]

@rprouse - Looks sensible! Sounds like a bit of a one-man critical path until the last step, so I'll hold back until then. 😄

[rprouse]

@ChrisMaddock once I create the branch and get things started, we could coordinate and work on the same branch. I could probably use help getting each project compiling, updating the build scripts, etc.

I will contact you once I get started and we can coordinate.

[CharliePoole]

Maybe it's time to create a dev branch, making it the default branch in GitHub. That would make it easier to collaborate and to merge features that are partial and which we don't yet want released generally.

I plan to do this for the NUnit 3 adapter once I release 3.5, so an option would be to wait and see how that goes - or you could just do it now if you like the idea.